This bug was fixed in the package duplicity - 0.6.08b-0ubuntu2.2
---------------
duplicity (0.6.08b-0ubuntu2.2) lucid-proposed; urgency=low
* debian/patches/07volcorruption.dpatch:
- Fix some data-corruption issues when resuming an interrupted
backup (LP: #1091269)
-- Michael Terry <mte...@ubuntu.com> Fri, 11 Jan 2013 12:28:43 -0500
** Changed in: duplicity (Ubuntu Lucid)
Status: Fix Committed => Fix Released
--
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 - Bandwidth Efficient Encrypted Backup:
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:
Unknown
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 : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
