search

oetiker / znapzend

zfs backup with remote capabilities and mbuffer integration.
www.znapzend.org
GNU General Public License v3.0
608 stars 138 forks source link

Znapzend inherited backup plans #444

Closed jimklimov closed 4 years ago

jimklimov commented 4 years ago

One big annoyance is when some small ZFS subtree has not replicated, but to retry getting it there I must runonce and wait for the whole backup config to be processed.

This PR adds --inherit flag to znapzend and znapzendzetup list to permit (non-default) use of datasets that have the org.znapzend:* attributes inherited, but only if it comes from a dataset whose definition source for them is "local". This way the first encountered (directly specified or recursed) dataset with a backup plan (local or such inherited) in a subtree would be the replication source (datasets under it that only have the znapzend attrs inherited are not added to explicit lists for processing of them with children).

The PR is currently posted as Work-in-progress to solicit early comments about overall sanity ;) and because it is late night now, and I likely missed something in the code and/or did not implement some nuances as "promised" by the documented plan in comments and help/man text.

coveralls commented 4 years ago

Coverage Status

Coverage increased (+0.4%) to 88.682% when pulling 1e8555fb8db216b82ed87c128d9a437eab57767f on jimklimov:znapzend-inherited into eca5c90474bcdf7fa3e0b6e3606b3652870dc4d0 on oetiker:master.

jimklimov commented 4 years ago

I think by now it does what I intended so want to drop the "WIP" tag and let you merge it :-) Though maybe more people giving it a run first and finding any unfortunate regressions would also help.

As commented in the code, there are some nuances that could be handled better (e.g. more optimal processing/tracking of sub-inherited datasets we would ignore) but these refinements might be in some other PR.