I have an hourly backup with a prune policy as follows:
-keep 0:365 -keep 24:30 -keep 30:7 -a -threads 30
I believe this should result in no revisions older than a year, then two per month (ish), one per day (ish) then one per hour.
The important thing is that there are a number of backup ids which i stopped using 2-3 years ago and waited for them to gradually get pruned, but the last revision for each of them is still hanging around and not getting pruned.
I’ve also tried pruning with -exclusive to no avail.
I don’t see any reference to restrictions pruning the only remaining/latest revision on the prune documentation, so is there something i should be aware of?
duplicacy prune -keep 30:7 # Keep a revision every 30 days for revisions older than 7 days
duplicacy prune -keep 24:30 # Keep a revision every 24(???) days for revisions older than 30 days
duplicacy prune -keep 0:365 # Keep no revisions older than 365 days
Firstly, Duplicacy can’t prune down to the hour - days only. (Although you can leave hourly snapshots unpruned.)
Next, your interval:age parameters should decrease together - i.e. when you sort them in decreasing order of age (as you must), then interval should decrease as well (with the exception of 0:m). So 24>30 doesn’t make sense.
If you want nothing older than a year, two per month (after a month?), one per day (after a week?), then:
duplicacy prune -keep 0:365 -keep 14:30 -keep 1:7
duplicacy prune -keep 1:7 # Keep a revision per (1) day for revisions older than 7 days
duplicacy prune -keep 14:30 # Keep a revision every 14 days for revisions older than 30 days
duplicacy prune -keep 0:365 # Keep no revisions older than 365 days
With this schedule, you still get to keep hourly snapshots for a week (change 1:7 to 1:1 if you only want them for a day and are running hourly simply to be as up-to-date as possible).
Lastly, you should never use -exclusive in conjunction with -keep - as you can end up with no revisions left and an empty storage. Duplicacy, without -exclusive, will always keep the last revision - as protection against this situation.
Under normal circumstances, deleting the last revision effectively means deleting everything (why would you want to keep older revisions?), so deleting the last revisions, and a snapshot ID out of existence is left up to the user to do manually.
Thanks for the clarification, i’d made a typo ( -keep 30:30) then tried to justify my typo , but it doesn’t seem like i’d need that if i have -keep 30:7.
Anyway, that’s not been the problem at hand
Lastly, you should never use -exclusive in conjunction with -keep - as you can end up with no revisions left and an empty storage. Duplicacy, without -exclusive, will always keep the last revision - as protection against this situation.
Could you clarify this further? You say i should never use these together, but empty storage and no revisions seems to be exactly what I want? (at long as the backups that still have revisions are not deleted)
Either way, these two flags together didn’t have any effect and the last revision remained.
Even attempting to manually prune the revision had no effect. (prune -r xxxx)
I am pretty sure the last version is not pruned because it can be used by ongoing processes of concurrent clients, not sure if -exclusive impact that or not. But if you want to remove several obsolete snapshot ids completely, here is what I would do. Not sure if this is an endorsed practice ;), but it should work.
Go to your storage, and simply remove all your obsolete snapshot ids under /snapshots folder. Then run prune with -exhaustive flag, and it should remove all the orphaned chunks. Done.
, but it doesn’t seem like i’d need that if i have -keep 30:7.