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

Is there no support for recursive send? #438

Open
jimklimov opened this issue Oct 14, 2019 · 2 comments

Comments

@jimklimov
Copy link
Contributor

@jimklimov jimklimov commented Oct 14, 2019

Looking at code around

@cmd = ([@{$self->priv}, 'zfs', 'send', @sendOpt, '-I', $lastCommon, $lastSnapshot]);
(and at processes actually running on my system) I think znapzend only sends an incremental or full update for lastSnapshot of one dataset. So for a fairly zfs-treeish system with hundreds of datasets, it makes (eventually, not at once) hundreds of zfs send|mbuffer|(ssh|)zfs recv forks, each with its latency hit of zfs processes talking to kernel for several seconds or minutes to begin actual I/O (Related to #104 - similar use-case).

If we have a recursive = on setting for snapshots creation and cleaning, why not use it for sending? At least, if it does succeed, we are more quickly done. If it fails, we can re-evaluate which datasets and snapshots exist on both sides, and catch up one-by-one to get at the specific errors.

The #104 issue discussion goes further into the land of wanna-woulda, with different retention policies and so sending-schedules (as well as, in my earlier posted wishlist, an exclusion support - so e.g. I set up once the pool retention rules, but point-exclude the swap/dump/... datasets). Both of these directions call for more sophisticated schedule calculator than current all-or-nothing, but it is doable). Those features would be great, and with the scheduler mentioned above the computer could calculate the work scope needed (with e.g. differently-scheduled zfs send -r calls for different sub-trees with same settings under some point) rather than admins doing such grunt work, having recursive actions and different policies would not all contradict each other.

@jimklimov

This comment has been minimized.

Copy link
Contributor Author

@jimklimov jimklimov commented Oct 25, 2019

Thinking about it a bit more over the past week of digging in this code, a safe path forward seems to be:

  • evaluate whether the dataset with backup plan that we would now process (might be one of many discovered or handed-down backupSet array entries) is a root of a "straightforward" tree to back up completely (plan's "recursive" option is "on", and no descendant has an "enabled=off" setting... and maybe also that no descendant has a "source=local" backup plan of its own)
    ** also consider --autoCreation=on (BTW... introduce a backup plan option for that, if needed?) if some target datasets are missing; ignore this point if trees are equivalent
  • if this dataset is "straightforward", try to zfs send -R | mbuffer | zfs recv and let ZFS figure out what to accept and what to ignore; different vendors' and releases' builds of ZFS are differently capable in this regard (e.g. some might send the whole stream to be ignored in vain, while others might perhaps agree to skip it and begin sending another more quickly)
  • if the dataset is not "straightforward", or if it is but the zfs send -R attempt failed, fall back to what we do now, sending each individual dataset and each their enabled descendant, one by one

Hopefully this approach is backwards-compatible for complex configurations, but might benefit from simpler faster single-command-per-tree send/receive; in particular I hope that it would let the zfs recv half of the equation not to start hundreds of times each with its evaluation of the pools and stuff, and so would cut days-long runs of small but numerous backups into something a lot shorter.

@oetiker

This comment has been minimized.

Copy link
Owner

@oetiker oetiker commented Oct 25, 2019

I like the idea to add a 'cut through' path for 'the normal case'.
Not sure about the opportunistic receive ... it is backup, so I would like for znapzend to complain if things do not work out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.