Feature: Allow different options for distinct datasets within one backup group

[tuffnatty]

My use case: I would like to specify --min_change=212993 for one dataset and --min-change=1 for another, but still need to snapshot them together in atomic manner, no matter how many snapshots were selected.

[digitalsignalperson]

also thinking about how to manage [min-change, allow-empty, keep-source] for different datasets

I don't need atomic-ness, so I guess I could create one group per unique set of those parameters just for standalone snapshotting

Could imagine using dataset properties as a way to store the rules and allow for inheritance or local setting.

like zfs set autobackup:min-change=1 rpool/mydatasets and zfs set autobackup:min-change=212993 rpool/mydatasets/the-unique-one etc.

reminds me of the debate in https://github.com/psy0rz/zfs_autobackup/issues/113 where sometimes you want the config in the command arguments, other times you want it in the dataset properties, and may be applications for both...

[psy0rz]

indeed..maybe the commandline specify the default and global settings, while properties can overrule some settings per dataset?

[Scrin]

A way to overrule certain "settings" on a per-dataset level would be useful in some scenarios indeed, however ideally that should be done in such a way that it can be overruled only for specific "backup tags" (or whatever the proper terminology is).

For example you may have something like autobackup:offsite=true and autobackup:onsite=true on the same dataset(s) and you want to overrule certain per-dataset settings only for either onsite or offsite backups but not both, so something like autobackup:min-change=1 wouldn't work here

[psy0rz]

@Scrin yep i was thinking about that as well.

perhaps this would take the form autobackup:offsite:min-change=1 ?

or autobackup:offsite.min-change=1 ?

i think the : is mean for namespace seperation, so maybe the second example is cleaner?

[Scrin]

Either would work and be fine from ZFS point of view, the thing with the : is that it's a requirement to have at least one : on user properties to ensure they will never collide with native properties which will never have them, though the expected convention is indeed to take the form of module:property when implementing this, but it's not a requirement and the documentation explicitly states that this is not enforced.

With that in mind, autobackup:offsite.min-change=1 would indeed be cleaner than autobackup:offsite:min-change=1 as long as the names are simple ones like "offsite". I wouldn't be surprised if there are deployments utilizing names like autobackup:offsite.primary=true and autobackup:offsite.secondary=true or similar in which case it would be both more confusing and actually potentially break existing setups.

A third option would be something like autobackup.min-change:offsite=1 which would be most robust in the sense that it should not break no matter what naming convention you have used for the backups, but that is probably the least clean option of the all.

Personally I'm fine with any of these options, but these are some things to consider. If I were to choose, I would use autobackup:offsite.min-change=1 form as it's the cleanest and release this feature in a new major version (or whatever is appropriate for introducing potentially breaking changes in your versioning scheme) and declare new "naming requirements"; meaning forbidding the use of . in the names.

[psy0rz]

i can also imagine setups that use autobackup:host.server.net=true

ill check later what currently is allowed in zfsbackup and which snapshotnames are valid.

[psy0rz]

what about: autobackup:offsite@min-change=1

[Scrin]

According to the documentation (linked above), @ is not a valid character in property names. Something like autobackup:offsite+min-change=1 could work though, but I don't find that any cleaner than autobackup:offsite:min-change=1

[psy0rz]

indeed..i thought i tried a property with an @ but apparently not.