Backup chain corrupted due to scp failure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Duplicity |
New
|
Undecided
|
Unassigned |
Bug Description
Today I've been trying to salvage some lost data using our duplicity backups. However during the restoration I've run into the following error a few times:
Invalid data - SHA1 hash mismatch for file:
duplicity-
Digging through the backup volumes, that specific increment caught my attention:
200M Jun 1 09:38 duplicity-
21M Jun 1 09:38 duplicity-
201M Jun 1 10:27 duplicity-
Notably:
- volume 16 is incomplete
- volume 17 and 18 are missing
In the logs when creating that backup, the following relevant messages have been outputted:
Giving up after 5 attempts. BackendException: Error running 'scp -oServerAliveIn
Giving up after 5 attempts. BackendException: Error running 'scp -oServerAliveIn
Giving up after 5 attempts. BackendException: Error running 'scp -oServerAliveIn
For reference, the command used to produce this backup is:
/usr/
Duplicity version: 0.7.15
Python version: 2.7.5
OS: CentOS 7.3 EL7 (centos-
Filesystem: XFS
Looking through the backup logs, I see quite a few of those "giving up" messages. Probably those increments are corrupted as well. I'm starting to lose my confidence in the backups produced by duplicity. I expect that when an increment hasn't fully completed, duplicity would not continue to use that increment for the backup chain.
Am I doing something horribly wrong, or is this expected behaviour from duplicity?