| 2016-12-24 01:06:32 |
David Oxland |
bug |
|
|
added bug |
| 2016-12-24 01:06:32 |
David Oxland |
attachment added |
|
Duplicity failure.odt https://bugs.launchpad.net/bugs/1652410/+attachment/4795962/+files/Duplicity%20failure.odt |
|
| 2017-01-08 14:00:24 |
Vej |
deja-dup (Ubuntu): status |
New |
Incomplete |
|
| 2017-01-08 14:07:23 |
Vej |
bug |
|
|
added subscriber Vej |
| 2017-01-08 21:51:21 |
David Oxland |
attachment added |
|
/tmp deja-dup https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1652410/+attachment/4801706/+files/Screenshot%20from%202017-01-08%2013-45-49.png |
|
| 2017-01-13 23:22:35 |
David Oxland |
attachment added |
|
deja-dup.gsettings https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1652410/+attachment/4804058/+files/deja-dup.gsettings |
|
| 2017-01-14 20:42:53 |
David Oxland |
attachment added |
|
deja-dup.log ___that did have content https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1652410/+attachment/4804410/+files/deja-dup.log |
|
| 2017-01-14 22:51:56 |
Naël |
bug |
|
|
added subscriber Nathanaël Naeri |
| 2017-01-15 18:56:56 |
Naël |
summary |
duja-dup AssertionError: ({1: 'duplicity-full.20161129T015237Z.vol1.difftar'} |
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 |
|
| 2017-01-15 18:57:37 |
Naël |
deja-dup (Ubuntu): status |
Incomplete |
New |
|
| 2017-01-15 21:28:53 |
Vej |
bug task added |
|
deja-dup |
|
| 2017-01-15 21:29:00 |
Vej |
deja-dup: status |
New |
Triaged |
|
| 2017-01-15 21:29:51 |
Vej |
deja-dup: importance |
Undecided |
High |
|
| 2017-01-16 01:09:13 |
Naël |
attachment added |
|
deja-dup.log1 https://bugs.launchpad.net/deja-dup/+bug/1652410/+attachment/4804855/+files/deja-dup.log1 |
|
| 2017-01-16 01:09:34 |
Naël |
attachment added |
|
deja-dup.log2 https://bugs.launchpad.net/deja-dup/+bug/1652410/+attachment/4804856/+files/deja-dup.log2 |
|
| 2017-01-16 01:22:44 |
Launchpad Janitor |
deja-dup (Ubuntu): status |
New |
Confirmed |
|
| 2017-01-16 06:48:11 |
Vej |
deja-dup: status |
Triaged |
Confirmed |
|
| 2017-01-27 23:36:06 |
Alberto Salvia Novella |
deja-dup (Ubuntu): importance |
Undecided |
High |
|
| 2017-02-02 23:41:54 |
Naël |
removed subscriber Nathanaël Naeri |
|
|
|
| 2017-02-13 13:41:29 |
Naël |
bug task added |
|
duplicity |
|
| 2017-02-13 13:42:05 |
Naël |
bug task added |
|
duplicity (Ubuntu) |
|
| 2017-02-13 13:42:19 |
Naël |
duplicity: status |
New |
Confirmed |
|
| 2017-02-13 13:42:23 |
Naël |
duplicity (Ubuntu): status |
New |
Confirmed |
|
| 2017-02-13 13:59:08 |
Naël |
tags |
amd64 apport-bug xenial |
apport-bug testcase |
|
| 2017-02-13 13:59:14 |
Naël |
description |
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
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) |
[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. |
|
| 2017-02-13 20:56:41 |
David Oxland |
removed subscriber David Oxland |
|
|
|
| 2017-02-15 17:03:59 |
Vej |
tags |
apport-bug testcase |
apport-bug testcase xenial |
|
| 2017-03-06 20:57:54 |
Vej |
duplicity (Ubuntu): importance |
Undecided |
High |
|
| 2017-08-03 04:48:33 |
Michael Terry |
bug task deleted |
deja-dup |
|
|
| 2017-08-03 04:48:41 |
Michael Terry |
bug task deleted |
deja-dup (Ubuntu) |
|
|
| 2021-04-01 18:51:21 |
Kenneth Loafman |
duplicity: importance |
Undecided |
Medium |
|
