[Desktop-packages] [Bug 1538333] Re: AssertionError in manifest.py: assert filecount == len(self.files_changed)
I've just experienced this bug on Zesty with duplicity 0.7.06-2ubuntu3. I was doing a full backup when the underlying filesystem disappeared (partly my fault). I remounted it and trying to resume the backup, but duplicity won't start with Traceback (most recent call last): File "/usr/bin/duplicity", line 1532, in with_tempdir(main) File "/usr/bin/duplicity", line 1526, in with_tempdir fn() File "/usr/bin/duplicity", line 1380, in main do_backup(action) File "/usr/bin/duplicity", line 1405, in do_backup globals.archive_dir).set_values() File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 710, in set_values self.get_backup_chains(partials + backend_filename_list) File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 835, in get_backup_chains add_to_sets(f) File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 829, in add_to_sets if new_set.add_filename(filename): File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 101, in add_filename self.set_manifest(filename) File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 149, in set_manifest self.set_files_changed() File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 128, in set_files_changed mf = self.get_manifest() File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 250, in get_manifest return self.get_local_manifest() File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 225, in get_local_manifest return manifest.Manifest().from_string(manifest_buffer) File "/usr/lib/python2.7/dist-packages/duplicity/manifest.py", line 207, in from_string assert filecount == len(self.files_changed) AssertionError This bug is marked as fixed but I haven't seen an update for Zesty. Did I miss something? -- 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/1538333 Title: AssertionError in manifest.py: assert filecount == len(self.files_changed) Status in Duplicity: Fix Released Status in duplicity package in Ubuntu: Confirmed Status in duplicity source package in Zesty: Fix Released Bug description: Duplicity was almost finishing a full backup to a FTP server. When I restarted the backup, the following error occured: root@MyMachine:~# duply MyProfile backup Start duply v1.11, time is 2016-01-26 23:38:21. Using profile '/root/.duply/MyProfile'. Using installed duplicity version 0.7.06, python 2.7.3, gpg 1.4.12 (Home: ~/.gnupg), awk 'mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan', grep 'grep (GNU grep) 2.12', bash 'GNU bash, Version 4.2.37(1)-release (i486-pc-linux-gnu)'. Autoset found secret key of first GPG_KEY entry '' for signing. Checking TEMP_DIR '/tmp' is a folder and writable (OK) Test - Encrypt to '' & Sign with '' (OK) Test - Decrypt (OK) Test - Compare (OK) Cleanup - Delete '/tmp/duply.16938.1453847902_*'(OK) --- Start running command PRE at 23:38:24.349 --- Skipping n/a script '/root/.duply/MyProfile/pre'. --- Finished state OK at 23:38:24.400 - Runtime 00:00:00.051 --- --- Start running command BKP at 23:38:24.447 --- LFTP version is 4.3.6 Reading globbing filelist /root/.duply/MyProfile/exclude Local and Remote metadata are synchronized, no sync needed. Traceback (most recent call last): File "/usr/local/bin/duplicity", line 1532, in with_tempdir(main) File "/usr/local/bin/duplicity", line 1526, in with_tempdir fn() File "/usr/local/bin/duplicity", line 1380, in main do_backup(action) File "/usr/local/bin/duplicity", line 1405, in do_backup globals.archive_dir).set_values() File "/usr/local/lib/python2.7/dist-packages/duplicity/collections.py", line 710, in set_values self.get_backup_chains(partials + backend_filename_list) File "/usr/local/lib/python2.7/dist-packages/duplicity/collections.py", line 835, in get_backup_chains add_to_sets(f) File "/usr/local/lib/python2.7/dist-packages/duplicity/collections.py", line 829, in add_to_sets if new_set.add_filename(filename): File "/usr/local/lib/python2.7/dist-packages/duplicity/collections.py", line 101, in add_filename self.set_manifest(filename) File "/usr/local/lib/python2.7/dist-packages/duplicity/collections.py", line 149, in set_manifest self.set_files_changed() File "/usr/local/lib/python2.7/dist-packages/duplicity/collections.py", line 128, in set_files_changed mf = self.get_manifest() File "/usr/local/lib/python2.7/dist-packages/duplicity/collections.py", line 250, in get_manifest return self.get_local_manifest() File "/usr/local/lib/python2.7/dist-packages/duplicity/collections.py", line 225, in get_local_manifest return
[Desktop-packages] [Bug 875676] Re: Backing up fails with 'IOError CRC check failed'.
I think I've got the same problem.
DejaDup with Ubuntu 16.04 prints the same error message and even
duplicity can't do anything in the backup folder. ("remove-older-than"
fails with "(, IOError('CRC check failed
0xb1276c7b != 0x9b944aa5L',), )".)
If I delete or move duplicity-new-
signatures.20160922T090645Z.to.20160929T083644Z.sigtar.gz, it might work
again.
But this is really not good.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/875676
Title:
Backing up fails with 'IOError CRC check failed'.
Status in Déjà Dup:
New
Status in Duplicity:
New
Status in deja-dup package in Ubuntu:
Confirmed
Bug description:
For 4 days déjà dup hasn't been able to perform a backup. It fails
with the error
Failed to read /tmp/duplicity-lJcUDl-tempdir/mktemp-o4LYSJ-1: (, IOError('CRC check failed 0x8434f7d2L !=
0x3d503338L',), )
There is another similar bug #676767 where deleting ~/.cache/deja-dup
helps. In this case it doesn't.
I'm quite certain that my backup drive isn't corrupted. (It's a
raid5.) I'd be happy to provide any additional information needed.
--
System information:
Ubuntu 11.10
deja-dup 20.0-0ubuntu3
duplicity 0.6.15-0ubuntu2
Logs:
deja-dup.log: http://pastie.org/2705320
deja-dup.gsettings: http://pastie.org/2705322
To manage notifications about this bug go to:
https://bugs.launchpad.net/deja-dup/+bug/875676/+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
[Desktop-packages] [Bug 1252484] Re: Possible data loss when restarting in the middle of a deleted file
I'm not affected with duplicity 0.7.06 on Ubuntu 16.04. -- 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/1252484 Title: Possible data loss when restarting in the middle of a deleted file 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 Precise: Fix Released Status in duplicity source package in Quantal: Won't Fix Status in duplicity source package in Saucy: Fix Released Bug 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 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. To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/1252484/+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
