Mit OpenSuses Snapshot-Tool Snapper lässt sich das System in einen vorher gespeicherten Zustand zurückversetzen. Das klappt sogar unter Ubuntu – zumindest teilweise.

Streikt das Betriebssystem wegen eines misslungenen Updates oder haben Sie aus Versehen eine wichtige Konfigurationsdatei gelöscht, hilft oft nur einer von zwei Wegen: Entweder installieren Sie das System neu – das bietet zwar den Vorteil eines sauberen Neuanfangs, bedeutet aber ziemlich viel Aufwand –, oder Sie verfügen über ein halbwegs aktuelles Abbild der Installation.

Die Software Snapper erstellt und verwaltet solche Systemabbilder, benötigt dazu aber Btrfs als Dateisystem. Als einzige gängige Distributionen verwenden Suse Linux und dessen Community-Ableger OpenSuse standardmäßig Btrfs für die Root-Partition. Wir verwenden für diesen Text allerdings nicht OpenSuse, für das Snapper ursprünglich entwickelt wurde, sondern wollen die Software in Ubuntu 19.04 integrieren.

Einem Linux-Anwender mit Kommandozeilenroutine und Erfahrung im Umgang mit Änderungen an Konfigurationsdateien sollte das Umsetzen keine Probleme bereiten. Allerdings schadet es nichts, sich vor dem Erstellen eines Produktivsystems mit Snapper mit den Eigenheiten von Btrfs vertraut zu machen. Einen guten Überblick dazu vermittelt das Arch-Wiki [1]. Für erste Tests genügt es aber, diesem Artikel zu folgen und sich gegebenenfalls in einzelne Bereiche einzulesen.

Snapper mit Ubuntu

Zunächst gilt es, Ubuntu mit Btrfs als Dateisystem einzurichten. Dazu wählen Sie im Installer bei der Formatierungsabfrage den Eintrag Etwas anderes aus und legen bei einer UEFI-Installation eine Btrfs-Root-Partition sowie eine 100 MByte große FAT-32-Boot-Partition mit Verwendungszweck efi an. Auf einem Rechner mit einem herkömmlichen BIOS formatieren Sie die Boot-Partition dagegen mit Ext4. Btrfs geht erst seit Kernel 5.0 wieder mit Swap-Dateien um, und das auch nur bedingt. Sollten Sie also eine Auslagerungsdatei benötigen, müssen Sie an dieser Stelle eine eigene Partition dafür anlegen.

Nach der Installation bringen Sie das System zunächst auf den neuesten Stand. Danach installieren Sie Snapper und die Btrfs-Tools. Was Btrfs und Snapper angeht, bietet Ubuntu eine vernünftige Voreinstellung (Abbildung 1). Somit steht das Snapshot-Werkzeug nun grundsätzlich zum Einsatz bereit. Wenn Sie ab jetzt im System ein Paket installieren oder ein Upgrade einspielen, legt Ubuntu vorher und nachher automatisch einen Snapshot an.

Abbildung 1: Ubuntu mit Btrfs-Dateisystem legt bei der Installation die beiden Subvolumes @ und @home auf der obersten Ebene an.

Auf der Root-Partition legt Btrfs automatisch die zwei Subvolumes @ und @home an (Listing 1, erste Zeile). Jetzt teilen Sie dem System mit, dass Sie für die Root-Partition eine Konfiguration anlegen möchten (zweite Zeile). Wiederholen Sie nun das List-Kommando, taucht ein neues Subvolume namens .snapshots auf. Es liegt, wie in einem Verzeichnisbaum, unterhalb von @, dem Subvolume von Root. Das erkennen Sie daran, dass es sich in einem anderen Level befindet (Abbildung 2).

$ sudo btrfs sub list /
$ sudo snapper -c root create-config /

Abbildung 2: Bei der Konfiguration von Snapper entsteht das Subvolume .snapshots, das unterhalb der anderen Subvolumes liegt. Das ist bei OpenSuse in Ordnung, wir verlegen es unter Ubuntu aber auf die oberste Ebene.

Das passt so zwar für OpenSuse, nicht aber für andere Distributionen. Damit sich später ein Rollback auf einen älteren Snapshot vornehmen lässt, der das Home-Verzeichnis unangetastet lässt, passen Sie zunächst die Infrastruktur an: Für unsere Zwecke muss .snapshots auf der obersten Ebene neben den beiden anderen Subvolumes liegen.

Snap und Sub

An dieser Stelle gilt es, einer Verwirrung bezüglich der Begriffe Snapshot und Subvolume vorzubeugen [2]. Ein Snapshot stellt eine Momentaufnahme des Systems dar und lässt sich später bei Bedarf als Standard-Subvolume wie eine Partition einhängen. Das gilt für alle Arten von Snapshots, außer für die bei Paketmanipulationen automatisch erstellten Pre- und Post-Snapshots – dazu später mehr.

Die notwendigen Schritte zum Anpassen der Subvolumes zeigt Listing 2. Wir hangeln uns dabei an einem Konzept des Linux-Youtubers Nick aka unicks.eu entlang [3]. Kontrollieren Sie die Änderungen an der /etc/fstab (Abbildung 3) doppelt auf korrekte Eintragungen, denn den kleinsten Fehler darin bestraft Systemd damit, den Systemstart zu verweigern.

Abbildung 3: Wie in diesem Bild sollte die Datei /etc/fstab nach dem Editieren aussehen. Das System verzeiht hier keine Fehler und verweigert das Booten.

$ sudo btrfs sub del /.snapshots
$ sudo mkdir /.snapshots
### Datei /etc/fstab um zwei Einträge erweitern.
### Als UUID dient jene der Root-Partition /.
UUID=UUID /btrfs      btrfs defaults,subvolid=5 0 0
UUID=UUID /.snapshots btrfs defaults,subvol=@snapshots 0 0
### Zeile der Root-Partition / editieren.
UUID=UUID /           btrfs defaults,subvol=@ 0 0
### wird zu:
UUID=UUID /           btrfs defaults 0 0
### Erstellen und Einhängen der angelegten Einträge:
$ sudo mkdir /btrfs && sudo mount /btrfs
### Subvolume @snapshots erstellen
$ sudo btrfs sub cr /btrfs/@snapshots
$ sudo mount /.snapshots
$ sudo btrfs sub set-default 257 /btrfs

Nun installieren Sie das Paket git und klonen von Github das Skript grub-btrfs [4] in das zuvor erstellte Verzeichnis $HOME/grub/. Dann kopieren Sie die darin befindliche Datei 41_snapshots-btrfs nach /etc/grub.d/. Wenn Sie danach sudo snapper list aufrufen, sehen Sie, dass Snapper durch die Paketinstallation von Git bereits Snapshots angelegt hat, jeweils einen vor und nach der Installation. Diese haben die Typen pre und post und sind in der Beschreibung als vor beziehungsweise nach einer Apt-Aktion definiert.

Als Nächstes passen Sie die Boot-Konfiguration in der Datei /etc/default/grub an. Im ersten Block ändern Sie die Zuweisung in der Zeile GRUB_BTRFS_SUBMENUNAME der Ordnung halber zu "Ubuntu Snapshots". Aus demselben Grund editieren Sie die Zeile darunter zu GRUB_BTRFS_PREFIXENTRY="Snapshot: (Abbildung 4).

Abbildung 4: Diese zwei Zeilen hat das Skript für Debian angepasst; Sie sollten sie auf die verwendete Distribution abstimmen.

Als neue Zeile tragen Sie am Ende des Blocks GRUB_BTRFS_CREATE_ONLY_HARMONIZED_ENTRIES="true" ein. Damit stellen Sie beim Vorhalten mehrerer Kernel sicher, dass Grub nur sinnvoll zueinander passende Kombinationen von Kernel und Initrd anzeigt. Nach dem Abspeichern der Datei fehlt lediglich noch ein sudo update-grub. Hier sollten Sie bei der Ausgabe des Befehls bereits die automatisch erstellten Snapshots sehen (Abbildung 5).

Abbildung 5: Der Befehl update-grub veranlasst den Bootmanager dazu, beim nächsten Neustart alle bereits angelegten Snapshots anzuzeigen.

Um Update-grub nicht nach jeder Manipulation der Paketbasis ausführen zu müssen, legen Sie nun einen kleinen Hook an, der das für Sie übernimmt. Dazu erstellen Sie im Verzeichnis etc/apt/apt.conf.d die Datei 81upgradehook und fügen darin die Zeile DPkg::Post-Invoke {"/usr/sbin/update-grub";}; ein. Diese sorgt dafür, dass Update-grub nach jeder Installation, Deinstallation oder Aktualisierung eines Pakets oder eines System-Upgrades startet und somit Grub immer auf dem neuesten Stand in Sachen Snapshots hält. Nun müssen Sie den Bootloader nur noch nach einem manuell erstellten Snapshot von Hand aktualisieren.

Zu viele Snapshots

Bei Bedarf dämmen Sie die Flut der automatisch erstellten Snapshots ein. Voreingestellt erzeugt Snapper neben den mit pre und post bezeichneten Snapshots vor und nach Paketmanipulationen auch stündlich ein sogenanntes Timeline-Snapshot. Außerdem erstellt die Software bei jedem Booten einen neuen Snapshot. Um die Übersicht nicht zu verlieren, deaktivieren Sie diese vorerst, bis auf die Pre-Post-Snapshots.

Die stündlichen Timeline-Snapshots legen Sie direkt in der Konfiguration still (Listing 3, erste Zeile), Boot-Snapshots (Abbildung 6) stellen Sie per Systemd ab (zweite Zeile). Noch mehr Kontrolle über den Platzbedarf von Btrfs-Snapshots bieten Quota [5], mit denen sich das Löschen in Abhängigkeit vom Füllstand der Partition einrichten lässt, sodass eine Partition nie vollläuft.

$ sudo snapper -c root set-config "TIMELINE_CREATE=no"
$ sudo systemctl disable snapper-boot.timer

Abbildung 6: Snapper legt bei der Installation drei Systemd-Timer an. Ob Sie Timeline- und Boot-Snapshots anlegen möchten, legen Sie selbst fest.

Timeline-Snapshots sind nur dann sinnvoll, wenn Sie sie auch für das Subvolume @home anlegen lassen. Da Snapper die Snapshots zunächst nur mit Leserechten versieht, schützt Sie das beispielsweise vor dem Verschlüsseln durch Erpresser-Trojaner. Hier müssen Sie nach dem Aktivieren von Snapper (Listing 4) noch in den Einstellungen unter /etc/snapper/configs/home/ über das Timeline-Cleanup das automatische Löschen von älteren Snapshots nach Bedarf konfigurieren.

$ sudo snapper -c home create-config /home

Nach einem Neustart des Systems sehen Sie, ob die Konfiguration wie gewünscht funktioniert. Legen Sie nun mit dem Befehl aus Listing 5 einen manuellen, aussagekräftig benannten Snapshot an (Abbildung 7). Er dient im Anschluss zur Vorbereitung für einen kompletten Rollback.

$ sudo snapper -c root create -d "1. Snapshot"

Abbildung 7: Ein manuell angelegter Snapshot umfasst das gesamte Root-System und lässt sich, im Gegensatz zu den bei Paketmanipulationen erstellten Pre-Post-Snapshots, über den Grub-Bootloader zurückrollen.

Pre und Post

Doch zunächst zum einfacheren Fall. Nach der Installation von Paketen oder dem Editieren von Konfigurationsdateien stellen Sie fest, dass sich Ihr Rechner merkwürdig verhält. Da Snapper bei der Installation der Pakete ein Pre- und ein Post-Snapshot anlegt, sehen Sie zunächst nach, was genau passiert ist. Geben Sie dazu sudo snapper list ein, und schauen sich die beiden letzten Snapshots vom Typ Pre und Post an, die sich über ihre Nummer und Beschreibung eindeutig identifizieren lassen (Abbildung 8).

Abbildung 8: Pre-Post-Snapshot-Paare lassen sich an einem apt in der Beschreibung leicht erkennen. Indem Sie beide vergleichen, identifizieren Sie Paketmanipulationen und machen diese gegebenenfalls rückgängig.

Befinden sich sehr viele Snapshots in der Liste, grenzen Sie die Anzeige auf Pre-Post-Snapshots ein (Listing 6, erste Zeile). Um herauszufinden, was zwischen zwei Snapshots geschah, lassen Sie sich den entsprechenden Status ausgeben. Das Kommando aus der zweiten Zeile von Listing 6 zeigt beispielsweise an, was sich zwischen dem Pre-Snapshot 10 und dem Post-Snapshot 11 veränderte (Abbildung 9). Plus und Minus kennzeichnen dabei hinzugekommene oder entfernte Dateien; ein c signalisiert Veränderungen in der Datei. Falls eine Datei Sie besonders interessiert, sehen Sie genauer hin (Zeile 3). Entscheiden Sie sich dafür, auf den Stand von Snapshot 10 zurückzukehren, so gelingt das mit dem Kommando aus Zeile 4 (Abbildung 10). Danach löschen Sie das Snapshot-Paar (Zeile 5).

$ sudo snapper list -t pre-post
$ sudo snapper status 10..11
$ sudo snapper diff 10..11 Datei
$ sudo snapper -v undochange 10..11
$ sudo snapper delete 10 11

Abbildung 9: Der Befehl snapper status zeigt detailliert, was zwischen zwei Pre-Post-Snapshots geschah.

Abbildung 10: Der Befehl snapper undochange rollt auf einen Pre-Snapshot zurück und nimmt damit alle Änderungen der vorangegangenen Paketmanipulation zurück.

Wenn nichts mehr geht

Verhält sich das System nach Änderungen an der Konfiguration merkwürdig, wäre es bei umfangreichen Änderungen mühsam, diese zurückzunehmen und zu hoffen, dabei keine Fehler zu machen. Deshalb rollen Sie das System besser auf den vorher angelegten manuellen Snapshot 1. Snapshot zurück.

Um die folgenden Schritte besser nachvollziehbar zu machen, löschen Sie zunächst alle Snapshots außer den mit der Nummer 0 und den manuell erstellten 1. Snapshot. Dazu identifizieren Sie die zu löschenden Snapshots anhand ihrer Nummer (Listing 7, erste Zeile) und entfernen sie dann (zweite Zeile). Der Ausschluss der Timeline- und Boot-Snapshots vereinfacht die Auswahl, da nicht permanent ein neuer Timeline-Snapshot auftaucht.

$ sudo snapper list
$ sudo snapper delete Nummer(n)
$ sudo btrfs sub get-default
$ sudo btrfs sub list /
$ sudo btrfs sub set-default 275 /
$ sudo btrfs sub get-default
$ sudo btrfs property set -ts /.snapshots/5/snapshot ro false

Das Standard-Subvolume ist noch @ im Level 5 (Zeile 3). Jetzt setzen Sie zunächst den manuell erstellten Snapshot als neues Standard-Subvolume ein. Dazu listen Sie die Subvolumes auf (Zeile 4) und merken sich die ID des manuell angelegten Snapshots – in unserem Fall die ID 275 für das Sublevel @snapshots/5/snapshot. Dementsprechend ändern Sie das Subvolume (Zeile 5) und kontrollieren sicherheitshalber den Erfolg (Zeile 6) der Aktion (Abbildung 11).

Abbildung 11: Mit dem Befehl sub set-default setzen Sie einen Snapshot, auf den Sie zurückrollen möchten, als neues Standard-Subvolume, und booten anschließend hinein.

Um dieses Subvolume zu booten, müssen Sie wissen, dass Btrfs alle Snapshots read-only anlegt – sie lassen sich also durch äußere Einflüsse nicht verändern. Dadurch fällt bei einer Änderung des Standard-Subvolumes aber ein zusätzlicher Schritt an: Sie müssen den Snapshot beschreibbar machen (Listing 7, Zeile 7). Passen Sie die Nummer des Snapshots im Befehl entsprechend Ihren Gegebenheiten an. Danach starten Sie den Rechner neu und sollten danach mit sudo mount | grep subvol sehen, dass das neue Standard-Subvolume gebootet wurde (Abbildung 12).

Abbildung 12: Nach einem Neustart in eine neues Standard-Subvolume zeigt der Befehl mount | grep subvol den Erfolg des Vorgangs.

Fast perfekt

Das bis hierher gezeigte Vorgehen sichert ein System gegen Fehlkonfigurationen und gegen die meisten Fehler bei der Systemaktualisierung. Ein Rollback des Systems für den Fall, dass es nicht mehr bootet, bietet Snapper allerdings nur unter OpenSuse. Es gelang uns nicht, einen solchen Notfall-Rollback unter Manjaro, Debian oder Ubuntu zuverlässig umzusetzen. Da Zuverlässigkeit in einer solchen Situation von essenzieller Bedeutung ist, verzichten wir auf das Beschreiben der weiteren Schritte zum kompletten Rollback.

Das Umsetzen des beschriebenen Konzepts funktioniert zumindest bei Debian- und Arch-basierten Systemen, sollte sich aber auch auf andere Distributionen übertragen lassen. Wenn Sie den Notfall-Rollback als unverzichtbar erachten, müssen Sie derzeit direkt zu OpenSuse greifen, das Snapper von Haus aus tief im System und im Bootmanager verankert.

Fazit und Ausblick

Ein Testsystem von Snapper mit Ubuntu lässt sich an einem Nachmittag aufsetzen. Wer sich allerdings entscheidet, Btrfs und Snapper auf Produktivsystemen einzusetzen, kommt nicht darum herum, sich intensiver mit Btrfs zu beschäftigen. So kann man beispielsweise den freien Speicherplatz mit den üblichen Bordmitteln wie df -h nicht immer korrekt ermitteln: Dazu brauchen Sie Werkzeuge aus den Btrfs-Tools (Abbildung 13). Snapshots ersetzen im Übrigen keineswegs ein Backup: Bei einem kaputten Dateisystem hilft auch ein Snapshot nur bedingt.

Abbildung 13: Je mehr Snapshots das System bevölkern, desto mehr weichen die Angaben von Bordmitteln wie df -h vom realen Füllstand der Platte ab. Hier kommen die für Btrfs entwickelten Befehle zum Einsatz.

Ausführliche Informationen zu Snapper und Btrfs finden Sie bei Interesse bei OpenSuse [6], im Arch-Wiki [7] und bei Ubuntu [8]. Als weniger aufwendige, aber auch weniger mächtige Alternative zu Snapper bietet sich Timeshift [9] an. Darauf werden wir in der nächsten Ausgabe von LinuxUser näher eingehen.