I just tried a backup and restore, encrypting the backup. Failed again on the restore, in exactly the same way as far as I can tell.
At this point I simply use Grsync to run a complete backup to an encrypted drive. It works well enough. On 12/15/2013 04:56 PM, Michael Terry wrote: > Lennart, see my comment #11. This fix/SRU is for the root cause when > making a backup, preventing the data loss in the first place. > > But if you are trying to restore a backup affected by the bug (as you > are), the traceback you see when restoring is worked-around by a > separate fix in duplicity trunk. You still will not be able to > correctly restore the file missing its 65k chunk, but duplicity trunk > does prevent the restore from bailing out. > -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to duplicity in Ubuntu. https://bugs.launchpad.net/bugs/1252484 Title: Possible data loss when restarting in the middle of a deleted file Status in Duplicity - Bandwidth Efficient Encrypted Backup: Fix Committed Status in “duplicity” package in Ubuntu: Fix Released Status in “duplicity” source package in Lucid: Fix Committed Status in “duplicity” source package in Precise: Fix Committed Status in “duplicity” source package in Quantal: Fix Committed Status in “duplicity” source package in Raring: Fix Committed Status in “duplicity” source package in Saucy: Fix Released Bug description: This was recently fixed in duplicity trunk. But I'm filing a bug for paperwork purposes and for Ubuntu SRUs. [Impact] When restarting a backup, duplicity may accidentally skip the first 65k chunk of one of the source files. This means that when it is restored, it will be incomplete/corrupted, resulting in data loss. [Test Case] Download and install the 'test1.sh' file attached to this bug report, and run it like 'sh test1.sh'. If it prints the following line, the bug is present: Binary files /tmp/source/newfile and /tmp/restore/newfile differ Or, follow these manual steps: mkdir /tmp/source dd if=/dev/urandom of=/tmp/source/bigfile bs=1024 count=5000 # This next command will intentionally fail after the second volume! duplicity full /tmp/source file:///tmp/backup --vol 1 --fail 2 --no-encryption mv /tmp/source/bigfile /tmp/source/newfile duplicity full /tmp/source file:///tmp/backup --no-encryption duplicity restore file:///tmp/backup /tmp/restore --no-encryption # This next line will say the files differ if the bug is present diff /tmp/source/newfile /tmp/restore/newfile [Regression Potential] It's a relatively small patch, only affecting the specific case of restarting a backup when the file we were in the middle of is no longer there. I'd say minor regression potential. To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/1252484/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
