Hi everyone. Apologies if this has been covered before - I might have missed a previous discussion or some details.
While browsing the forum, I came across an idea regarding backup retention. My AI assistant pointed me to Issue#3195, but I believe my suggestion is slightly different. I think it would be very useful to have a “lock” feature for specific snapshots.
There are cases where I need to preserve a particular backup without altering the global backup plan or editing scripts. Essentially, I want to manually ‘lock’ a snapshot to prevent it from being deleted until I explicitly unlock it. While S3 offers deletion policies, I’m looking for a more direct, manual way to ensure specific snapshots are kept regardless of automated cleanup rules.
I presume you now about forget --keep-tag which you could have always applied to your forget commands with a specific tag you chose to represent “locked” snapshots, e.g. forget --keep-tag locked? Any snapshot you put that tag on will then be kept regardless of the rest of the policy.
I see your point about --keep-tag, and that’s what I’m using now. But for me, it feels like a workaround rather than a solid safety feature.
The real issue is ‘Silent Success’. If I make a typo in a tag within my cron script, forget will just happily run, find no matches, and delete the snapshot I was trying to protect. If we had an internal lock state, a typo in the ID would cause an immediate error, stopping the process. That’s a huge difference in peace of mind.
To give you a real-world example: whenever I need to perform a data restore, my first step is to take a ‘pre-restore’ backup of the current (broken) state. It’s a vital safety net in case I need to check something from the version I’m about to overwrite. In the middle of a stressful recovery, I want to just lock that specific snapshot and know it’s safe. I don’t want to worry about a nightly cron job pruning it because I forgot to update the scripts or messed up a tag while under pressure.
Also, I believe that if I lock a snapshot, it should be ‘invisible’ to the retention policy. If I want to keep the last 5 backups, I want exactly 5 fresh ones, plus whatever n snapshots I’ve manually locked for the long term. Using tags makes this math messy because they ‘steal’ slots from the regular rotation.
I’m basically looking for a way to make the snapshot ‘protect itself’ from the inside, so I don’t have to rely on a fragile external script to remember which tag is which.
Another option is to always use --group-by host,tags. I now use this in all of my retention policy scripts for several reasons. For example, it’s common for a logical set of backups to have paths that change over time, but the default --group-by host,paths would treat the snapshots with a different set of paths as a different backup set. And, as you’ve found, this makes it too easy for a forgotten --keep-tag to remove snapshots you wanted to save (I use keep for such snapshots).
With --group-by host,tags, it’s extremely unlikely that your “locked” snapshot in this example would be removed. This is not to say that your proposal doesn’t have value, but rather this is a suggestion for something you can do right now that will make it far less likely to accidentally delete a snapshot – you would effectively have two different layers of protection instead of one.