[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Duplicity-talk] silent data corruption with checkpoint/restore
From: |
Liraz Siri |
Subject: |
[Duplicity-talk] silent data corruption with checkpoint/restore |
Date: |
Tue, 03 Aug 2010 05:16:52 +0300 |
User-agent: |
Thunderbird 2.0.0.21 (X11/20090318) |
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] silent data corruption with checkpoint/restore,
Liraz Siri <=