Norman Goldstein | 18 Sep 05:53 2014
Picon

Oddity using --include-globbing-filelist

In my globbing filelist file, I have the line

+ /home/save/systems/Duplicity/Test/src/dirA

I have noticed a couple of things:

1. If there is a space at the end of the line,
the specified folder is not matched.  However,
duplicity is silent.

2. If I put a bogus folder name, instead of one
that actually exists, duplicity complains that
the folder does not exist.

So, it seems that duplicity is doing two passes
of the lines in the globbing filelist file.  The
first pass vets the file names, ignoring trailing
white space.  However, the 2nd pass, which actually
uses the file names, includes the trailing white
space, and does not complain if the resulting
file does not exist.

I can attach the example, it you would find it useful.

Thank you.
Aaron Whitehouse | 6 Sep 23:34 2014
Picon

ImportError (progress) when setting up for development

Hi,

I'm wanting to try to do a little development on duplicity, but I am struggling to get it set up. Apologies if this is a stupid question, but I'm new to some of these tools.

I'm following the instructions at:
http://bazaar.launchpad.net/~duplicity-team/duplicity/0.7-series/view/head:/README-REPO

==
1) Do the checkout while in a location called $DUP_ROOT:
        bzr lp:duplicity . [for the dev branch]
   -OR- bzr lp:duplicity/stable . [for the stable branch]
==
so I do:
:~/Programming$ bzr lp:duplicity .
bzr: ERROR: unknown command "lp:duplicity"

:~/Programming$ bzr branch lp:duplicity .
bzr: ERROR: Target directory "." already exists.

I therefore assume that this should be "bzr branch lp:duplicity":
:~/Programming$ bzr branch lp:duplicity
Branched 998 revisions.

==
2) cd $DUP_ROOT/duplicity
3) run "python compilec.py" to create _librsync.so
==
:~/Programming/duplicity/duplicity$ python compilec.py
running build
running build_ext
building '_librsync' extension
creating build
creating build/temp.linux-x86_64-2.7
x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c _librsyncmodule.c -o build/temp.linux-x86_64-2.7/_librsyncmodule.o
creating build/lib.linux-x86_64-2.7
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/_librsyncmodule.o -lrsync -o build/lib.linux-x86_64-2.7/_librsync.so

==
4) cd ..
5) run "./bin/duplicity -V". You will see "duplicity $version" instead
of the normal version number. Versioning comes during the release.
==
:~/Programming/duplicity/duplicity$ cd ..
:~/Programming/duplicity$ ./bin/duplicity -V
Traceback (most recent call last):
  File "./bin/duplicity", line 56, in <module>
    from duplicity import progress
ImportError: cannot import name progress

Running the unit tests seems to work (cd testing; ./run-tests) and nearly everything finishes with "ok" (except 2to3, diff2, PEP8, pylint and 2.6 tests, as I only have 2.7 installed).

Any thoughts would be appreciated.

This started out on Launchpad answers: https://answers.launchpad.net/duplicity/+question/252898

Many thanks in advance,

Aaron


_______________________________________________
Duplicity-talk mailing list
Duplicity-talk <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Carlos Chavez | 2 Sep 00:12 2014

Duplicity stops after 40 volumes

     I just installed a new CentOS 6.5 server with Duplicity 0.6.22 but 
I am having trouble completing the first full backup.  The backup stops 
every 40 volumes.  So far had to restart it several times and it has 
stopped at 40, 80, 120 and 160.  I really cannot understand why it is 
doing that.  The network connection between the servers is fast and 
stable.  Here is the output of duplicity:

Import of duplicity.backends.dpbxbackend Failed: No module named dropbox
Reading globbing filelist /root/backupinclude.txt
Local and Remote metadata are synchronized, no sync needed.
Last full backup left a partial set, restarting.
Last full backup date: Sun Aug 31 12:21:25 2014
RESTART: The first volume failed to upload before termination.
          Restart is impossible...starting backup from beginning.
Import of duplicity.backends.dpbxbackend Failed: No module named dropbox
Reading globbing filelist /root/backupinclude.txt
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
Last full backup is too old, forcing full backup
No handlers could be found for logger "paramiko.transport"
sftp put of /tmp/duplicity-4AxEur-tempdir/mktemp-N6NWhN-42 (as 
duplicity-full.20140831T223248Z.vol41.difftar.gz) failed:  (Try 1 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-4AxEur-tempdir/mktemp-N6NWhN-42 (as 
duplicity-full.20140831T223248Z.vol41.difftar.gz) failed:  (Try 2 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-4AxEur-tempdir/mktemp-N6NWhN-42 (as 
duplicity-full.20140831T223248Z.vol41.difftar.gz) failed:  (Try 3 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-4AxEur-tempdir/mktemp-N6NWhN-42 (as 
duplicity-full.20140831T223248Z.vol41.difftar.gz) failed:  (Try 4 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-4AxEur-tempdir/mktemp-N6NWhN-42 (as 
duplicity-full.20140831T223248Z.vol41.difftar.gz) failed:  (Try 5 of 5) 
Will retry in 10 seconds.
BackendException: Giving up trying to upload 
'duplicity-full.20140831T223248Z.vol41.difftar.gz' after 5 attempts
[root <at> server ~]#
[root <at> server ~]# /usr/bin/duplicity --no-encryption --full-if-older-than 
7D --include-globbing-filelist /root/backupinclude.txt / 
ssh://telecomab.dyndns.org//respaldos/cabana
Import of duplicity.backends.dpbxbackend Failed: No module named dropbox
Reading globbing filelist /root/backupinclude.txt
Local and Remote metadata are synchronized, no sync needed.
Last full backup left a partial set, restarting.
Last full backup date: Sun Aug 31 17:32:48 2014
RESTART: Volumes 41 to 41 failed to upload before termination.
          Restarting backup at volume 41.
Restarting after volume 40, file 
home/circulobienesraices/homes/conchaazuara/Maildir/cur/1409498005.000044.mbox:2,RS, 
block 181
No handlers could be found for logger "paramiko.transport"
sftp put of /tmp/duplicity-a3mSS0-tempdir/mktemp-qM53j6-42 (as 
duplicity-full.20140831T223248Z.vol81.difftar.gz) failed: Server 
connection dropped:  (Try 1 of 5) Will retry in 10 seconds.
sftp put of /tmp/duplicity-a3mSS0-tempdir/mktemp-qM53j6-42 (as 
duplicity-full.20140831T223248Z.vol81.difftar.gz) failed:  (Try 2 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-a3mSS0-tempdir/mktemp-qM53j6-42 (as 
duplicity-full.20140831T223248Z.vol81.difftar.gz) failed:  (Try 3 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-a3mSS0-tempdir/mktemp-qM53j6-42 (as 
duplicity-full.20140831T223248Z.vol81.difftar.gz) failed:  (Try 4 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-a3mSS0-tempdir/mktemp-qM53j6-42 (as 
duplicity-full.20140831T223248Z.vol81.difftar.gz) failed:  (Try 5 of 5) 
Will retry in 10 seconds.
BackendException: Giving up trying to upload 
'duplicity-full.20140831T223248Z.vol81.difftar.gz' after 5 attempts
[root <at> server ~]# /usr/bin/duplicity --no-encryption --full-if-older-than 
7D --include-globbing-filelist /root/backupinclude.txt / 
ssh://telecomab.dyndns.org//respaldos/cabana
Import of duplicity.backends.dpbxbackend Failed: No module named dropbox
Reading globbing filelist /root/backupinclude.txt
Local and Remote metadata are synchronized, no sync needed.
Last full backup left a partial set, restarting.
Last full backup date: Sun Aug 31 17:32:48 2014
RESTART: Volumes 81 to 81 failed to upload before termination.
          Restarting backup at volume 81.
Restarting after volume 80, file

home/circulobienesraices/homes/doloresestrada/Maildir/.sent-mail/cur/1409498271.000672.mbox:2,S, 
block 11
No handlers could be found for logger "paramiko.transport"
sftp put of /tmp/duplicity-Jm9zjA-tempdir/mktemp-GwwkhD-42 (as 
duplicity-full.20140831T223248Z.vol121.difftar.gz) failed: Server 
connection dropped:  (Try 1 of 5) Will retry in 10 seconds.
sftp put of /tmp/duplicity-Jm9zjA-tempdir/mktemp-GwwkhD-42 (as 
duplicity-full.20140831T223248Z.vol121.difftar.gz) failed:  (Try 2 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-Jm9zjA-tempdir/mktemp-GwwkhD-42 (as 
duplicity-full.20140831T223248Z.vol121.difftar.gz) failed:  (Try 3 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-Jm9zjA-tempdir/mktemp-GwwkhD-42 (as 
duplicity-full.20140831T223248Z.vol121.difftar.gz) failed:  (Try 4 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-Jm9zjA-tempdir/mktemp-GwwkhD-42 (as 
duplicity-full.20140831T223248Z.vol121.difftar.gz) failed:  (Try 5 of 5) 
Will retry in 10 seconds.
BackendException: Giving up trying to upload 
'duplicity-full.20140831T223248Z.vol121.difftar.gz' after 5 attempts
[root <at> server ~]# /usr/bin/duplicity --no-encryption --full-if-older-than 
7D --include-globbing-filelist /root/backupinclude.txt / 
ssh://telecomab.dyndns.org//respaldos/cabana
Import of duplicity.backends.dpbxbackend Failed: No module named dropbox
Reading globbing filelist /root/backupinclude.txt
Local and Remote metadata are synchronized, no sync needed.
Last full backup left a partial set, restarting.
Last full backup date: Sun Aug 31 17:32:48 2014
RESTART: Volumes 121 to 121 failed to upload before termination.
          Restarting backup at volume 121.
Restarting after volume 120, file 
home/circulobienesraices/homes/edelamora/Maildir/cur/1409498342.000415.mbox:2,S, 
block 7
No handlers could be found for logger "paramiko.transport"
sftp put of /tmp/duplicity-akynaz-tempdir/mktemp-lxSklg-42 (as 
duplicity-full.20140831T223248Z.vol161.difftar.gz) failed: Server 
connection dropped:  (Try 1 of 5) Will retry in 10 seconds.
sftp put of /tmp/duplicity-akynaz-tempdir/mktemp-lxSklg-42 (as 
duplicity-full.20140831T223248Z.vol161.difftar.gz) failed:  (Try 2 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-akynaz-tempdir/mktemp-lxSklg-42 (as 
duplicity-full.20140831T223248Z.vol161.difftar.gz) failed:  (Try 3 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-akynaz-tempdir/mktemp-lxSklg-42 (as 
duplicity-full.20140831T223248Z.vol161.difftar.gz) failed:  (Try 4 of 5) 
Will retry in 10 seconds.
sftp put of /tmp/duplicity-akynaz-tempdir/mktemp-lxSklg-42 (as 
duplicity-full.20140831T223248Z.vol161.difftar.gz) failed:  (Try 5 of 5) 
Will retry in 10 seconds.
BackendException: Giving up trying to upload 
'duplicity-full.20140831T223248Z.vol161.difftar.gz' after 5 attempts

--

-- 
Telecomunicaciones Abiertas de México S.A. de C.V.
Carlos Chávez
+52 (55)9116-91161
Brant Winter | 31 Aug 05:37 2014
Picon

Behaviour upon 'Full' backup after incrementals

Can someone please help clarify this ? If I have seeded a massive (100GB) full backup over SFTP remotely and have then done daily incremental backups for a week. If I chose to do another ‘full’ backup will Duplicity have to seed the massive initial backup again, or will it roll up the original full backup and incremental on the remote side, add in the latest deltas and call it a new full backup without having to seed the whole thing across SFTP again ? I have approx 100GB to have backed up offsite and just trying to work out if Duplicity will do what I need ? Thanks in advance.
_______________________________________________
Duplicity-talk mailing list
Duplicity-talk <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Jonathan Brown | 29 Aug 23:30 2014
Picon

Stream Vulnerability

Could anyone tell me if Duplicity is vulnerable to stream encryption vulnerabilities utilizing GPG? This blog post talks about issues affecting encryption that uses GPG and I would like to know if there is any reason to be concerned. Thanks


_______________________________________________
Duplicity-talk mailing list
Duplicity-talk <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Mikko Ohtamaa | 25 Aug 20:21 2014

IRC channel

Hi all,

If you are still using IRC chat (like all good open source citizens should :)

There is a channel

#duplicity

on irc.freenode.net
_______________________________________________
Duplicity-talk mailing list
Duplicity-talk <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Karl Buckland | 22 Aug 11:52 2014
Picon

Purging, purge-full, not working?

Hi,

I've been using Duply for a few months to backup up a handful of servers to Amazon S3. So far it's been working brilliantly.

I'm running Debian Squeeze on all of them, which ships with Duply 1.5.5.5. However I have also tried using the latest 1.8.0 in order to ensure that my issue hasn't already been fixed. I have the same issue with both versions (and the equivalent commands for each).

Either I'm not using the purge commands properly, or it's not working.

I currently have Duply set up to do a full backup once a month, with incrementals every day, with these settings:
MAX_AGE=3M
MAX_FULL_BACKUPS=3
MAX_FULLS_WITH_INCRS=3
MAX_FULLBKP_AGE=1M
DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE "
VOLSIZE=250
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "

When I run the 'status' command, I can see:
Full backups: April 27, June 18, Jul 19, Aug 19
Incrementals: June 18 onwards
This is correct, as I originally ran a full backup and then left it for a little while before getting it to run regularly.

However, when I issue the 'purge' command, it lists out all files, full and incremental up to August 17th. I get this even if I issue the purge command as 'purge 3M' or 'purge 90D' or anything similar. It ignores my commands and appears to be ignoring the config file too?

I see the same issues with the purgeFull 3 and purgeIncr 3 commands. They ignore the config file and the arguments passed to them and they list everything up until the last week or so.

Have I misunderstood the commands and config file, or is there a legitimate issue?

Thanks in advance for any assistance.

Regards,

Karl
_______________________________________________
Duplicity-talk mailing list
Duplicity-talk <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
David Ehrmann | 20 Aug 19:21 2014
Picon

Migrating to a different data store URL

It looks like migrating to a new data store (from file:// to s3, or s3 to ssh) is as simple as moving the files, and optionally renaming the ~/.cache/duplicity entry to the md5 of the new destination, though omitting the last step will just cause Duplicity to fetch the metadata. Obviously, all the prefix flags will have to match, but otherwise, it looks like migrating is straightforward.

Am I missing anything? My plan is to do an initial backup to a local disk, use AWS Import to move the data to S3, then do incremental backups off of that.
_______________________________________________
Duplicity-talk mailing list
Duplicity-talk <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
a.grandi@gmail.com | 15 Aug 18:10 2014
Picon

Skylable backend ready to be merged and relased

Hi!

As you already know, in these days I was working to the Skylable
backend for Duplicity and you can find it here:
https://github.com/andreagrandi/duplicity-sx/blob/master/duplicity/backends/sxbackend.py

People from Skylable have tested heavily in the past days and they
consider it quite stable (it's been written using the devel/0.7
version of Duplicity).

What is the official procedure to have this integrated in the
mainstream Duplicity code?

Thank you so much!

Cheers.

--

-- 
Andrea Grandi -  Software Engineer / Qt Ambassador / Nokia Developer Champion
website: http://www.andreagrandi.it
Jelle de Jong | 13 Aug 16:58 2014
Picon

problem: duplicity is not backing up the my files


Hello everyone,

After some investigation I found that duplicity does not have the same
files in its collection as the files in the location that should be
backuped. I think it has to do that the files may be changed or
removed after the duplicity command has been started. (since the
backup takes a few days, and some files rotate every day).

See the attached debug file for more information.

However I also never get any warning or error that it failed to backup
anything. It will finish saying it went all okay.

Is this normal behaviour? Should I change my backup systems?

Kind regards,

Jelle de Jong
root <at> backup:~# duplicity --version
duplicity 0.6.24

root <at> backup:~# duplicity collection-status --archive-dir /var/cache/backupninja/duplicity
--name ca76476632badf50cdf688a006875374 scp://user-backup <at> server.somewhere.nl/backups/libvirt-guests
duplicity list-current-files --archive-dir /var/cache/backupninja/duplicity --name
ca76476632badf50cdf688a006875374 scp://user-backup <at> server.somewhere.nl/backups/libvirt-guests
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Aug  8 19:02:18 2014
Collection Status
-----------------
Connecting with backend: SSHParamikoBackend
Archive dir: /var/cache/backupninja/duplicity/ca76476632badf50cdf688a006875374

Found 3 secondary backup chains.
Secondary chain 1 of 3:
-------------------------
Chain start time: Fri Jul 18 19:04:27 2014
Chain end time: Fri Jul 18 19:04:27 2014
Number of contained backup sets: 1
Total number of contained volumes: 7123
 Type of backup set:                            Time:      Num volumes:
                Full         Fri Jul 18 19:04:27 2014              7123
-------------------------

Secondary chain 2 of 3:
-------------------------
Chain start time: Fri Jul 25 19:02:40 2014
Chain end time: Fri Jul 25 19:02:40 2014
Number of contained backup sets: 1
Total number of contained volumes: 7572
 Type of backup set:                            Time:      Num volumes:
                Full         Fri Jul 25 19:02:40 2014              7572
-------------------------

Secondary chain 3 of 3:
-------------------------
Chain start time: Fri Aug  1 19:20:09 2014
Chain end time: Fri Aug  1 19:20:09 2014
Number of contained backup sets: 1
Total number of contained volumes: 8068
 Type of backup set:                            Time:      Num volumes:
                Full         Fri Aug  1 19:20:09 2014              8068
-------------------------

Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Fri Aug  8 19:02:18 2014
Chain end time: Fri Aug  8 19:02:18 2014
Number of contained backup sets: 1
Total number of contained volumes: 8071
 Type of backup set:                            Time:      Num volumes:
                Full         Fri Aug  8 19:02:18 2014              8071
-------------------------
No orphaned or incomplete backup sets found.
root <at> backup:~# duplicity list-current-files --archive-dir /var/cache/backupninja/duplicity
--name ca76476632badf50cdf688a006875374 scp://user-backup <at> server.somewhere.nl/backups/libvirt-guests
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Aug  8 19:02:18 2014
Sat Aug  2 13:21:08 2014 .
Fri Apr 11 11:35:37 2014 srv
Mon Aug 19 12:24:22 2013 srv/storage
Fri Aug  8 18:56:33 2014 srv/storage/backups
Fri Aug  8 17:45:01 2014 srv/storage/backups/libvirt-guests
Fri Aug  8 18:56:30 2014 srv/storage/backups/libvirt-guests/latest
Mon Aug  4 18:11:55 2014 srv/storage/backups/libvirt-guests/latest/charibase1-disk1-snapshot-2014-08-04-1407167107.dd.disk.gz
Mon Aug  4 18:31:54 2014 srv/storage/backups/libvirt-guests/latest/charibase1-disk2-snapshot-2014-08-04-1407167107.dd.disk.gz
Mon Aug  4 18:04:10 2014 srv/storage/backups/libvirt-guests/latest/charibase1-disk3-snapshot-2014-08-04-1407167107.dd.disk.gz
Fri Aug  8 18:45:40 2014 srv/storage/backups/libvirt-guests/latest/somewhere-disk1-snapshot-2014-08-08-1407512704.dd.disk.gz
Fri Aug  8 01:29:15 2014 srv/storage/backups/libvirt-guests/latest/somewhere-disk2-snapshot-2014-08-07-1407426307.dd.disk.gz
Tue Aug  5 18:26:55 2014 srv/storage/backups/libvirt-guests/latest/horoscope-disk-snapshot-2014-08-05-1407253505.dd.disk.gz
Fri Aug  8 18:03:49 2014 srv/storage/backups/libvirt-guests/latest/kvm01-disk-snapshot-2014-08-08-1407512704.dd.disk.gz
Fri Aug  8 18:56:09 2014 srv/storage/backups/libvirt-guests/latest/ldapproxy1-disk-snapshot-2014-08-08-1407513839.dd.disk.gz
Wed Aug  6 19:32:56 2014 srv/storage/backups/libvirt-guests/latest/maintenance1-disk-snapshot-2014-08-06-1407344350.dd.disk.gz
Thu Aug  7 21:46:44 2014 srv/storage/backups/libvirt-guests/latest/nginx1-disk-snapshot-2014-08-07-1407439270.dd.disk.gz
Thu Aug  7 21:53:09 2014 srv/storage/backups/libvirt-guests/latest/ns0-disk-snapshot-2014-08-07-1407440130.dd.disk.gz
Fri Aug  8 07:19:28 2014 srv/storage/backups/libvirt-guests/latest/opsi-disk-snapshot-2014-08-07-1407440836.dd.disk.gz
Sun Aug  3 23:40:55 2014 srv/storage/backups/libvirt-guests/latest/osiris-at-disk-snapshot-2014-08-03-1407095682.dd.disk.gz
Sun Aug  3 23:52:39 2014 srv/storage/backups/libvirt-guests/latest/osiris-ot-disk-snapshot-2014-08-03-1407095853.dd.disk.gz
Mon Aug  4 03:31:41 2014 srv/storage/backups/libvirt-guests/latest/relax1-disk1-snapshot-2014-08-04-1407107877.dd.disk.gz
Mon Aug  4 03:37:24 2014 srv/storage/backups/libvirt-guests/latest/socks1-disk-snapshot-2014-08-04-1407115215.dd.disk.gz
Fri Aug  8 11:31:05 2014 srv/storage/backups/libvirt-guests/latest/sr5-disk2-snapshot-2014-08-08-1407477324.dd.disk.gz
Fri Aug  8 13:50:33 2014 srv/storage/backups/libvirt-guests/latest/webserver1-disk2-snapshot-2014-08-08-1407480987.dd.disk.gz
Fri Aug  8 09:44:03 2014 srv/storage/backups/libvirt-guests/latest/zabbix2-disk-snapshot-2014-08-08-1407481493.dd.disk.gz
root <at> backup:~# ls -hal /srv/storage/backups/libvirt-guests/latest/
total 330G
drwxr-xr-x  2 root root 4.0K Aug 13 12:12 .
drwxr-x--- 37 root root 4.0K Aug 12 23:56 ..
-rw-r--r--  1 root root 2.6G Aug 11 18:26 charibase1-disk1-snapshot-2014-08-11-1407772806.dd.disk.gz
-rw-r--r--  1 root root 4.1G Aug 11 18:47 charibase1-disk2-snapshot-2014-08-11-1407772806.dd.disk.gz
-rw-r--r--  1 root root 1.6G Aug 11 18:19 charibase1-disk3-snapshot-2014-08-11-1407772806.dd.disk.gz
-rw-r--r--  1 root root 4.4G Aug 12 18:45 somewhere-disk1-snapshot-2014-08-12-1407858305.dd.disk.gz
-rw-r--r--  1 root root  20G Aug 13 01:20 somewhere-disk2-snapshot-2014-08-12-1407858305.dd.disk.gz
-rw-r--r--  1 root root 4.3G Aug 12 18:26 horoscope-disk-snapshot-2014-08-12-1407858305.dd.disk.gz
-rw-r--r--  1 root root 1.7G Aug 12 18:46 kvm01-disk-snapshot-2014-08-12-1407860819.dd.disk.gz
-rw-r--r--  1 root root 5.5G Aug 12 19:38 ldapproxy1-disk-snapshot-2014-08-12-1407861988.dd.disk.gz
-rw-r--r--  1 root root  15G Aug 12 21:29 liferay1-disk1-snapshot-2014-08-12-1407861988.dd.disk.gz
-rw-r--r--  1 root root 3.4G Aug  6 19:32 maintenance1-disk-snapshot-2014-08-06-1407344350.dd.disk.gz
-rw-r--r--  1 root root  13G Aug 12 22:01 media1-disk3-snapshot-2014-08-12-1407865141.dd.disk.gz
-rw-r--r--  1 root root 2.5G Aug 10 21:52 nginx1-disk-snapshot-2014-08-10-1407698737.dd.disk.gz
-rw-r--r--  1 root root 1.5G Aug 10 21:56 ns0-disk-snapshot-2014-08-10-1407699464.dd.disk.gz
-rw-r--r--  1 root root  57G Aug 13 06:54 opsi-disk-snapshot-2014-08-12-1407871944.dd.disk.gz
-rw-r--r--  1 root root 7.9G Aug 10 23:36 osiris-at-disk-snapshot-2014-08-10-1407700383.dd.disk.gz
-rw-r--r--  1 root root 9.7G Aug 10 23:58 osiris-ot-disk-snapshot-2014-08-10-1407700588.dd.disk.gz
-rw-r--r--  1 root root 8.8G Aug 12 23:56 osiris-training2-disk-snapshot-2014-08-12-1407873831.dd.disk.gz
-rw-r--r--  1 root root 7.4G Aug 13 01:29 owncloud1-disk1-snapshot-2014-08-12-1407880682.dd.disk.gz
-rw-r--r--  1 root root  12G Aug 13 03:36 portal1-disk1-snapshot-2014-08-13-1407885830.dd.disk.gz
-rw-r--r--  1 root root  11G Aug 11 03:12 relax1-disk1-snapshot-2014-08-11-1407712305.dd.disk.gz
-rw-r--r--  1 root root 5.3G Aug 13 02:51 reporting-disk-snapshot-2014-08-13-1407886264.dd.disk.gz
-rw-r--r--  1 root root 4.0G Aug 13 03:45 sec1-disk1-snapshot-2014-08-13-1407891153.dd.disk.gz
-rw-r--r--  1 root root 1.3G Aug 11 03:11 socks1-disk-snapshot-2014-08-11-1407718475.dd.disk.gz
-rw-r--r--  1 root root 6.0G Aug 13 05:00 sr1-disk1-snapshot-2014-08-13-1407893897.dd.disk.gz
-rw-r--r--  1 root root 610M Aug 13 03:54 sr1-disk2-snapshot-2014-08-13-1407894397.dd.disk.gz
-rw-r--r--  1 root root  15G Aug 13 06:35 sr2-disk1-snapshot-2014-08-13-1407894904.dd.disk.gz
-rw-r--r--  1 root root 1.1G Aug 13 05:16 sr2-disk3-snapshot-2014-08-13-1407898880.dd.disk.gz
-rw-r--r--  1 root root  21G Aug 13 08:53 sr4-disk1-snapshot-2014-08-13-1407899777.dd.disk.gz
-rw-r--r--  1 root root  13G Aug 13 08:40 sr4-disk2-snapshot-2014-08-13-1407904622.dd.disk.gz
-rw-r--r--  1 root root 7.7G Aug 13 08:36 sr5-disk1-snapshot-2014-08-13-1407906095.dd.disk.gz
-rw-r--r--  1 root root  23G Aug 13 12:10 sr5-disk2-snapshot-2014-08-13-1407911854.dd.disk.gz
-rw-r--r--  1 root root 6.2G Aug 13 09:40 webserver1-disk-snapshot-2014-08-13-1407912157.dd.disk.gz
-rw-r--r--  1 root root  36G Aug 12 14:18 webserver1-disk2-snapshot-2014-08-12-1407828382.dd.disk.gz
-rw-r--r--  1 root root 2.6G Aug 11 09:05 zabbix2-disk-snapshot-2014-08-11-1407738226.dd.disk.gz
root <at> backup:~# ls -hal /etc/backup.d/
10.sys                               90.system.dup                        91.libvirt-guests.dup.disabled       92.libvirt-filesystems.dup.disabled  93.somewhere-zimbra.dup.disabled
root <at> backup:~# grep -i include /etc/backup.d/91.libvirt-guests.dup.disabled
# NB: neither quote this, nor should it include any quotes
# A few notes about includes and excludes:
# 1. include, exclude and vsinclude statements support globbing with '*'
# 2. Symlinks are not dereferenced. Moreover, an include line whose path
#      include = /home/user/Mail
#      include = /mnt/crypt/home/user/Mail
# 3. All the excludes come after all the includes. The order is not otherwise
# files to include in the backup
include = /srv/storage/backups/libvirt-guests/latest/
# vsinclude = <path>
# vsinclude = <path>
# Any path specified in vsinclude is added to the include list for each vserver
# For example, vsinclude = /home will backup the /home directory in every
# vsinclude will add to the include list /vservers/foo/home, /vservers/bar/home
_______________________________________________
Duplicity-talk mailing list
Duplicity-talk <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
boytruc | 12 Aug 00:26 2014
Picon

git and duplicity

Hello 

My question will be strange but, is it possible to get any problem with git folder who are backup by
duplicity. I have 2 VPS and 1 raspberry who are all using duplicity script under debian (threw
duplicity-backup script) and I'm getting sometimes (3 times this year) some weird problem with git folder.

Folder with project 'git cloned' getting empty (except unrecognized .git folder) or having problem
without any changes on files (example for dot-files). I'm not doing lot's of stuff on this machine except
usual update. 

It's not probably related, but I was wondering.

Thanks in advance for your help.

Ben

Gmane