znapzendzetup disable on child about znapzend HOT 21 CLOSED

by now, znapzend does not support to exclude child datasets when running w/ a recursive policy. you'll have to set up all child datasets individually (non recursive) if you want to exclude some of them....

from znapzend.

this can be labeled as "feature-request" so, because I see znapzend is already looping on each child datasets for zfs send/recv. It may be simple to skip one if org.znapzend:enabled=off
I'll dig into the source code and see if I can make a pull request on this.

EDIT - the snapshot itself is recursive and will be performed on the pointed child ... Will see what can be done

from znapzend.

@odoucet, did you get anywhere with this?

I think the request would be interesting even if it only applied to overriding the DST option. I can live with local snapshots for transient datasets as long as they're not sent to a backup server.

from znapzend.

did not make any progress at all... I was busy with something else .. Then totally forgot about this one.

from znapzend.

Right now, i'm keeping 2 datasets for this.

e.g.

tank/critical
tank/non-critical

tank/critical is being znapped recursively, the other won't get znapped anyway.

zfs rename -p tank/critical/disable-me tank/non-critical/disable-me

from znapzend.

This would be a killer feature.

from znapzend.

I am not good in perl, but I understand that the way to go is to do the regular snapshot and, right after that (if recursive), check which child ZFS have the flag, e.g., org.znapzend:enabled set to off.... nope?

from znapzend.

yes, the send operations are 'per fs' anyway, so I think the change should not be all the big

from znapzend.

@oetiker: I have written a possible patch addressing this issue, but I do not have around a setup to test it. Do you? How can I send it to you (the whole diff is 50 lines, but I am not very skilled in Perl, and I guess it can be made smaller)? If you do not have any testbed around I will create a VM and so... but yeah, Sunday morning, I guess... :-D

from znapzend.

the tests we have are all included with the package ... they work by using simulated version of the zpoo,zfs,ssh commands ...

from znapzend.

if you create a PR I will be glad to review

from znapzend.

I have discovered a bug on my commit: Seems that, when znapzend gets reloaded, it refreshes all the plans. As it finds the property org.znapzend:enable on a child ZFS, it considers that to be a dataset... but as there is only that property, it reports it and fails. I see two ways to solve this, maybe you can advise for one (or propose another)?

a) On Config.pm, line 71. Instead of "die" if a dataset has properties missing, I feel more inclined to notify it as a warning, and continue with the next dataset.

b) For the children ZFS, to define their backup plans. Might this pose a problem if the parent dataset has the recursive flag set, and not the children ZFS?

from znapzend.

Hello everyone,
I have a new solution based on the item a) from the previous comment. From my point of the view there is the best compromise how to do it by adding a new flag in our situation. It is a kind of the workaround when this source code isn't in objects. I used "invisible=on" for a inherit child in my patch. I attached it here:

0001-The-second-patch-for-znapzendzetup-disable-on-child-.patch.txt

Please, look at it. I am not a perl geek.
Thanks, for your feedbacks.

from znapzend.

hi @speedytom please create a PR, then it is much simpler to look at your idea

from znapzend.

@speedytom Hi, one question: Doesn't your solution require to fully populate those datasets that want to be skipped? The idea, AFAIU, is to discard the descendant datasets with the minimum required actions, and I think that making full use of recursive datasets is a must.

I checked in a patch few days ago that addresses that by:
a) if any dataset is missing properties, this is not an error anymore but a warning. Is reported and that dataset is skipped (and this happens only when znapzend is run or it is reloaded, so is not very intrusive).
b) In the snapshoting process: after doing the snapshot, on a dataset with "recursive" flag on, descendant datasets are checked for the "enabled" flag to "off", and those are set for removal (And, thus, not send).

I think a cache should be populated with this information (the disabled descendants of a recursive dataset), so that only when checking the backup these are traversed but... yeah, still no time for it.

from znapzend.

@flixman how about detecting that the enabled = no property is the only one set and then NOT complaining about that fact as it is a valid state

from znapzend.

Thanks guys for your quick feedback. I appreciate it. I will try explain it in detail my intent. I wanted distinguish between parents, child and other datasets. Znapzend works without any problem with the first patch from my point of view. I wanted fix znapzendzetup. I would like see parent and children datasets when I run command "znapzendzetup list". My patch should suggest lets say a new feature. It was the first step to add new flag to all children datasets. Maybe the new flag "invisible=on" hasn't correct name. What about name "children"?

I have to say that I am beginner with ZFS and znapzend. Your work is really great. Is it possible send you some patches from time to time?

from znapzend.

@oetiker Good! I fill prepare a PR for tomorrow afternoon :-)

from znapzend.

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.

from znapzend.

Still a wanted feature.

from znapzend.

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.

from znapzend.