remove-all-but-n-full does not check for successfull backup
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Duplicity |
New
|
Undecided
|
Unassigned |
Bug Description
duplicity 0.6.09
Python 2.5.2
Debian Lenny
Target: Linxux, via SSH, no encryption
My backup script contains:
duplicity --exclude-
duplicity remove-
The last full backup was more than 180 days old, so duplicity created a new full backup. However the filesystem was too small, so the new full backup was incomplete.
It seems that the call to remove-
$ ls -s
total 529732
0 duplicity-
25612 duplicity-
...
17808 duplicity-
0 duplicity-
0 duplicity-
25588 duplicity-
...
25592 duplicity-
0 duplicity-
I found this bug still present in Duplicity 0.8.17-1 on Debian, see https:/ /bugs.debian. org/977546
It would be nice if there were at least a workaround described in the man page, like "run duplicity collection-status LOCATION, and if it says XXX you're okay, but if it says YYY then you may have an incomplete full backup. You can delete an incomplete full backup by running ZZZ."