[Duplicity-talk] silent data corruption with checkpoint/restore

[Liraz Siri]

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