| 2013-11-18 21:49:33 |
Michael Terry |
bug |
|
|
added bug |
| 2013-11-18 21:49:50 |
Michael Terry |
branch linked |
|
lp:~mterry/duplicity/disappearing-source |
|
| 2013-11-18 21:50:04 |
Michael Terry |
bug task added |
|
duplicity (Ubuntu) |
|
| 2013-11-18 22:09:14 |
Michael Terry |
nominated for series |
|
Ubuntu Lucid |
|
| 2013-11-18 22:09:14 |
Michael Terry |
bug task added |
|
duplicity (Ubuntu Lucid) |
|
| 2013-11-18 22:09:14 |
Michael Terry |
nominated for series |
|
Ubuntu Precise |
|
| 2013-11-18 22:09:14 |
Michael Terry |
bug task added |
|
duplicity (Ubuntu Precise) |
|
| 2013-11-18 22:09:14 |
Michael Terry |
nominated for series |
|
Ubuntu Raring |
|
| 2013-11-18 22:09:14 |
Michael Terry |
bug task added |
|
duplicity (Ubuntu Raring) |
|
| 2013-11-18 22:09:14 |
Michael Terry |
nominated for series |
|
Ubuntu Saucy |
|
| 2013-11-18 22:09:14 |
Michael Terry |
bug task added |
|
duplicity (Ubuntu Saucy) |
|
| 2013-11-18 22:09:14 |
Michael Terry |
nominated for series |
|
Ubuntu Quantal |
|
| 2013-11-18 22:09:14 |
Michael Terry |
bug task added |
|
duplicity (Ubuntu Quantal) |
|
| 2013-11-18 22:14:40 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/trusty-proposed/duplicity |
|
| 2013-11-18 23:01:46 |
Launchpad Janitor |
duplicity (Ubuntu): status |
New |
Fix Released |
|
| 2013-11-19 00:05:27 |
Michael Terry |
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]
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 --no-encryption full /tmp/source file:///tmp/backup --vol 1 --fail 2
mv /tmp/source/bigfile /tmp/source/newfile
duplicity --no-encryption full /tmp/source file:///tmp/backup
duplicity --no-encryption restore file:///tmp/backup /tmp/restore
# 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. |
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]
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. |
|
| 2013-11-19 00:05:41 |
Michael Terry |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2013-11-19 02:29:21 |
Stéphane Graber |
duplicity (Ubuntu Saucy): status |
New |
Fix Committed |
|
| 2013-11-19 02:29:25 |
Stéphane Graber |
bug |
|
|
added subscriber SRU Verification |
| 2013-11-19 02:29:26 |
Stéphane Graber |
tags |
|
verification-needed |
|
| 2013-11-19 02:38:37 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/saucy-proposed/duplicity |
|
| 2013-11-19 15:11:17 |
Miklos Juhasz |
tags |
verification-needed |
verification-done |
|
| 2013-11-21 22:27:06 |
Brian Murray |
duplicity (Ubuntu Raring): status |
New |
Fix Committed |
|
| 2013-11-21 22:27:13 |
Brian Murray |
tags |
verification-done |
|
|
| 2013-11-21 22:27:15 |
Brian Murray |
tags |
|
verification-needed |
|
| 2013-11-21 22:29:17 |
Brian Murray |
tags |
verification-needed |
verification-done-saucy verification-needed |
|
| 2013-11-21 22:30:30 |
Brian Murray |
duplicity (Ubuntu Quantal): status |
New |
Fix Committed |
|
| 2013-11-21 22:35:03 |
Brian Murray |
duplicity (Ubuntu Precise): status |
New |
Fix Committed |
|
| 2013-11-21 23:00:58 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-proposed/duplicity |
|
| 2013-11-21 23:01:00 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/quantal-proposed/duplicity |
|
| 2013-11-21 23:01:01 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/raring-proposed/duplicity |
|
| 2013-11-21 23:46:21 |
Brian Murray |
duplicity (Ubuntu Lucid): status |
New |
Fix Committed |
|
| 2013-11-21 23:53:39 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/lucid-proposed/duplicity |
|
| 2013-11-26 19:20:51 |
Launchpad Janitor |
duplicity (Ubuntu Saucy): status |
Fix Committed |
Fix Released |
|
| 2013-12-07 21:41:25 |
Michael Terry |
attachment added |
|
test1.sh https://bugs.launchpad.net/duplicity/+bug/1252484/+attachment/3925018/+files/test1.sh |
|
| 2013-12-07 21:42:40 |
Michael Terry |
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]
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. |
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. |
|
| 2014-01-03 18:52:16 |
Michael Terry |
tags |
verification-done-saucy verification-needed |
verification-done-lucid verification-done-saucy verification-needed |
|
| 2014-01-03 20:02:12 |
Michael Terry |
tags |
verification-done-lucid verification-done-saucy verification-needed |
verification-done-lucid verification-done-precise verification-done-saucy verification-needed |
|
| 2014-01-09 17:29:58 |
Launchpad Janitor |
duplicity (Ubuntu Lucid): status |
Fix Committed |
Fix Released |
|
| 2014-01-09 17:30:27 |
Launchpad Janitor |
duplicity (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
| 2014-01-09 17:50:48 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/lucid-updates/duplicity |
|
| 2014-01-09 17:50:50 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-updates/duplicity |
|
| 2014-01-23 18:05:59 |
Michael Terry |
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. |
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.
Note that symptoms of this bug are diverse and may look like:
assert len( patch_seq ) == 1, len( patch_seq )
or
assert first.difftype != "diff", patch_seq
or
librsync error 103 while in patch cycle
These are all different results from this root cause. In all cases, it is because chunks of files are missing in your backup. There is nothing we can do to get those chunks back. But a related patch in duplicity trunk will let you restore the rest of your files (instead of just crashing halfway through a restore like 0.6.22 does). So try duplicity trunk to get a little progress from your broken backups. And use duplicity trunk for all future backups.
[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. |
|
| 2014-01-24 12:24:12 |
Kenneth Loafman |
duplicity: milestone |
|
0.6.23 |
|
| 2014-01-24 13:12:12 |
Kenneth Loafman |
duplicity: status |
Fix Committed |
Fix Released |
|
| 2014-01-24 13:49:10 |
Michael Terry |
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.
Note that symptoms of this bug are diverse and may look like:
assert len( patch_seq ) == 1, len( patch_seq )
or
assert first.difftype != "diff", patch_seq
or
librsync error 103 while in patch cycle
These are all different results from this root cause. In all cases, it is because chunks of files are missing in your backup. There is nothing we can do to get those chunks back. But a related patch in duplicity trunk will let you restore the rest of your files (instead of just crashing halfway through a restore like 0.6.22 does). So try duplicity trunk to get a little progress from your broken backups. And use duplicity trunk for all future backups.
[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. |
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.
Note that symptoms of this bug are diverse and may look like:
assert len( patch_seq ) == 1, len( patch_seq )
or
assert first.difftype != "diff", patch_seq
or
librsync error 103 while in patch cycle
These are all different results from this root cause. In all cases, it is because chunks of files are missing in your backup. There is nothing we can do to get those chunks back. But a related patch in duplicity 0.6.23 will let you restore the rest of your files (instead of just crashing halfway through a restore like 0.6.22 does). So try duplicity 0.6.23 to get a little progress from your broken backups. And use duplicity 0.6.23 for all future backups.
[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. |
|
| 2014-01-27 20:40:34 |
Michael Terry |
bug task deleted |
duplicity (Ubuntu Raring) |
|
|
| 2014-12-05 05:06:34 |
Rolf Leggewie |
duplicity (Ubuntu Quantal): status |
Fix Committed |
Won't Fix |
|
