Here's a test script, run like so to test the system duplicity: sudo /bin/bash ./auto-ctrl-c-test.sh -s
** Attachment added: "auto-ctrl-c-test.sh" https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/1091269/+attachment/3479775/+files/auto-ctrl-c-test.sh ** Description changed: [Impact] It's very easy to accidentally corrupt the backup copy of a file when resuming an interrupted backup. Specifically, there are several ways to end up backing up corrupted data: A) If resuming after a volume that ended in a one-block file, we would skip the first block of the next file. B) If resuming after a volume that ended in a multi-block file, we would skip the first block of the next file. C) If resuming a non-encrypted backup after a volume that spanned a multi-block file, we would skip some data inside the file. These are all very similar but have slightly different code fixes. Together they amount to "if you resume a backup, it's very likely you will have corrupted data somewhere". The only situation that doesn't is resuming in the middle of a file while using encryption. [Test Case] - Running the restart test suite from my fix branch, which includes new tests for these cases: - bzr branch lp:~mterry/duplicity/static-corruption - cd static-corruption - ./testing/run-tests + Download the script 'auto-ctrl-c-test.sh' from this bug, and run it: + sudo /bin/bash ./auto-ctrl-c-test.sh -s + + It should end with "***** Diff between /lib and /tmp/restore" and no + lines following if the bug is fixed. If the bug is still there, there + will be several lines explaining the difference between the original + files and the restored ones. [Regression Potential] This patch changes (1) how much data we read from source files when backing up and (2) how we pick where to resume a backup. If a regression did appear because of this branch, I would expect it to be a similar data corruption problem (not starting in the right place or reading too much/too little from source files). [Original Report] I have found a bug similar to #613244. It seems that some files are corrupted when the backup is interrupted and resumed when using --no-encryption option. The make-ctrl-c-test.sh test fails if I add the --no-encryption option to duplicity. Without this option it works fine. I have added an option to make-ctrl-c-test.sh test to run it with or without encryption (patch attached). I have seen this bug in the current duplicity quantal version (0.6.19-0ubuntu2) and in the last bazaar revision (897). I also attached a patch that seems to fix this issue. I don't know anything about duplicity internals, so I don't know if this patch is correct or it will break something. Actually, I have ran the run-test script and it fails in test_GzipWriteFile test. But hopefully this can help you to fix the problem. These are the final log lines of the make-ctrl-c-test.sh script, with and without encryption. make-ctrl-c-test.sh with encryption: ... Restoring backups... Local and Remote metadata are synchronized, no sync needed. Last full backup date: Mon Dec 17 14:07:59 2012 Local and Remote metadata are synchronized, no sync needed. Last full backup date: Mon Dec 17 14:08:13 2012 Diff between /lib and /tmp/restore1 Diff between /tmp/restore1 and /tmp/restore2 make-ctrl-c-test.sh with --no-encryption and without fix applied: ... Restoring backups... Local and Remote metadata are synchronized, no sync needed. Last full backup date: Mon Dec 17 14:08:55 2012 Local and Remote metadata are synchronized, no sync needed. Last full backup date: Mon Dec 17 14:09:16 2012 Diff between /lib and /tmp/restore1 Diff between /tmp/restore1 and /tmp/restore2 Files /tmp/restore1/modules/3.5.0-19-generic/kernel/drivers/infiniband/hw/qib/ib_qib.ko and /tmp/restore2/modules/3.5.0-19-generic/kernel/drivers/infiniband/hw/qib/ib_qib.ko differ make-ctrl-c-test.sh with --no-encryption and fix applied: ... Restoring backups... Local and Remote metadata are synchronized, no sync needed. Last full backup date: Mon Dec 17 14:19:43 2012 Local and Remote metadata are synchronized, no sync needed. Last full backup date: Mon Dec 17 14:20:14 2012 Diff between /lib and /tmp/restore1 Diff between /tmp/restore1 and /tmp/restore2 The test_GzipWriteFile fails with this error: ====================================================================== FAIL: test_GzipWriteFile (__main__.GPGTest) Test GzipWriteFile ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/gpgtest.py", line 135, in test_GzipWriteFile assert size - 64 * 1024 <= os.stat("testfiles/output/gzwrite.gz").st_size <= size + 64 * 1024 AssertionError ---------------------------------------------------------------------- Ran 8 tests in 1.326s FAILED (failures=1) Test failed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1091269 Title: Data corruption when resuming To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/1091269/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
