Fresh backup started rather than current backup resumed, backups never complete
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Déjà Dup |
Invalid
|
Undecided
|
Unassigned | ||
deja-dup (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
About 2 months ago, I added several GB of new files that need to be backed up to Ubuntu One.
Since then, deja-dup incremental backups have never completed. The backup is happily stopped and resumed for a few days, and things progress - I've seen it gets as far as uploading over 80 25MB .difftar.gpg files over a few days. However, eventually deja-dup decides to start a new backup and the incomplete one is removed.
There are no alerts or warnings that the backups are not working. I've reported this as Bug #1210493.
I suspect that what is happening is that the duplicity is failing, but Deja-dup seeing this as a success. I cannot find any useful log files to investigate further.
ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: deja-dup 26.0-0ubuntu1
ProcVersionSign
Uname: Linux 3.8.0-27-generic x86_64
NonfreeKernelMo
ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
Date: Fri Aug 9 19:01:04 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-02-26 (164 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130225)
MarkForUpload: True
SourcePackage: deja-dup
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.12.4-0ubuntu1
Architecture: amd64
DistroRelease: Ubuntu 13.10
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-02-26 (213 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130225)
MarkForUpload: True
NonfreeKernelMo
Package: deja-dup 27.3.1-0ubuntu1
PackageArchitec
ProcVersionSign
Tags: saucy
Uname: Linux 3.11.0-8-generic x86_64
UpgradeStatus: Upgraded to saucy on 2013-09-24 (2 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
Thinking a little more about what I've been able to observe, I suspect that deja-dup is launching a fresh duplicity backup while the previous one is still running due to some sort of lock fail, or assumption that the former job couldn't possibly still be running. This new process cleans up, removing the partially completed backup and files required by the first instance, cause the first instance to abort when it tries to access these resources. deja-dup doesn't notice because it is dealing with the new duplicity job and couldn't care less about what is happening with the first instance.