Closed jimklimov closed 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.
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.
ready to merge ?
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.
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 ranbeadm activate
to have that new BE be the one used next boot (in particular, thiszfs 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.: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.