Frage zu ZFS-Snapshots

Macke1979

Macke1979

FreeBSD-User
Hallo Leute,

ich habe nun seit gestern sehr viel über das Thema ZFS gelesen, sowohl im FreeBSD-Handbuch als auch im Wiki zu diesem Forum. Ich habe mir mit
Code: 
zfs snapshot -r
gestern Nacht einen rekursiven Schnappschuss des gesamten ZFS-Pools (welchen ich während der Installation mit bsdinstall angelegt habe) erstellt.
Code: 
shinji@freebsd:~ $ zfs list -t snapshot
NAME                                       USED  AVAIL  REFER  MOUNTPOINT
zroot@snapshot1                              0B      -    96K  -
zroot/ROOT@snapshot1                         0B      -    96K  -
zroot/ROOT/default@snapshot1               360K      -  9.43G  -
zroot/ROOT/default@2024-01-24-18:40:59-0   592K      -  9.81G  -
zroot/home@snapshot1                      38.9M      -  1.44G  -
zroot/tmp@snapshot1                        132K      -   164K  -
zroot/usr@snapshot1                          0B      -    96K  -
zroot/usr/ports@snapshot1                    0B      -   805M  -
zroot/usr/src@snapshot1                      0B      -    96K  -
zroot/var@snapshot1                          0B      -    96K  -
zroot/var/audit@snapshot1                    0B      -    96K  -
zroot/var/crash@snapshot1                    0B      -    96K  -
zroot/var/log@snapshot1                    220K      -   320K  -
zroot/var/mail@snapshot1                     0B      -   160K  -
zroot/var/tmp@snapshot1                     64K      -    96K  -
shinji@freebsd:~ $
Wenn ich jedoch mittels zfs rollback den kompletten Schnappschuss irgendwann eventuell mal zurückspielen muss, weil zum Beispiel bei einem Upgrade etwas schiefgelaufen ist, so kann ich dies sicher nicht einfach im Single-User-Mode tun, da sich dann ziemlich sicher die Katze selbst in den Schwanz beißen würde, wenn ich einfach das komplette Dateisystem im laufenden Betrieb in einen älteren Zustand versetze... Mein Vorgehen wäre in etwa so: Ich würde ein Live-System vom USB-Stick starten... Dann würde ich meinen zpool importieren und mounten, um drauf zugreifen zu können...
Code: 
zpool import -f -R /mnt zroot
mount -t zfs zroot/ROOT/default /mnt
Daraufhin würde ich noch in mein System chrooten...
Code: 
chroot /mnt
Und zu guter Letzt...
Code: 
zfs rollback zroot/ROOT/default@snapshot1
Ja, ich denke, so würde ich vorgehen. Könnte ich das so gefahrlos machen? Ich bin mir nicht ganz sicher (ZFS ist Neuland für mich) und ich befürchte, dass da eine Menge schiefgehen kann, wenn man da etwas falsch macht, deshalb frage ich lieber vorher. Auch wenn ich bis jetzt noch gar nicht in dieser Situation bin.
 
Sollte prinzipiell so funktionieren;
Wenn du die Möglichkeit hast, solltest du das am Besten mal so durchspielen und die Schritte aufnotieren - wäre ggf was fürs Wiki;
Ein Live-System (FreeBSD Bootmedium oder mfsbsd) wird vermutlich notwendig sein;
Ich selber nutze das so nicht (vollständiger snap des Systems), sondern mache snapshots nur vom $HOME (ein snap alle 15 Minuten, die letzten 3 Tage) und bei Updates erstelle ich vorher ein Boot-Environment, deswegen würde mich das Vorgehen da auch interessieren.

Wenn es dir nur drum geht, um gegen Updatefehler gefeit zu sein, dann nutze bectl (im Basissystem enthalten) oder beadm (Skript von vermaden, Vorgänger vom bectl).

Damit kannst du ein neues Boot-Environment (im Endeffekt ein Snapshot des Systems, ohne $HOME) erstellen und dieses updaten - falls es schief geht, verwirfst du es einfach und fängst von vorne an, wenns aber geklappt hat dann bootest du in dieses neue Environment. Hier noch ne genauere Beschreibung des ganzen.
Damit kann man auch gefahrlos von ner alten auf ne neue Major Version testweise wechseln - z.B. 13 auf 14, mit der Möglichkeit weiterhin noch die vorherige Version zu booten (zumindest solange du kein "zpool upgrade" auf dem in Frage kommenden zroot Pool durchgeführt hast, wenn da neuere Features im zfs dabei waren, gibts meist keinen Weg mehr zurück)
 
Das mit dem chroot solltest du lassen, einfach direkt aus dem Livesystem das Rollback machen. Aber: Gerade für das rootfs und update-rollbacks nutze lieber die integrierte Funktionalität von bectl. @turrican hat da ja schon auf die nötigen Ressourcen verlinkt.
 
tatsächlich habe ich das schon mal "machen müssen" und mir aber nicht notiert, wie ich das hinbekommen habe. Es war nicht so einfach, wie ich dachte, ein Live-System wurde benutzt, gechrootet wurde nicht, ich glaube, ich musste jedes Dataset einzeln zurück rollen.

Hilfreich war für mich schon häufiger die Information bei oracle, zB:
das ist nun einfach der Link zum ersten Treffer der Suchmaschine, nicht direkt ein Link, mit der fertigen Lösung.

Die Frage kommt immer wieder auf, welchen Sinn es macht, das komplette System zu sichern (snapshots sind keine Sicherungen, können aber ganz gut hierfür verwendet werden). Ich mache vor jedem SW-Update einen -r snapshot. Ganz einfach schon, weil ich mich dadurch sicherer fühle. Und es hat sich in der Vergangenheit gezeigt, dass ich mir dadurch schon eine Menge Arbeit sparen konnte. So funktionierte nach einem Update XSANE nicht mehr, weil ich übereifrig der Löschung einiger Dateien zugestimmt hatte. Das war doof von mir, aber allermeist sind es ja auch die persönlichen Fehler, die man korrigieren möchte. In meinem Fall hatte ich das benötigte Binary (die "Firmware") für den Scanner gelöscht und auch die zugehörige Konfiguration. Statt alles neu zu machen, konnte ich aus dem Snapshot heraus die benötigten Dateien einfach zurück kopieren.
Dass man tatsächlich komplett zurück rollen muss, ist sicher selten.

Allerdings kann man auch einen kompletten (-r) Snap sichern oder sogar auf ein anderes System klonen. Somit erweitern sich die Möglichkeiten, die man nutzen kann.
 
turrican schrieb:
Damit kannst du ein neues Boot-Environment (im Endeffekt ein Snapshot des Systems, ohne $HOME) erstellen und dieses updaten - falls es schief geht, verwirfst du es einfach und fängst von vorne an, wenns aber geklappt hat dann bootest du in dieses neue Environment. Hier noch ne genauere Beschreibung des ganzen.
Zum Vergrößern anklicken....
Hey, das ist ja mal nice, Danke. :) Vor allem wenn beim Upgrade auf ein Major-Release etwas daneben geht, wird sich das als sehr nützlich erweisen. Ich habe übrigens festgestellt, dass bectl auch bei kleinen Sicherheitsupdates des Betriebssystems automatisch ein Boot Environment anlegt. Vorgestern gab es da nämlich ein paar Updates, und...
Code: 
shinji@freebsd:~ $ bectl list
BE                             Active Mountpoint Space Created
14.0-RELEASE_2024-01-24_184059 -      -          600K  2024-01-24 18:40
default                        NR     /          11.3G 2024-01-24 18:17
shinji@freebsd:~ $
Und dann gibt es ja auch noch freebsd-update rollback welches bei kleineren Updates vermutlich noch etwas einfacher geht, falls was schiefläuft.
pit234a schrieb:
tatsächlich habe ich das schon mal "machen müssen" und mir aber nicht notiert, wie ich das hinbekommen habe. Es war nicht so einfach, wie ich dachte, ein Live-System wurde benutzt, gechrootet wurde nicht, ich glaube, ich musste jedes Dataset einzeln zurück rollen.
Zum Vergrößern anklicken....
Schade, interessiert hätte mich schon, wie du da vorgegangen bist. Das klingt als ob zfs rollback nicht rekursiv arbeitet.
 
Jetzt ist es gestern Nacht dazu gekommen, dass ich beide Methoden ausprobieren musste, was jedoch durch einen Irrtum meinerseits gar nicht nötig gewesen wäre. Nachdem mir pkg upgrade neue Updates spendiert hat, habe ich mir also eine BE erstellt, selbige gemountet und das Upgrade wie beschrieben durchgeführt. Allerdings hatte ich nach dem Wechsel in die neue Umgebung, in der ich ausprobieren wollte, ob alles zu meiner Zufriedenheit läuft, folgendes Problem: Wenn ich ein Programm (ja, ich hasse das Wort App XD) starten wollte direkt nachdem sich mein XFCE-Desktop präsentierte, musste ich (ungefähr) eine Minute warten, bis das Programm geöffnet wurde und ich arbeiten konnte... Wenn ich meinen Webbrowser oder das Terminal hingegen einmal aufgerufen hatte, funktionierte alles wie gewohnt. Als ich allerdings den Rechner neu starten wollte, hat es wieder etwa eine Minute gedauert, bis der Abmeldebildschirm erschien... Und nachdem ich auf "Neustart" geklickt habe, musste ich ebenfalls wieder etwa eine Minute warten... Das BE default funktionierte hingegen tadellos, wie ich feststellen musste.

Irgendwas brachte mich zu dem Schluss, dass ich vielleicht einach die neue BE wieder löschen sollte, um dann pkg upgrade unter default durchzuführen. Aber: Nach pkg upgrade hatte ich auch unter der default-BE dasselbe Problem, was für einen Bug in einem der Pakete spricht. Sowas ist ja eigentlich (ich benutze den Latest-Zweig) recht selten, aber ausgerechnet jetzt mal wieder der Fall. Also hatte ich keine andere Wahl, ein Live-System zu starten und von dort meinen alten Schnappschuss, den ich angelegt habe, zurückzuspielen. So bin ich vorgegangen:
Code: 
zpool import -f -R /mnt zroot
mount -t zfs zroot/ROOT/default /mnt
Dann habe ich mit zfs rollback jedes Dataset einzeln zurückgerollt, was auch recht schnell ging. Danach noch
Code: 
umount /mnt
reboot
Hat alles ohne Probleme geklappt. Wenn ich jetzt noch wüsste, welches Paket den fraglichen Bug enthält, wäre ich rundum zufrieden, so bleibt mir nur zu warten, bis das Problem gefixt wird (ich gehe mal davon aus, dass dies bald der Fall sein wird) und dann kann ich mein Upgrade durchführen. Und ich denke mal, dass @pit234a ebenfalls so vorgegangen ist, als er dieses Problem schonmal hatte.^^
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben