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 Desktop
Packages, which is subscribed to duplicity in 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
Status in Déjà Dup:
Confirmed
Status in Duplicity:
Confirmed
Status in deja-dup package in Ubuntu:
Confirmed
Status in duplicity package in Ubuntu:
Confirmed
Bug description:
[System]
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/deja-dup/+bug/1652410/+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
