I’ve got a backup, ID 9, which I’ve deleted the snapshot folder “9”, and have run a schdueled prune -exhaustive job, but the hard drive utilization size didn’t change.
Did I mess something up here? I left all the other prune settings default, and added option -exhaustive. Job says it completed, hard drive in the array shows the same size usage as before the job ran. Backup was about 8TB, so I would expect to have reclaimed that space in the array if the files were indeed deleted.
Confirm your price command contains both -a flag and -exhaustive.
Review the prune logs if there are any issues there.
What is the target? There was some weirdness with using shared google drive account where under certain circumstances non-admin user was unable to delete anything.
I’m not sure if -keep flags can affect the outcome of the -exhaustive flag. Another possibility is that it’s a safety feature and you would need to run this prune several times to clear out the data. Third possibility is that there is a lot of overlap in data being backed up so no chunks were deleted. What do you see in prune log?
If you absolutely need it to clear it now with no delay – ensure no other duplicacy instance is touching the storage and run prune -a -exhaustive -exclusive. All concurrency safety mechanisms will be off and the data will be deleted immediately.
Unraid is Linux, NTFS is Microsoft windows filesystem, NTFS driver on linux is a second attempt at reverse engineering the filesystem and is by necessity garbage. I’m not saying this is causing issues now (even though it could) but it will definitely cause issues later. I woudl format the volume to ext4.
Sorry, my phone corrected to NTFS. The share is NFS on an xfs array.
Where do I find the logs?
IIRC events on dashboard are clickable and lead to logs.
For anyone looking to do the same in the future. Delete the corresponding ID of the backup you are looking to get rid of under the /snapshots directory, then create a prune job with the following options ONLY.
-id “number of id you deleted in snapshots” -exclusive -delete-only
These options mean:
-id #: This specifies that the prune command should only apply to the backup with ID <# you wish to delete>.-exclusive: This ensures that only the chunks exclusive to backup ID # will be deleted.-delete-only: This will delete the chunks without touching the other snapshots, which is useful since you’ve already deleted the snapshot folder manually.Super easy. Hope this helps anyone else.
This is false. Exclusive flag turns off concurrency aware safety and assumes the current prune operation has exclusive access to the datastore.
If id does not exist this will fail. You want to pass -an and -exhaustive flags if you have already deleted the snapshots manually from the store.
Alternatively, you can just prune full range of revisions from the specific snapshot to delete all of them and avoid exhaustive prune.
This is also false. That flag does something else entirely.
Well, it worked this way beautifully. Thanks!
It worked because it was a second invocation of prune that removed fossils collected during first invocation:
This is two-step fossil collection process that you can read about in the Duplicacy paper. By providing -exclusive flag you have bypassed it.
It worked despite your options provided in the second run; in fact, all those options were effectively ignored, as they only applied to the snapshot ID that no longer exists.
Please don’t give dangerous and misleading advice. Misunderstanding delete-only flag is harmless, but misunderstanding the -exclusive flag can result in permanent data loss.
I linked to the docs in the previous comment.