Skip to content
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 suffix? #151

Open
digitalsignalperson opened this issue Jun 21, 2022 · 6 comments
Open

snapshot suffix? #151

digitalsignalperson opened this issue Jun 21, 2022 · 6 comments

Comments

@digitalsignalperson
Copy link
Contributor

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.

@psy0rz
Copy link
Owner

psy0rz commented Aug 19, 2022

Can't you just use --snapshot-format to add a static string to the end?

@digitalsignalperson
Copy link
Contributor Author

say I'd have three different severs taking snapshots with --snapshot-format each like
something-%Y-%m-%d_%H-%M-%S_owner1
something-%Y-%m-%d_%H-%M-%S_owner2
something-%Y-%m-%d_%H-%M-%S_owner3

and I want all to be thinned together ignoring whether it is owner1 or 2 or 3

For this we need is_ours() to return True, which means self.timestamp must not throw an exception.
self.timestamp will try to calculate
time_secs = time.mktime(time.strptime(self.snapshot_name, self.zfs_node.snapshot_time_format))
which will not be compatible with 3 different suffixes

@psy0rz
Copy link
Owner

psy0rz commented Aug 19, 2022

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?

@digitalsignalperson
Copy link
Contributor Author

here's a quick bit of code to explain

snapshots_1 = [
'something-2022-08-19_12-00-00_owner1',
'something-2022-08-19_12-01-00_owner1',
'something-2022-08-19_12-02-00_owner1',
]

snapshots_mix = [
'something-2022-08-19_12-00-00_owner1',
'something-2022-08-19_12-01-00_owner2',
'something-2022-08-19_12-02-00_owner3',
]

def is_ours(snapname):
    try:
        timestamp(snapname)
        return True
    except:
        return False

snapformat = 'something-%Y-%m-%d_%H-%M-%S_owner1'

def timestamp(snapname):
    time_secs = time.mktime(time.strptime(snapname, snapformat))
    return time_secs

assert all([is_ours(snapname) for snapname in snapshots_1])

assert all([is_ours(snapname) for snapname in snapshots_mix])

first assertion passes
second assertion fails - I want this to pass. I want a set of snapshots matching e.g. 'something-%Y-%m-%d_%H-%M-%S_owner*' with a wildcard at the end

in digitalsignalperson@c3d8a2f I achieved this "wildcard" by chopping off the part on the end

@DvdGiessen
Copy link

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. zfs_autobackup is automatically called to make snapshots on every boot, as well as on a timer, and also whenever I install/update/remove packages using my distro's package manager. And perhaps even some more times when I decide to make extra snapshots manually.

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.

zroot/ROOT/default@zfsautobackup-20230704215550
zroot/ROOT/default@zfsautobackup-20230704215635
zroot/ROOT/default@zfsautobackup-20230704215802
zroot/ROOT/default@zfsautobackup-20230704215926
zroot/ROOT/default@zfsautobackup-20230704215928
zroot/ROOT/default@zfsautobackup-20230704215952
zroot/ROOT/default@zfsautobackup-20230704220045

vs

zroot/ROOT/default@zfsautobackup-20230704215550-boot
zroot/ROOT/default@zfsautobackup-20230704215635-packagemanager
zroot/ROOT/default@zfsautobackup-20230704215802-boot
zroot/ROOT/default@zfsautobackup-20230704215926-packagemanager
zroot/ROOT/default@zfsautobackup-20230704215928-timer
zroot/ROOT/default@zfsautobackup-20230704215952-packagemanager
zroot/ROOT/default@zfsautobackup-20230704220045-manual

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, --set-snapshot-annotation "packagemanager" for example. It should not using this annotation for any of the pruning logic etc, and be optional (still work with snapshots that don't have an added annotation).

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!

@digitalsignalperson
Copy link
Contributor Author

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 zfs-autobackup args:

SNAPFORMAT=zab-%Y-%m-%d_%H-%M-%S

    --snapshot-format ${SNAPFORMAT}_nas \
    --snapshot-suffix-char _ \

or instead of "nas", different computer names (or in your case boot, packagemanager, etc.)

which results in snapshots like

rpoolx/dataset@zab-2023-06-30_17-02-00_nas
rpoolx/dataset@zab-2023-07-01_17-01-54_thing1
rpoolx/dataset@zab-2023-07-02_17-00-50_thing2
rpoolx/dataset@zab-2023-07-03_17-02-08_nas
rpoolx/dataset@zab-2023-07-04_02-02-15_etc

etc. and the snapshot thinning works as if everything after and including the _ suffix char doesn't exist,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants