dataset with a local backup plan (org.znapzend:recursive=off) wrong debug output

[moetiker]

I set zfs set org.znapzend:recursive=off fast/vm/test and run

znapzend -d --runonce=fast/vm

=== getBackupSet() : got 1 dataset(s) with a local backup plan
=== getBackupSet() : got 1 enabled-only dataset(s) with a local backup plan

but there is also the output:

[2020-09-22 12:14:40.94208] [1591] [debug] sending snapshots from fast/vm/test to slow/backup/vm/test
# zfs list -H -o name -t snapshot -s creation -d 1 fast/vm/test
# zfs list -H -o name -t snapshot -s creation -d 1 slow/backup/vm/test

it is only the output, the system does the right thing and creates no snapshot backup for fast/vm/test

[jimklimov]

Curious, OTOH it might be the latter action checking if the send of particular child dataset is enabled (if it is, then probably it should log that it aborted this datasend send as it is disabled, though).

The former is (probably) the discovery of "fast/vm" itself, which locally defines the backupSet policy and is "got" as such. Not sure OTOH what the "enabled-only" might refer to :)

[jimklimov]

Yes, so here https://github.com/oetiker/znapzend/blob/26be7912aa59995e9f8d3078f0ccbc684ae441b7/lib/ZnapZend/Config.pm#L188-L191 the getBackupSet() routine can work with an $enabledOnly argument. If it is not set, it returns all backupSets that have a local policy definition (or inherited, if another argument is specified for that); if it is set, filters the list by picking only those backupSets that have the policy enabled in their root definition: https://github.com/oetiker/znapzend/blob/26be7912aa59995e9f8d3078f0ccbc684ae441b7/lib/ZnapZend/Config.pm#L230-L235 So that's the "1" in first snippet.

The other message comes from https://github.com/oetiker/znapzend/blob/213bb7f4c10085745499968b95e826d1f207b7db/lib/ZnapZend.pm#L371-L375 iterating "srcSubDatasets", skips the large --since handling block, and goes into sendRecvSnapshots() https://github.com/oetiker/znapzend/blob/26be7912aa59995e9f8d3078f0ccbc684ae441b7/lib/ZnapZend/ZFS.pm#L496

Not sure where it bails then, there are several sanity checks that quietly return from this routine after looking for common snapshots...

[jimklimov]

Probably makes sense to skip the (grand...-)child of a source dataset which is explicitly disabled early in the handling routine; I think something like this was discussed in some issues or PRs earlier in the year, probably where we look for inherited dataset props up and down in the tree.

One caveat is that if later there is a deeper child that is again enabled, we can not rely on all versions of ZFS implementations to create intermediate destination datasets if they are currently missing and we are sending them for the first time - then the intermediates have to be created manually (or even by system's zfs create -p if available).

And then there is a problem of someone enabling replication of those intermediate datasets, and there's no compatible snapshot to send and none where to revert the "live" intermediate dataset on dest by zfs recv -F though not sure this is a practical problem (maybe it can just overwrite the link in the middle of the chain).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.