ZFS Boot Environments mit bectl: ein Rollback-Pfad für FreeBSD- und Paket-Upgrades

Ziel

Vor einer riskanten Änderung unter FreeBSD 14.x mit Root-on-ZFS eine ZFS Boot Environment anlegen, nach dem Testen eine andere aktivieren und nicht mehr benötigte Environments entfernen.

Voraussetzungen

Eine Root-on-ZFS-Installation (die Datasets liegen unter zroot/ROOT, das laufende System befindet sich typischerweise in zroot/ROOT/default); Root-Zugriff; bectl(8) ist vorhanden (Werkzeug des Basissystems, keine Paketinstallation nötig).

Schritte

1. Vor einer grösseren Änderung – einem Upgrade des Betriebssystems oder einem umfangreichen Paket-Upgrade – eine neue Environment anlegen: bectl create beforeupgrade. Das FreeBSD Handbook beschreibt das Anlegen einer Boot Environment als Snapshot und Klon der Root-Datasets, der "completes in seconds and consumes almost no space until the environments start to diverge" (also in Sekunden abgeschlossen ist und kaum Speicherplatz belegt, bis die Environments auseinanderlaufen). Auf einem ZFS-Root, der Boot Environments unterstützt, legt auch freebsd-update install automatisch eine an, sofern in /etc/freebsd-update.conf nicht CreateBootEnv no gesetzt ist; eine benannte Environment lässt sich trotzdem leichter wiederfinden.
2. Prüfen, ob sie existiert, und feststellen, welche Environment aktiv ist: bectl list. In der Spalte Active kennzeichnet N die aktuell verwendete Environment und R diejenige, die nach dem nächsten Neustart aktiv sein wird.
3. Das Upgrade wie gewohnt durchführen – freebsd-update install oder pkg upgrade. Dabei wird die aktuell aktive Environment verändert, während beforeupgrade unangetastet bleibt.
4. Bootet das aktualisierte System nicht oder verhält es sich fehlerhaft, neu starten und beforeupgrade im Menü "Boot Environments" des FreeBSD-Loaders auswählen; die Auswahl dort gilt nur für den aktuellen Bootvorgang.
5. Soll dieses Rollback dauerhaft gelten, statt bei jedem Start erneut gewählt zu werden, die Environment aktivieren: bectl activate beforeupgrade. Laut bectl(8) setzt activate die angegebene Environment als Standard-Boot-Dateisystem. bectl activate -t beforeupgrade aktiviert sie nur für den nächsten Start; das eignet sich, um ein Rollback auf einem entfernten System zu testen, ohne sich darauf festzulegen.
6. Um eine inaktive Environment zu untersuchen oder zu reparieren, ohne sie zu booten, sie einhängen: bectl mount beforeupgrade, unter dem ausgegebenen temporären Pfad arbeiten und anschliessend bectl umount beforeupgrade ausführen.
7. Sobald feststeht, dass eine Environment nicht mehr gebraucht wird, ihren Speicherplatz freigeben: bectl destroy beforeupgrade. Laut bectl(8) zerstört dieser Befehl die Environment "without confirmation" (ohne Rückfrage), anders als das ältere Werkzeug beadm; den Namen daher vorher mit bectl list prüfen.

Erwartetes Ergebnis

bectl list zeigt die neue Environment unmittelbar nach create an, mit einem Space-Wert von nur wenigen Kilobytes; nach activate und Neustart zeigt bectl list sie mit der Markierung NR.

Grenzen und Prüfbasis

Eine Boot Environment umfasst nur die Datasets unter zroot/ROOT. Im Standardlayout gehören dazu /usr/local und /var/db. Installierte Pakete werden daher zusammen mit dem Basissystem zurückgesetzt, ebenso dort abgelegte Anwendungsdaten (zum Beispiel eine Datenbank unter /var/db): Beim Aktivieren einer älteren Environment kehren sie unbemerkt auf ihren älteren Stand zurück. Datasets ausserhalb von zroot/ROOT (zroot/home, zroot/var/log, zroot/var/mail) werden von allen Environments gemeinsam genutzt und nie zurückgesetzt; das Handbook empfiehlt, Daten, die ein Rollback überstehen müssen, in einem eigenen Dataset ausserhalb von zroot/ROOT abzulegen. Boot Environments liegen im selben Pool und ersetzen kein Backup.