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
