is this procedure still the recommended approach to create daily/weekly/monthly/yearly snapshots?
I.e. separate ZFS snapshot tasks for daily/weekly/monthly/yearly with a name format like:
auto-hourly-%Y-%m-%d_%H-%M <— set to expire in 2 DAYS
auto-daily-%Y-%m-%d_%H-%M <— set to expire in 1 MONTH
auto-monthly-%Y-%m-%d_%H-%M <— set to expire in 4 YEARS
auto-yearly-%Y-%m-%d_%H-%M <— set to expire in 12 YEARS
Having read that linked thread, I don’t quite understand why it is suggested to time snapshots properly. Also following statement irritated me:
using the same naming schema for different snapshot tasks with different expirations (on the same dataset) can risk destroying your long-term snapshots
Hence I am asking for best practices. Also: Does TrueNAS web interface provide “smart” backup rotation via single task in the meanwhile?
My goal is to have a ZFS-native backup rotation similar to restic’s
--keep-daily n
--keep-weekly n
--keep-monthly n
--keep-yearly n
The reason you want each snapshot task to have a different naming scheme is to avoid overlapping names. Without anything in the snapshot’s name to differentiate it from the naming schema of another task, there’s no safeguard against it being pruned when zettarepl runs in the background and checks for which snapshots to destroy.
It’s explained in the thread (which I assume is what you meant to link against) why this happens if you temporarily disable or remove an existing snapshot task which shares the same naming schema as another task.
Nope.
As long as you use a unique naming schema for each snapshot task, they’ll be safe from unintentional pruning, even if you later disable, rename, pause, or delete another task.
Unfortunately, there is no “smart” way to create a single snapshot task that staggers them based on frequency and lifetime. You’ll need to create multiple snapshot tasks.
hour for a day
day for two weeks
week for a month
month for a year
In practice we don’t use ‘hour for a day’ all that much as by the time the user has realised they need recovery, logged a call and its reached me or the team we are into ‘day for two weeks’. Month for year is also not used that much and actually annoys some people as when they try to free up space as they have hit their quota they don’t immediately get the space back however it has saved some users over the years so we like to keep it as standard. We can and do manually delete the ‘month for a year’ snapshots if requested.
The zettarepl utility relies on names only, and thus requires that the naming convention includes all five %Y%m%d%H%M fields (order and separators, or lack thereof, are fully up to you). In my experience, having the same naming convention for different snapshot tasks with different retention times does work as intended.
Two caveats: I’m on CORE, and have not tested whether SCALE introduced breaking changes, and I do PULL replication, so “pausing” replication is done by simply shutting down the backup server.
Just to make my life easier when searching snapshots I tend to add the retention to the end of the snapshot name for example %Y%m%d%H%M-1d or %Y%m%d%H%M-2w.
I am not sure what you mean here … Nobody sent me.
Right, corrected! And yes, it’s the one you mentioned.
Thanks for the explanation. So, after this longer time, would you say that your suggested approach proved of value for “smart” backups?
It is a bit sad, that configuration is not as convenient as in other tools. You get max. factor 5 for hourly/daily/weekly/monthly/yearly variants of the same dataset for initial setup and maintenance work, which might be cumbersome, depending on the amount of of backup tasks . But I could live with that.
Appreciated, it’s on my watch list.
Ah OK, so as long as the name with all combined parameters is unique, there won’t be unintended auto-deletion of snapshots, right?
After a bit more testing: Easiest solution probably is to adjust TrueNAS hourly/daily/weekly/monthly presets in the webinterface + add a new yearly task.
I used proposed name format and appended corresponding time constants (...-hourly-... etc.) for uniqueness. Run hours are varied for all, so that backup tasks don’t run in parallel.
Viewer warning: There’s a jump scare at 16:23 into the video. Do not watch this video alone at night.