Launchpad has imported 13 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=922576.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2013-03-18T00:41:46+00:00 Michael wrote: Created attachment 711658 test script Description of problem: 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. (This is upstream bug https://bugs.launchpad.net/duplicity/+bug/1091269 ) Version-Release number of selected component (if applicable): This is fixed in upstream 0.6.21. It is present in probably any version of duplicity >= 0.6.0. How reproducible: Reliably. Steps to Reproduce: 1. Download the script 'auto-ctrl-c-test.sh' from this bug 2. sudo /bin/bash ./auto-ctrl-c-test.sh -s Actual results: There will be several lines at the end of the output explaining the difference between the original files and the restored ones. Expected results: It should end with "***** Diff between /lib and /tmp/restore" and no lines following. Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/24 ------------------------------------------------------------------------ On 2013-03-18T00:48:44+00:00 Michael wrote: Created attachment 711659 Patch against 0.6.20 Here's a patch against 0.6.20 for F18. Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/25 ------------------------------------------------------------------------ On 2013-03-18T00:52:33+00:00 Michael wrote: Created attachment 711660 Patch against 0.6.18 Here's a patch against 0.6.18 for F17. Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/26 ------------------------------------------------------------------------ On 2013-03-19T01:03:59+00:00 Rahul wrote: I have reviewed the upstream changelog and I think it is just better to push the latest upstream release to all active branches instead of cherry picking fixes. I am going to attempt to do that now. @robert, holler if you have a problem with that! Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/27 ------------------------------------------------------------------------ On 2013-03-19T01:32:13+00:00 Fedora wrote: duplicity-0.6.21-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/duplicity-0.6.21-1.fc18 Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/28 ------------------------------------------------------------------------ On 2013-03-19T01:34:46+00:00 Fedora wrote: duplicity-0.6.21-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/duplicity-0.6.21-1.fc17 Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/29 ------------------------------------------------------------------------ On 2013-03-19T03:19:37+00:00 Fedora wrote: duplicity-0.6.21-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/duplicity-0.6.21-1.el6 Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/30 ------------------------------------------------------------------------ On 2013-03-19T03:29:42+00:00 Fedora wrote: duplicity-0.6.21-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/duplicity-0.6.21-1.el5 Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/31 ------------------------------------------------------------------------ On 2013-03-19T21:26:58+00:00 Fedora wrote: Package duplicity-0.6.21-1.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing duplicity-0.6.21-1.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0709/duplicity-0.6.21-1.el6 then log in and leave karma (feedback). Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/32 ------------------------------------------------------------------------ On 2013-04-01T22:23:53+00:00 Fedora wrote: duplicity-0.6.21-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/33 ------------------------------------------------------------------------ On 2013-04-01T22:35:13+00:00 Fedora wrote: duplicity-0.6.21-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/34 ------------------------------------------------------------------------ On 2013-05-02T19:51:33+00:00 Fedora wrote: duplicity-0.6.21-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/35 ------------------------------------------------------------------------ On 2013-05-02T19:53:19+00:00 Fedora wrote: duplicity-0.6.21-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/duplicity/+bug/1091269/comments/36 ** Changed in: duplicity (Fedora) Status: Unknown => Fix Released ** Changed in: duplicity (Fedora) Importance: Unknown => Undecided -- 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/1091269 Title: Data corruption when resuming Status in Duplicity: Fix Released Status in duplicity package in Ubuntu: Fix Released Status in duplicity source package in Lucid: Fix Released Status in duplicity source package in Oneiric: Won't Fix Status in duplicity source package in Precise: Fix Released Status in duplicity source package in Quantal: Fix Released Status in duplicity package in Fedora: Fix Released Bug description: [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] 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 To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/1091269/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
