Sounds a lot like the A/B update method used widely in Android and to a lesser extend for embedded GNU/Linux OTA updates. But it uses two distinct boot partitions. Since ZFS is involved here, I assume that boot environments take advantage of its copy-on-write mechanism to avoid duplicating the entire boot dataset.
NixOS and Guix use a concept called 'system generations' to do the same without the support of the filesystem. LibOSTree can do the same and is called 'atomic rollback'.
Talking about NixOS, does anybody know of a similar concept in the BSD world (preferably FreeBSD)?
A snapshot is a low-cost read-only view of a filesystem at a point in time; a clone is a writeable filesystem with initial contents shared from a snapshot.
It's an amazing safety net, though it requires understanding and sysadmin discipline to use well -- starting with keeping user/application data separated from the filesystems managed as part of the BE. ZFS makes this easy (a pool can contain many separate filesystems) but you have to do it.
One gotcha is that if you run an update that creates and activates a new BE but don't reboot right away, changes made to the BE-managed part of the running system after the snapshot creation will be "lost" (stranded in the old BE) when you reboot to the new BE.
NixOS and Guix use a concept called 'system generations' to do the same without the support of the filesystem. LibOSTree can do the same and is called 'atomic rollback'.
Talking about NixOS, does anybody know of a similar concept in the BSD world (preferably FreeBSD)?