collection-status removes local running backup files (sigtar)

Bug #1471818 reported by John Jasen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Duplicity
New
Undecided
Unassigned

Bug Description

Duplicity: 0.6.18-3 (debian stock)
Python: 2.7.3-4+deb7 (debian stock)
OS: Debian GNU/Linux 7.8 (wheezy)

We run duplicity --collection-status as part of periodic system health cron job (to feed passive nagios checks). The health script runs every 5 minutes.

During the normal backup run, on the local disk, signatures are written to $filename.sigtar.part. That file is then copied to $filename.sigtar and gzipped.

If $filename.sigtar.part is being copied to $filename.sigtar during a collection-status, duplicity will remove $filename.sigtar. These cause local backups to show as failed/incomplete, and for duplicity to fail with an error -- usually something along the lines of:

"OSError: [Errno 2] No such file or directory: '/var/cache/duplicity/$hostname/@/duplicity-full-signatures.$date-time-stamp.sigtar'"

This can be repeated, perhaps, by unzipping $filename.sigtar.gz and running collection-status. It can definitely be repeated by cp $filename.sigtar.part to $filename.sigtar, and running collection-status.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.