For active-passive systems, keep the standby dataset tree read-only and verify it before promotion.
When both directions are defined as recurring policy jobs, this pattern is a Zelta Twin: an asynchronous cluster pair where either side can become the active dataset tree. Twin is the full operator guide; this page is the short promotion path.
The high-level workflow in Zelta 1.2 is zelta failover:
zelta failover primary.example.com:tank/service standby.example.com:tank/service
zelta failover composes the safety steps: lock the active source, perform a final backup, sync local ZFS properties, and unlock the promoted target. See zelta-failover(8).
Use lower-level commands when you need to script or pause between steps:
zelta match primary.example.com:tank/service standby.example.com:tank/service
zelta lock primary.example.com:tank/service
zelta backup primary.example.com:tank/service standby.example.com:tank/service
zelta propsync primary.example.com:tank/service standby.example.com:tank/service
zelta unlock standby.example.com:tank/service
zelta match primary.example.com:tank/service standby.example.com:tank/service
| Command | Role |
|---|---|
zelta lock |
Make the active tree safe to leave (readonly / unmount order) |
zelta backup |
Final incremental to the standby |
zelta propsync |
Copy local properties the promoted side needs |
zelta unlock |
Make the promoted side writable |
See zelta-failover(8) for the lower-level command details.
zelta match before and after promotion.zelta match reports divergence (not merely behind), fix backup continuity with zelta rotate before expecting a normal backup or failover.