How to truly delete snapshots / backup IDs in a storage?

[doher]

I’m a little confused - let’s say I changed my mind, and no longer want to backup my local music. The repository is my local music folder, correct? The snapshot-id is ‘local-music’. They are stored on a destination drive (storage). I want to delete all the backed up revisions for that snapshot-id from the storage. I am using the web UI.

Am I correct that deleting the ‘ID’ under the backup tab on the web UI will just remove it as an option from the web UI, not delete the actual snapshot?

And am I correct that running a Prune command in the web UI will merely prune snapshot revisions according to the schedule - so I’ll have to wait for those snapshots to be deleted on schedule?

Thanks! I know I’m misunderstanding something!

[saspus]

You would need to physically delete snapshots/local-music folder manually from your target storage, and then run “prune” with the flag “-exhaustive”. It will take a long time but will purge the chunks that are no longer used by any revision from the target storage.

@doher

Am I correct that deleting the ‘ID’ under the backup tab on the web UI will just remove it as an option from the web UI, not delete the actual snapshot?

Yes.

@doher

And am I correct that running a Prune command in the web UI will merely prune snapshot revisions according to the schedule

Yep. Prune without -exhaustive flag will only read existing snapshots and remove chunks that were part of removed snapshots but are no longer needed. The exhaustive flag tells prune to look at all chunks, and remove orphans.

You can probably set the prune schedule with -keep 0:0 (or 0:1 if that does not work) to effectively prune all revisions from the snapshot ID. (I haven’t tried it though)
If I needed to purge the whole snapshot with all its revisions – I would have deleted it from storage and then cleaned up the datastore with -exhaustive prune.

[cuhztzen]

So just to be sure nothing’s changed in the past three years…
In my first few days of using duplicacy about one year ago or so, I was backing up all the subdirectories of “Parent Directory A”. Now I just back up the entire parent. So if I want to clean up my backups I can delete all the subdirectories (that appear at the same level as the parent in the snapshots folder) from snapshots and run a prune -a -exhaustive and the orphaned chunks from the subs will be deleted without issue (as long as there are no concurrent processes)?

[saspus]

Yep, nothing changed. It’s core design.

@cuhztzen

I was backing up all the subdirectories of “Parent Directory A”. Now I just back up the entire parent.

Emmm… What’s the difference?

@cuhztzen

So if I want to clean up my backups

Since it’s essentially the same data – I don’t think cleaning up anything will free you any meaningful amount of pace – it’s all deduplicated.

@cuhztzen

delete all the subdirectories (that appear at the same level as the parent in the snapshots folder)

I’m not sure this is accurate. The snapshots folder contains subfolders, corresponding to snapshot IDs, which in tern contain just plain files corresponding to revisions.

If you want to entirely get rid of the whole snapshot with all its history – yes, you can delete the corresponding to the snapshot name folder and then run prune -a -exhaustive. If you want to get space back right away, you have to make absolutely sure that no other process is touching the datastore and add -exclusive flag to the prune. It will turn off all safety and “just do it”

But if I were you I would keep the backup history of subdirectories. What if tomorrow you discover that one of the files has rotted five months ago? You would be able to go to your per-subdirectory backup and restore it. You can always delete data, and disk space is cheap. Nobody ever regretted “I wish I deleted it sooner!”