Serie: Arch - bootbare Btrfs Snapshots mit UKI und Rollbackfunktion (Teil 2)

Inhaltsverzeichnis

• Einleitung
• Teil 1: Unified Kernel Image & systemd-boot einrichten in Arch Linux
• Teil 2: Automatische Btrfs Snapshots mit `snapper` und Co. (das ist dieser Artikel)
• Teil 3: Arch Linux Bootbare Btrfs Snapshots mit UKIs

Teil 2

Snapper ist ein Snapshot Manager für Btrfs Dateisysteme, welcher den Grundbaustein für die Automatisierung von Snapshots legt. Info: Btrfs unterscheidet intern nicht zwischen Snapshots und Subvolumes - ein Snapshot ist technisch einfach eine Subvolume. Die Unterscheidung dient lediglich als mentale Hilfe.

Wir benötigen 3 Pakete:

• snapper (Grundbaustein, Snapshot Manager)
• snap-pac (Erstellt vor und nach pacman Operationen Snapshots mit snapper)
• snapper-rollback AUR (Vereinfacht den Rollback auf einen älteren Snapshot)

Wichtig: Dein System benötigt ein Subvolume Layout wie im Arch Wiki Eintrag für Snapper beschrieben. In meiner Arch Installationsanleitung kannst du unter Festplatte(n) konfigurieren nachschauen, wie du ein solches Layout erstellst. Alternativ ist das Arch Wiki wohl das bessere Nachschlagewerk.

Snapper konfigurieren

Die Installation von snapper habe ich auch bereits in meiner Arch Installationsanleitung beschrieben, deswegen werde ich mich hier nicht wiederholen. Dem Tutorial kann ab Automatische Snapshots mit Snapper bis und mit Snapper timeline Services aktivieren gefolgt werden, den Rest brauchen wir im Rahmen dieser Tutorialreihe nicht. Falls du dem Tutorial folgst: Verringere die Anzahl an stündlichen und täglichen Snapshots etwas; 5 respektive 7 ist etwas viel.

Timeline Snapshots sind automatische Snapshots, die zeitbasiert nach den Regeln in der Konfigurationsdatei erstellt werden. Number Snapshots sind reguläre Snapshots, die mit manuell snapper create erstellt werden. Mit snap-pac erstellte Snapshots sind Number Snapshots.

Der Systemd Service snapper-timeline.timerverwaltetden Timer für timeline Snapshots, der snapper-cleanup.timer Service löscht alte Snapshots automatisch nach den Regeln in der Konfigurationsdatei.

Ich habe mittlerweile die timeline Snapshots deaktiviert (TIMELINE_CREATE="no") da ich mich auf snap-pac basierte Snapshots beschränke. Wir bearbeiten die Konfigurationsdatei /etc/snapper/configs/root, um immer mindestens 20 als "important" markierte Snapshots zu behalten. 20, da jede Upgrade Aktion ein "Pre" und "Post" Snapshot erstellt, die beide als "important" markiert werden (machen wir gleich danach).

# run daily number cleanup
NUMBER_CLEANUP="yes"

# limit for number cleanup
NUMBER_MIN_AGE="3600" # in sekunden
NUMBER_LIMIT="50" # standardwert, maximale Anzahl an Snapshots
NUMBER_LIMIT_IMPORTANT="20"

snap-pac konfigurieren

Das snap-pac Paket befindet sich in der extra Repository. Nach der Installation ist es sofort im Einsatz.

sudo pacman -S snap-pac

Wir müssen snap-pac so konfigurieren, dass ein Upgrade Befehl als important markiert wird. So stellen wir sicher, dass die Snapshots der letzten 10 Upgrades nicht gelöscht werden. Dazu bearbeiten wir die Datei /etc/snap-pac.ini.

[root]
important_commands = ["pacman -S -y -u --config /etc/pacman.conf --", "pacman -S -u -y --config /etc/pacman.conf --", "pacman -Syu", "pacman -Syyu"]

Ich aktualisiere mein System hauptsächlich mit yay. Die ersten beiden Befehle spuckt yay beim Aufruf ohne weitere Optionen aus. Aus welchem Grund auch immer kann es vorkommen, dass die Reihenfolge der Optionen entweder -S -y -u oder -S -u -y sein kann. Egal, hier können einfach alle Befehle angegeben werden, die als "important" markiert werden sollten. Falls du paru nutzt, musst du mit snapper list in der Spalte Description überprüfen, welchen Befehl er bei einem Update genau ausspuckt. Die normalen Upgrade Befehle von pacman habe ich auch hinzugefügt. Aktualisiere dein System, wie du es sonst auch machen würdest, und überprüfe mit snapper list, ob in der Userdata Spalte für den Upgrade Snapshot important=yes steht.

snapper-rollback konfigurieren

snapper-rollback ist ein Script aus dem Arch User Repository, welches den Rollback auf einen spezifischen Snapshot automatisiert. Installiere es mit deinem bevorzugten AUR helper. Was es macht ist:

• mountet das Btrfs Top Level (Subvolume ID 5) vorübergehend an der angegebenen Stelle, damit es da die Subvolumes bearbeiten kann
• benennt die aktuelle Root Subvolume (@) um (Backup des aktuellen Zustands)
• erstellt ein read-write Snapshot des angegebenen Snapshots mit dem Namen @

Nach Neustart mountet das System ganz normal die neue @ Subvolume als Root, der Rollback ist somit abgeschlossen.

Die Konfiguration ist simpel. Zuerst erstellen wir einen Ort, an dem das Btrfs Top Level vorübergehend gemountet wird.

sudo mkdir /mnt/btrfsroot

Die Konfigurationsdatei /etc/snapper-rollback.conf braucht noch gewisse Informationen.

# Name der snapper Konfiguration für die root Subvolume
[root]
# Name der root Subvolume
subvol_main = @
# Name der snapshots Subvolume
subvol_snapshots = @snapshots
# Hier wird vorübergehend der btrfs root gemountet
mountpoint = /mnt/btrfsroot
# Gerät, welches den btrfs root beinhaltet, also deine root Partition
# meine ist verschlüsselt, bei dir könnte hier /dev/sda2 stehen
dev = /dev/mapper/cryptroot

Rollback

Wichtig: Kernel und initramfs in der "standard" UKI (arch-linux.efi) müssen immer mit dem Kernel/initramfs des aktuellen Systems (@ Subvolume) übereinstimmen. Diese Regel gilt auch für Snapshot-UKIs und die dazugehörigen Snapshots.

Dieses Setup ist so ausgelegt, dass Rollbacks nur aus einem gebooteten Snapshot heraus ausgeführt werden. In diesem Fall sind die passenden Kernel- und initramfs Versionen bereits geladen, und wir erstellen vor dem Neustart neue "standard" UKIs basierend auf diesem Zustand (dazu kommen wir im dritten Teil der Tutorialreihe).

Obwohl ich es nicht empfehle, ist ein Rollback grundsätzlich auch möglich, wenn du die @ Subvolume gebootet hast (arch-linux.efi). Allerdings musst du dir sicher sein, dass sich Kernel und initramfs zwischen dem aktuellen @ Subvolume und dem gewünschten Snapshot nicht geändert haben. In diesem Fall ist kein Neubau der "standard" UKIs erforderlich.

Stimmen die Versionen nicht überein, kannst du Glück haben und das System bootet trotzdem. In diesem Fall musst du nach dem Neustart die "standard" UKIs zwingend neu bauen. Wenn du einen Snapshot wählst, für den eine passende Snapshot UKI existiert, kannst du manuell das Kernel image und das initramfs daraus extrahieren und damit neue "standard" UKIs bauen, ist jedoch mit etwas Handarbeit verbunden.

Bootet das System nicht mehr, sieht der Weg zur Recovery etwas holpriger aus. Du müsstest mit einem Arch Installationsmedium ins System chrooten und die Schritte vom snapper-rollback Script manuell rückgängig machen.

Rollback:

# Snapper Snapshots auflisten, gewünschten Snapshot aussuchen und [ID] merken
snapper list
sudo snapper-rollback [ID]
# "standard" UKIs neu bauen um Kernel und initramfs zu synchronisieren
sudo mkinitcpio -P
sudo reboot
# Nach neustart pacman db lock datei löschen falls vorhanden
sudo rm /var/lib/pacman/db.lck

Das war der Snapshot Teil. Im dritten und letzten Teil automatisieren wir die Erzeugung der UKIs, um direkt in einen Snapshot zu booten.

Quellen:
https://wiki.archlinux.org/title/Main_page