I backup to an sftp server on my LAN. As a result of the recent 2.6.2 release and bugfix I ran the suggested duplicacy check on my repo. All commands here are run as root on the server itself.
(Have also read Invalid chunks in 1/4 snapshots and posted How long does check -chunks take? in relation to this.)
My inital check “duplicacy check -all -chunks -threads 4” turned up a corrupted chunk. I decided to take the path of removing it and any snapshots which contained it. (Most recent snapshot doesn’t contain it and its limited to one snapshot ID.)
So I manually deleted the problem chunk. Reran check and found which snapshots had missing chunks: 7,8,9,10,11 and 12 out of 13 total snapshots.
I deleted the snapshots:
duplicacy prune -id oszen -r 7-9
duplicacy prune -id oszen -r 10-12
but the latter didn’t seem to work properly so I did them seperately:
duplicacy prune -id oszen -r 12
duplicacy prune -id oszen -r 10
duplicacy prune -id oszen -r 11
ran prune to clean up:
duplicacy prune -id oszen -exhaustive -exclusive
all of which seemed to work normally but a list:
duplicacy list -id oszen
shows snapshot 11 is still there!
Storage set to /backup/duplicacy/chroot/repo
Snapshot oszen revision 1 created at 2019-12-20 15:07 -hash
Snapshot oszen revision 2 created at 2020-01-07 14:10
Snapshot oszen revision 3 created at 2020-01-23 09:16
Snapshot oszen revision 4 created at 2020-01-30 15:31
Snapshot oszen revision 5 created at 2020-03-10 23:23
Snapshot oszen revision 6 created at 2020-03-19 10:16
Snapshot oszen revision 11 created at 2020-06-10 19:22
Snapshot oszen revision 13 created at 2020-08-03 22:5
I’ve actually been though the whole delete/prune/list two or three times but snapshot 11 refuses to die.
About to delete the metadata cache and try again, but otherwise I’m at a bit of a loss…