oetiker / znapzend

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

contrib/synczbe: refactor work with zoned property + improve behavior for recently cloned sources #553

Closed jimklimov closed 2 years ago

jimklimov commented 2 years ago

A bit of refinement during/after recent OI upgrade :)

For full disclosure: in this use-case I ran pkg rituals to create a new boot environment and update it, and local zones too; then I ran beadm activate to have that new BE be the one used next boot (in particular, this zfs promote's its rootfs and zone roots), and ran this script against my system and zone roots to apply similar change to the backup pool, e.g.:

DEBUG=no SR=nvpool/zones/testdhcp/ROOT ~jim/shared/znapzend/contrib/synczbe

DEBUG=no ZFSLIST_REGEX=firefly SR=nvpool/ROOT ~jim/shared/znapzend/contrib/synczbe
DEBUG=no ZFSLIST_REGEX=hipster SR=nvpool/ROOT ~jim/shared/znapzend/contrib/synczbe

Subsequent znapzend runs for standard snapshot and resync use-case seems to have worked decently (no new non-cloned datasets spawned) before and after the OI reboot.

As before, zoned property is optionally (ab)used on my local backup dataset to surely avoid automounting of the backed-up datasets, with the overhead that it complicates non-trivial manipulations with those datasets.

stale[bot] commented 2 years ago

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.

jimklimov commented 2 years ago

gentle bump :)

On Mon, Sep 27, 2021, 21:51 stale[bot] @.***> wrote:

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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/oetiker/znapzend/pull/553#issuecomment-928218135, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFHJ3MTC7OSWLEWJ2Z3UEDDLLANCNFSM5BHCFUCA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

oetiker commented 2 years ago

ready to merge ?

jimklimov commented 2 years ago

I guess so - there were few things to address over my recent OS upgrades (and related dataset promotions on the backup).

Next big thing might be to add the smarts into znapzend itself by porting this logic well-tested standalone (to detect if target needs a promotion/clone like this and to perform it). Also the script here acts on a (zbe or rootfs) hosting dataset specified by caller, which for me means a rootfs/ROOT and a dozen local zone roots listed in another script to call this one.

One practical caveat - better stop znapzend before upgrading the OS to avoid confusion and avoid it sending a full copy of newly discovered dataset(s) to backup, then beadm activate NEWBE if update went well, then use synczbe here to update the backup, and only then init 6 to reboot into new OS revision - with that uptime starting znapzend service in usable conditions again.

On Wed, Nov 10, 2021, 14:42 Tobias Oetiker @.***> wrote:

ready to merge ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/oetiker/znapzend/pull/553#issuecomment-965172872, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFAFLRVEDU3HGIHDOYTULJZGDANCNFSM5BHCFUCA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.