Today I was honored to give ZFS Boot Environments Reloaded talk at the NLUUG Najaarsconferentie 2018 (the NLUUG Autumn Conference 2018).
Dunno for how long the conference page will be available so below you will find both conference page and its program.
… and the program.
There were lots of interesting talks, I really liked the Salt workshop at the end of the day. I wanted to also attend Ansible presentation in the morning but having spend almost 17 hours in the car driving from central Poland to Netherlands I really needed some sleep π
You are invited to download the PDF Slides – https://is.gd/BECTL – available here.
As I just finished the talk the video from the talk is not yet available, but I will update the post when it will be.
Besides obvious things that ZFS Boot Environments can do I also talked about upcoming FreeBSD 12.0-RELEASE improvements in this area. Currently FreeBSD 12.0-RELEASE is planned to be released around Christmas later this year and is at the BETA4 stage currently.
Also here is the abstractΒ that I added at the conference page about the presentation.
Abstract
As long as sysadmins need to maintain, change and update operating systems there is always need to protect against problems that may occur during these operations. Various solutions were used starting from simple backup/restore procedures or copying the contents of system filesystems into spare disks to snapshots and clones recently. None of these solutions were transparent enough or bulletproof enough to provide complete and consistent protection again failures in the change or update process.
One of such holy grails is ZFS Boot Environments solution. It protects entire system (and even additional data when needed) against almost any change or update process. As ZFS Boot Environments matured in Solaris/Illumos systems and then on FreeBSD UNIX other systems started to copy its principles to provide similar solutions such as snapper with BTRFS in SUSE or Boot Environment Manager for DragonFly BSD with their HAMMER filesystem.
The presentation aims to walk through the history of these solutions with the focus on practical ZFS Boot Environments solutions and examples.
Β
Hope you will enjoy it.
ππππππππ 
I have a doubt about ZFS on root installation in a UEFI dual boot setup with rEFIt boot loader. If I shift from installer to shell mode to create ZFS partition, pool, can I make the bsdinstall to continue installing? Thank you.
LikeLike
Check the 2.6.5. Shell Mode Partitioning section of the FreeBSD Handbook, that should be the thing you are looking for.
https://www.freebsd.org/doc/handbook/bsdinstall-partitioning.html#bsdinstall-part-shell
LikeLike
Thank you for the reply.
LikeLike
Pingback: ZFS Boot Environments – Firmware Security
Pingback: In Other BSDs for 2018/11/17 – DragonFly BSD Digest
Pingback: FreeBSD Network Management with network.sh Script | ππππππππ
Pingback: FreeBSD Desktop – Part 2.1 – Install FreeBSD 12 | ππππππππ
Pingback: Less Known pkg(8) Features | ππππππππ
Pingback: FreeBSD Enterprise 1 PB Storage | ππππππππ
At transactional-update, the openSUSE equivalent of beadm, your presentation about the ZFS Boot Environments was recently mentioned in an issue.
The presentation is amazing, but there is one thing which confuses me: On page 40 you claim that a “complete system rollback, restoring the complete system to the identical state as it was in when a snapshot was taken, is not possible” with Btrfs / zypper. This, however, is intentional behaviour: a rollback of production data (especially data in /var) is usually not desired (such as: I don’t want to loose all my orders put in the database since the creation of the last dataset). That’s why all those subvolumes listed on the next slide are created, as Btrfs (in contrast to ZFS) can and will not create recursive snapshots. So in other words: openSUSE is set up to enable rollbacks of the system, but not the data itself.
Now the interesting thing is: On page 42 it seems the same directories are also created as separate datasets on FreeBSD. Isn’t this for the same reason: To prevent an (usually unintended) rollback of production data?
LikeLike
Thank You.
This paragraph – “A complete system rollback, restoring the complete system to the identical state as it was in when a snapshot was taken, is not possible.” – is a cite from System Recovery and Snapshot Management with Snapper for OpenSUSE Leap 15 Linux. I did not wrote that, only cited.
FreeBSD by default omits these dirs in ZFS Boot Environments protection:
/tmp
/usr/home
/usr/ports
/usr/src
/var/audit
/var/crash
/var/log
/var/mail
/var/tmp
So no real ‘data’ here besides /home (by default as /usr/home on FreeBSD) – but beadm(8) is here to protect the system and its services – not users data. So on FreeBSD besides users home directories WHOLE SYSTEM along with daemons/services/data is protected by default.
These are excludes from OpenSUSE Leap 15 Linux system:
/boot/grub2.*
/home
/opt
/var/opt
/srv
/usr/local
/tmp
/var/tmp
/var/log
/var/cache
/var/crash
/var/lib/libvirt/images
/var/lib/mailman
/var/spool
/var/lib/named
/var/lib/mariadb
/var/lib/mysql
/var/lib/pgqsl
This means that system can be screwed from the beginning (/boot/grub2.*) along with broken services/daemons/applications (/opt and /srv and /usr/local omitted). Not to mention ‘picky’ excludes for mariadb/mysql/pgsql dirs, why sqlite/db2/informix/mongodb/… directories are not omitted?
I am also curious what Ubuntu 19.10 will bring as it will be shipped with root on ZFS feature … but as I know the Linux world the /boot partition will be separate anyway with some ext4/xfs filesystem so the whole idea of protection of the whole system will be dead on day one.
Thank you for comment.
Regards π
LikeLike
Oh dear, it seems the Leap manual contains an outdated list of directories – I’ve just filed a documentation bug. The actual subvolumes can be found on https://en.opensuse.org/SDB:BTRFS#Default_Subvolumes.
You will note that /var is just one subvolume now, resolving that pickiness we had to do previously – we had to first clean up the /var directory to separate system and user data cleanly.
Regarding GRUB2: Only the architecture specific modules directory is not part of the snapshot. This is due to the fact that the module versions always *have* to match the version of the installed GRUB (i.e. the file system independent part installed to MBR / EFI / …). As such this would also be the case with ZFS and FreeBSD (at least when using GRUB2 as the boot loader).
That said, the main difference seems to be that on openSUSE application data (e.g. databases, container images, log files etc) is also considered data (i.e. a rollback will revert everything *except* the application data), while FreeBSD will just roll back everything, similar to VM snapshots. That may be a philosophical question, but in our case we decided we never want to loose application data such database entries. Especially on atomic systems where the update is performed in the background or when jumping forth and back between snapshots, as this would necessarily result in data loss or data inconsistency when snapshotting the complete file system. This, however, is a design decision, and not a limitation of Btrfs.
And last but not least I just want to point out that a separate /boot partition is not needed if GRUB itself supports all necessary features. Most openSUSE distributions, including MicroOS and Kubic (https://kubic.opensuse.org/), won’t create one for exactly that reason: To be able to protect the whole system with a snapshot.
Will be interested to see how Ubuntu will be handling this, though π
LikeLike
Pingback: List Block Devices on FreeBSD lsblk(8) Style | ππππππππ
Pingback: ZFS Boot Environments Revolutions | ππππππππ