[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
The attachment "no-encryption-
[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]