-
-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
snapshot tag/annotation #151
Comments
Can't you just use --snapshot-format to add a static string to the end? |
say I'd have three different severs taking snapshots with --snapshot-format each like and I want all to be thinned together ignoring whether it is owner1 or 2 or 3 For this we need |
In your code above, shouldnt the string be exactly the same? So if you specify owner1 it still will ignore the snapshots of owner2 and owner3? |
here's a quick bit of code to explain
first assertion passes in digitalsignalperson@c3d8a2f I achieved this "wildcard" by chopping off the part on the end |
Just had the similar idea and came here to post a feature request, but saw this issue existed, so I'll describe my thought in a comment here so they can be considered. My use case is attaching metadata to a snapshot, to "annotate" it. These annotations provide the option to better distinguish snapshots other than based on their timestamp. For example, on my workstation I have set up automated snapshots. So the idea I just had was that if it was possible to annotate my snapshots, I could easily find the one I'm looking for. Including this annotation in the snapshot name as a suffix is then the most straightforward implementation I can think of for making it easy to use with other ZFS tools, which usually display snapshot names.
vs
Knowing which snapshot was made by which action makes it a lot easier for me (a human) to figure out which one I want to access. For example, when I discover an issue after an update and I want to roll back my OS, I usually can make a bit of a guess which timestamp represents the snapshot I want. But sometimes I had a bunch of reboots, installed a number of different packages, and also some timed snapshots were made. Then there's a bunch of timestamps which are fairly close together, and while my brain has no problem figuring out which snapshot I want ("the one before I installed that broken kernel driver"), I might have a harder time figuring out which one that is based on the timestamp. The snapshot name is the easiest way to place this, since it works out of the box with most tools as opposed to having to query the snapshot properties. For example from ZFSBootMenu. I would imagine it to be an optional parameter, Alternative would be to use multiple naming formats. But from my understanding that means they won't be thinned together, and I might have to add additional cronjobs for each and every annotation I use for them all to be thinned, backed up to an external server, etc. Hope that explains my use case! |
I've been using this branch master...digitalsignalperson:zfs_autobackup:v3.1.2-hacks in my replication setup for a year now like so with
or instead of "nas", different computer names (or in your case boot, packagemanager, etc.) which results in snapshots like
etc. and the snapshot thinning works as if everything after and including the |
Something I'm trying out similar to
--set-snapshot-properties
is adding a suffix to the snapshot format which is chopped off when determining which snapshots are "ours"digitalsignalperson@c3d8a2f
Not sure if it's too bespoke to make a PR, but throwing it out there. Convenient to see some extra metadata in the snapshot name but ignore it for purposes of thinning etc.
The text was updated successfully, but these errors were encountered: