Added this bug to duplicity, since it is probably better suited for resolution there than in Déjà-Dup.
Also updated the description. ** Tags removed: amd64 xenial ** Tags added: testcase ** Description changed: - Deja-dup has never worked for me (last 5 years) always errors. - No after a new system reinstall 16.04 I was determined to get it up and running and learn about it's use,and perhaps recover some old data. - Still fails with see attached text + [System] - ProblemType: Bug - DistroRelease: Ubuntu 16.04 - Package: deja-dup 34.2-0ubuntu1.1 - ProcVersionSignature: Ubuntu 4.4.0-57.78-generic 4.4.35 - Uname: Linux 4.4.0-57-generic x86_64 - ApportVersion: 2.20.1-0ubuntu2.4 - Architecture: amd64 - CurrentDesktop: Unity - Date: Fri Dec 23 16:56:43 2016 - ExecutablePath: /usr/bin/deja-dup - InstallationDate: Installed on 2016-12-02 (21 days ago) - InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) - ProcEnviron: - PATH=(custom, user) - SHELL=/usr/bin/fish - LANG=en_CA.UTF-8 - LANGUAGE=en_CA:en - XDG_RUNTIME_DIR=<set> - SourcePackage: deja-dup - UpgradeStatus: No upgrade log present (probably fresh install) + Ubuntu 16.04 + deja-dup 34.2-0ubuntu1.1 + duplicity 0.7.06-2ubuntu2 + + [Symptoms] + + When the backup location unfortunately contains two backup volumes with + different file names and same volume number in the same backup set, for + instance: + + duplicity-full.20161129T015237Z.vol1.difftar + duplicity-full.20161129T015237Z.vol1.difftar.gz + + this confuses duplicity collection-status, which ends up returning an + undescriptive Python assertion error, as seen in this Déjà-Dup log file: + + DUPLICITY: INFO 1 + DUPLICITY: . Args: /usr/bin/duplicity collection-status [...] + + [...] + + DUPLICITY: DEBUG 1 + DUPLICITY: . 12 files exist on backend + + DUPLICITY: DEBUG 1 + DUPLICITY: . Extracting backup chains from list of files: + [u'duplicity-full.20161129T015237Z.vol1.difftar', + u'duplicity-full.20161129T015237Z.manifest', + u'duplicity-full.20161129T015237Z.vol1.difftar.gz', + u'duplicity-full-signatures.20161129T015237Z.sigtar.gz', + u'duplicity-full-signatures.20161129T015237Z.sigtar', + [...] + + DUPLICITY: DEBUG 1 + DUPLICITY: . File duplicity-full.20161129T015237Z.vol1.difftar is not + part of a known set; creating new set + + DUPLICITY: DEBUG 1 + DUPLICITY: . File duplicity-full.20161129T015237Z.manifest is part of + known set + + DUPLICITY: ERROR 30 AssertionError + [...] + DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/collections. + py", line 105, in add_filename(self.volume_name_dict, filename) + DUPLICITY: . AssertionError: + ({1: 'duplicity-full.20161129T015237Z.vol1.difftar'}, + 'duplicity-full.20161129T015237Z.vol1.difftar.gz') + + What happens is that duplicity collection-status takes the uncompressed + duplicity-full.20161129T015237Z.vol1.difftar for the start of a backup + set, then tries to add the compressed duplicity- + full.20161129T015237Z.vol1.difftar.gz to this set, and fails because the + volume number of this file has already been added to the set. Otherwise + there would be two backup volumes with the same volume number in the + backup set. + + Note that a similar issue may also happen for file signatures instead of + backup volumes, e.g.: + + duplicity-full-signatures.20161129T015237Z.sigtar + duplicity-full-signatures.20161129T015237Z.sigtar.gz + + but backup volumes appear to be tripped on first, perhaps because of + alphabetic order. + + Note also that under normal operation, the backup location isn't + supposed to contain a mixed of compressed and uncompressed files (or + encrypted and unencrypted files), but this situation was still reported + by the bug reporter in the original bug report. + + [Test case] + + See comment 19, written for Déjà-Dup, but easily adaptable to pure + duplicity I think. + + [Ideas for fixing] + + Duplicity already has checks to avoid considering files whose names + don't look like they could be part of a backup set (see comment 19, + point 4). Perhaps this filename filter could be improved on so that + duplicity doesn't burp so hard when a backup volume is present in both + compressed and uncompressed forms? Perhaps it could have duplicity + prefer a particular filename when there are two volumes with the same + number in the same backup set? But then which one and on what grounds? + + Please also see comment 23. + + [Easier fix] + + Worst case, if this situation can't be handled automatically and the + situation requires a human to examine the contents of the backup + repository to take adequate action, then it would be helpful that + duplicity return a more descriptive message than the current terse + assertion error. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652410 Title: Undescriptive duplicity/collection-status error when the backup directory contains two volumes with different file names and same volume number in the same backup set To manage notifications about this bug go to: https://bugs.launchpad.net/deja-dup/+bug/1652410/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs