Delete a backup - Prune fails

[Tortuosit]

Hi, I’m in the process of creating a new backup with less complexity (per-file encrypted 7z via batch, for loop on Win).

Now I want to completely delete all backup revisions of a specific backup id. Of course it fails. There’s always something failing. I came to the conclusion, under no circumstances a third party (family) would be able to restore my Duplicacy backup in case of need.

The prune command is sent via WebUI: “-id S_Bilder -r 1-1000 -exclusive”

Error message below. I looked into restore, seems like all revisions are still there.

I could delete the whole storage folder but I don’t want, because there’s much more in there.

Options: [-log prune -storage WD50 -id S_Bilder -r 1-1000 -exclusive]
2022-08-23 20:19:44.751 INFO STORAGE_SET Storage set to C:/Disk/WD50/Backup/Duplicacy
2022-08-23 20:19:45.096 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 1
2022-08-23 20:19:45.352 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 2
2022-08-23 20:19:45.609 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 3
2022-08-23 20:19:45.855 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 4
2022-08-23 20:19:46.080 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 5
2022-08-23 20:19:46.298 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 6
2022-08-23 20:19:46.528 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 7
2022-08-23 20:19:46.770 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 8
2022-08-23 20:19:47.013 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 9
2022-08-23 20:19:47.252 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 10
2022-08-23 20:19:47.491 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 11
2022-08-23 20:19:47.743 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 12
2022-08-23 20:19:47.991 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 13
2022-08-23 20:19:48.239 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 14
2022-08-23 20:19:48.485 INFO SNAPSHOT_DELETE Deleting snapshot S_Bilder at revision 15
2022-08-23 20:19:53.598 ERROR DOWNLOAD_CHUNK Chunk 5c972e509920a22d7b826e4bd4dc96b85e991a3b15b310db21f37ee90556b7b0 can't be found
Chunk 5c972e509920a22d7b826e4bd4dc96b85e991a3b15b310db21f37ee90556b7b0 can't be found

[saspus]

Ok, the chunk not found issue is my “favorite” one is a result of previously interrupted prune. The ghost snapshots, that should have been deleted but were not, are failing the check, because some of their chunks have been deleted. @gchen, please prioritize fixing it. This is very unnerving to see check fail. And that covers 99.9% of cases when check fails, and casts shadow on the duplicacy reliability. I had never had duplicacy lose data, and yet I got buried in these superficial check failures, until I stopped pruning.

Now I want to completely delete all backup revisions of a specific backup id.

The easiest for you would be to delete the folder snapshots/<that_id> from the target, and then prune -exhaustive, to remove now-orphaned chunks.

You can also add -persist flag to check, so it does not give up on first failure, then find which revisions it complains about, and delete just those revision files from storage, followed by exhaustive prune.

@gchen – this shall be part of automated healing function. On the other hand, if the previous issue is fixed – it won’t be needed.

[sevimo]

Isn’t running -exclusive the root issue here? It seems to me that no matter what you do, exclusive prunes are just not resilient to interruptions, and I am not sure they can be made so for 1 step removal. If you remove snapshot first and chunks after, then you have unreferenced chunks on interruption that can only be removed by -exhaustive (=BAD). If you remove chunks first than snapshot after, then you get missing chunks on interruption (=BAD). Bottom line is, using exclusive=BAD.

I don’t think something like that should happen in a regular 2-step pruning that involves fossilization first, then snapshot removal and only then removal of fossilized chunks (later).

[Tortuosit]

Thanks, I did as you recommended. It worked - after I deleted old Backup-ID folders, which I am happy I have found. This solved another problem for me. There were always non-existent, old backup-IDs listed in some parts of the UI and I found no way to remove them. Now finally those remains are gone.