I've found a much more serious bug with checkpoint/restore that leads to
silent data corruption. I'm using duplicity 0.6.09 installed
on a 32-bit Ubuntu system, backing up to the local filesystem.
I discovered this by running two full backups with the same parameters.
duplicity --archive-dir /var/cache/duplicity --volsize 10
--include-filelist /tmp/filelist --exclude '**' /
file:///var/tmp/duplicity
The first backup I allowed to complete without interruption.
The second backup I repeatedly stopped/resumed after the first volume
had been created.
I then restored the backups to /tmp/restore.broken and /tmp/restore and
compared them as follows:
cd /tmp/restore
find |xargs stat -c "%n %U %G %A %s"> statlist
cd /tmp/restore.broken
find |xargs stat -c "%n %U %G %A %s"> statlist
cd ../
diff -u /tmp/restore/{statlist,statlist.broken}
I discovered what looks like one corrupt file for each time I
CTRL-C/resumed the backup. I'm pretty sure these are the files duplicity
resumed from.
I would recommend that until this is fixed nobody use the
checkpoint/restore feature but unfortunately there doesn't seem to be
any way to disable it (in duplicity 0.6).
If you've already used checkpoint/restore in a version of duplicity that
has this bug it would be wise to recreate your backups immediately. Just
make sure the backup completes.
Cheers,
Liraz
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk