Ein Bash-Skript genügt, um die vom Suse-Tool Snapper im Home angelegten stündlichen Snapshots ressourcenschonend auf eine externe Platte zu spiegeln. Dort überstehen sie auch Hardwareausfälle.

Eines der Alleinstellungsmerkmale von OpenSuse ist die Reversibilität von Software-Updates und Konfigurationsänderungen mit YaST. Die Basis dafür ist das von Suse entwickelte Tool Snapper, das seinerseits die vom Dateisystem Btrfs bereitgestellten Funktionen für differenzielle Snapshots nutzt. Die vorkonfigurierten Snapshots lassen sich mit einem Kommandozeilenaufruf auf die Daten im Home ausweiten.

Die von Btrfs bereitgestellten Send/Receive-Funktionen zur Übertragung von Snapshots auf einen anderen Datenträger nutzt Snapper nicht. Sie lassen sich jedoch leicht per Skript in den Vorgang der Snapshot-Erstellung einklinken. Das Ergebnis sind ohne ressourcenintensives Durchkämmen des Dateisystems erstellte differenzielle Backups auf einer externen Festplatte.

Bei SSDs muss man im Lauf der Jahre mit Lesefehlern (sogenannten gekippten Bits) rechnen. Festplatten verabschieden sich im schlimmsten Fall ohne warnende Vorzeichen. Kurz: Das Risiko, unwiederbringliche Daten auf nur einem Medium zu speichern, ist einfach zu groß. Ohne regelmäßige Backups sind Ihre Daten niemals sicher.

Diese OpenSuse-Tipps stellen ein Backup-Verfahren vor, das auf das von Suse entworfene, inzwischen distributionsübergreifend verfügbare Tool Snapper [1] aufsetzt (Abbildung 1). OpenSuse-Anwender profitieren davon, dass ihre Distribution Snapper vorinstalliert und einrichtet. Allerdings erzeugt Snapper zunächst nur Snapshots der Systempartition, die es jeweils nach einer Softwareinstallation oder der Benutzung von YaST anlegt. Um die Benutzerdaten im Home kümmert das Tool sich nicht.

Abbildung 1: Snapshots der Systempartition, die trotz differenzieller Speicherung die Root-Partition enthalten, entstehen in einer Standard-Installation im versteckten Verzeichnis ~/.snapshots/.

Ausgebaut

Ein Aufruf wie der aus der ersten Zeile von Listing 1 genügt, um ein neues Snapper-Profil zu erzeugen, das stündlich den Zustand der Home-Verzeichnisse aller Benutzer festhält. Das YaST-Modul Dateisystemschnappschuss (Abbildung 2) listet diese Snapshots in der Unified-Diff-Notation [2] auf, wenn Sie im Feld Aktuelle Konfiguration das eben erstellte Profil home auswählen. Die Spalte Startdatum nennt die Zeit der Erstellung der Snapshots.

Abbildung 2: Das YaST-Modul Dateisystemschnappschuss funktioniert auch für stündliche Snapshots im Home.

Wählen Sie einen Snapshot an und klicken auf Änderungen anzeigen, dann erscheint ein Dateibaum mit Auswahlkästchen (Abbildung 2). Die ausgewählten Dateien können Sie über die Schaltfläche Auswahl wiederherstellen in der Fassung vom Erstellungszeitpunkt des Schnappschusses ins Home-Verzeichnis zurückspielen. Das mit Administratorrechten laufende YaST-Modul erfasst dabei die Daten aller Benutzer. Auch inzwischen (versehentlich) gelöschte Dateien sind hier noch vorhanden.

Das Erstellen der Schnappschüsse bremst den Rechner nicht aus: Dabei müssen keine Daten kopiert werden, geschweige denn das ganze Home-Verzeichnis. Der neue Snapshot ist anfangs leer, das System liest noch unveränderte Daten aus dem vorherigen. Anders als bei konventionellen Dateisystemen bleiben die alten Daten erhalten, solang sie einem existierenden Snapshot zugeordnet bleiben. Neue Daten landen im aktuellsten Schnappschuss und lassen ihn anwachsen.

$ sudo snapper -c home create --description "Home Snapshots"
$ btrfs send -p /home/.snapshots/X-1/snapshot/ \
                /home/.snapshots/X/snapshot/ \
                | btrfs receive /backup/X

Gespiegelt

Da die Snapshots auf demselben Speichermedium liegen wie die eigentlichen Daten, helfen sie nur dann weiter, wenn Sie versehentlich eine Datei gelöscht haben oder auf frühere Dateiversionen zugreifen möchten. Bei einem Hardwaredefekt gehen die in derselben Partition liegenden Schnappschüsse jedoch ebenfalls verloren.

Zum Glück kennt das Linux-Dateisystem Btrfs mit dem Befehl btrfs send einen Mechanismus, um die festgehaltenen Daten effizient von einer Festplatte oder SSD auf eine andere zu übertragen. Auch hierbei fallen nur die Differenzdaten zwischen den Snapshot-Versionen an. Einen typischen Aufruf des Btrfs-Tools [3] zu diesem Zweck sehen Sie in den Zeilen 2 bis 4 von Listing 1. Dabei steht X für die Nummer des aktuellen Snapshots, X-1 für den vorausgehenden. Diese Schnappschüsse legt Snapper automatisch stündlich im versteckten Verzeichnis /home/.snapshots/ an. Sie können darauf statt mit dem YaST-Modul auch direkt zugreifen, allerdings nur als Root. Ungeachtet der differenziellen Speicherung erscheinen in jedem Unterverzeichnis alle Dateien im Home in der Fassung vom Erstellungszeitpunkt des Snapshots.

Wer sich mit der Linux-Kommandozeile beschäftigt hat, der weiß, dass das Pipe-Zeichen (|) die von einem Prozess ausgesandten Daten an einen anderen weiterleitet. In diesem Fall schickt btrfs send in Zeile 4 von Listing 1 die Daten, die sich zwischen Snapshot X-1 und Snapshot X verändert haben, an btrfs receive. Dieser Befehl legt daraus unter dem als /backup eingehängten Btrfs-Dateisystem einen neuen Schnappschuss an.

Zuerst brauchen Sie ein leeres Btrfs-Dateisystem als Backup-Speicherplatz. Am nützlichsten ist dafür eine USB-Festplatte, bei der Sie leicht an die Daten herankommen, falls der gesamte Rechner ausfällt. Starten Sie auf der Konsole mit sudo journalctl -f die Log-Überwachung und stecken Sie die externe Platte an. Abbildung 3 zeigt das Linux-Device-File für das Speichermedium. Formatieren Sie die Datenpartition der Backup-Platte mit mkfs.btrfs /dev/sdX1. Den Buchstaben für X müssen Sie entsprechend der Ausgabe von Journalctl anpassen.

Abbildung 3: Das System-Log von Linux nennt das Device-File eines neu angeschlossenen USB-Datenträgers.

Eine grafische Lösung zum Anlegen von Festplattenpartitionen und zum Formatieren mit einem bestimmten Dateisystem bietet GParted [4]. Wählen Sie in diesem Tool zuerst im Ausklappmenü rechts oben das per Journalctl ermittelte Device des USB-Laufwerks aus. Abbildung 4 zeigt das Erstellen einer neuen Partition mit dem hier nötigen Dateisystem Btrfs, die die ganze Platte umfasst.

Abbildung 4: Im Tool GParted entsteht per Rechtsklick auf den leeren Festplattenplatz ein Btrfs-Dateisystem. Die Funktion Alle Operationen ausführen (das Häkchen-Symbol rechts in der Schalterleiste) schreibt die vorausgewählten Änderungen auf das Speichergerät.

Um in GParted vorgewählte Operationen auszuführen, klicken Sie abschließend auf das Häkchen rechts in der Schalterleiste. Nach Abschluss der Formatierung öffnet ein Rechtsklick auf die als Block dargestellte Partition über die Option Information das Dialogfeld aus Abbildung 5. Es nennt die UUID des Dateisystems. Sie markieren diese lange Buchstaben-Zahlen-Folge mit der Maus und kopieren sie in die Zwischenablage.

Abbildung 5: GParted zeigt die UUID an, mit der Sie das Btrfs-Dateisystem auch dann zuverlässig einhängen, wenn sich die Reihenfolge der Festplatten oder SSDs im Rechner verändert.

Um das Btrfs-Dateisystem nach jedem Rechnerstart fest unter /backup einzuhängen, öffnen Sie als Root die Datei /etc/fstab und fügen die Zeile aus Listing 2 ein. Den Platzhalter UniversallyUniqueID ersetzen Sie dabei durch die in GParted herausgefundene UUID. Testen Sie den Eintrag mit sudo mount /backup. In Zukunft ist die Platte immer automatisch nach dem Systemstart eingebunden. Das funktioniert mit fest eingebauten Platten genauso wie mit externen Laufwerken.

UUID=UniversallyUniqueID /backup btrfs nofail,defaults 0 0

Sicherungsautomatik

Eine Backup-Lösung sollte vollautomatisch funktionieren, denn ein Unglück kommt selten allein. Bei händischen Sicherungen haben Sie womöglich gerade vor einem Ausfall des Speichergeräts das Backup vergessen oder hinausgeschoben. Ein Shell-Skript mit den send– und receive-Befehlen für Btrfs ist der erste Schritt. Speichern Sie dazu den Inhalt aus Listing 3 als Root in der Datei /usr/local/bin/snapper-timeline.sh.

#!/bin/bash
# snapper-timeline.sh - zeitgesteuerten Snapshot mit Snapper
/usr/lib/snapper/systemd-helper --timeline
# Nummer des letzten und vorletzten Snapshots ermitteln
last=$(snapper -c home list | tail -n1 | awk '{print $1}')
nexttolast=$(snapper -c home list | tail -n2 | head -n1 | awk '{print $1}')
# neues Unterverzeichnis für gespiegelten Snapshot
mkdir /backup/$last
# War der vorletzte Snapshot gespiegelt?
# Ja: inkrementelles Backup, nein: vollständiges Backup.
if [ -f /backup/$nexttolast/snapshot/ ]; then
  btrfs send -p /home/.snapshots/$nexttolast/snapshot/ \
                /home/.snapshots/$last/snapshot/ \
                | btrfs receive /backup/$last
else
  btrfs send /home/.snapshots/$last/snapshot/ \
             | btrfs receive /backup/$last
fi

Das Skript startet zunächst die (auch im Auslieferungszustand) von Snapper stündlich aufgerufene, für das Erzeugen der Snapshots verantwortliche Snapper-Komponente Systemd-helper (Zeile 3). Zusätzlich spiegelt es diesen Snapshot noch in ein anderes Btrfs-Dateisystem. Dazu gestaltet es die Send- und Receive-Befehle so, dass sie stets die Nummern des aktuell letzten und vorletzten von Snapper angelegten Snapshots referenzieren.

Der Code aus den Zeilen 5 und 6 ruft Snapper auf, um herauszufinden, wie diese Nummern lauten. Dabei wählt -c home das home-Profil. Das Kommando snapper list liefert eine Liste aller vorliegenden Snapshots (Abbildung 6), in deren erster Spalte die gewünschte Snapshot-Nummer steht. Der Befehl tail -n1 stutzt die Ausgabe von snapper list auf die letzte Zeile. Schließlich gibt awk '{print $1}') die erste Spalte dieser Zeile zurück. Sie enthält die gesuchte Nummer des jüngsten Snapshots.

Abbildung 6: snapper -c home list gibt eine Liste der Snapshots für das Profil home zurück. Sie enthält die Verzeichnisnamen für den Befehl btrfs send zum Spiegeln der Snapshots.

Das Konstrukt Variable=$(Befehl) weist die Shell an, die Rückgabe der hier per Pipe verketteten Befehle in der Variablen last zu speichern, in Zeile 5 also die Nummer des letzten Snapshots. Die folgende Skriptzeile wertet die vorletzte Zeile der Snapshot-Liste aus. Dazu greift sie per tail -n2 zuerst die letzten zwei Zeilen ab, wovon dann head -n1 die erste herausschält, also die vorletzte Zeile der ursprünglichen Befehlsrückgabe. In deren ersten Spalte steht folglich die Nummer des vorletzten Snapshots.

Dann folgt in Zeile 11 eine If-Abfrage, die testet, ob das Verzeichnis /backup/$nexttolast/snapshot/ existiert. Ist das der Fall, dann erzeugt der folgende Block ein inkrementelles Backup. Der Parameter -p weist Btrfs an, das folgende Verzeichnis des vorletzten Backups als Differenz-Parent zu verwenden. Liegt dieses Verzeichnis nicht gespiegelt im Ordner /backup vor, dann erstellt der Code aus dem im Else-Block (ab Zeile 15) ein vollständiges, nicht differenzielles Backup. Das nur beim ersten Aufruf des Skripts nötig sein sollte.

Eingeklinkt

Sie müssen jetzt nur noch dafür sorgen, dass das System statt des normalen Mechanismus zur stündlichen Snapshot-Erzeugung das neue Skript aufruft. Da Snapper dafür Systemd-Timer [5] verwendet, ist das nicht schwer umzusetzen. Sie erstellen dazu als Root die Datei /etc/systemd/system/snapper-timeline.service mit dem Inhalt aus Listing 4.

[Unit]
Description=Timeline of Snapper Snapshots
Documentation=man:snapper(8) man:snapper-configs(5)
[Service]
Type=simple
# ExecStart=/usr/lib/snapper/systemd-helper
ExecStart=/usr/local/bin/snapper_timeline.sh

Bei diesem File handelt es sich um eine Konfigurationsdatei für einen Systemdienst. Die unter /etc/systemd/system/ abgelegte Version überschreibt die mit Snapper mitgelieferte Systemdienstkonfiguration. Sie ersetzt im Parameter ExecStart den noch auskommentiert zu sehenden Aufruf (Zeile 6) der Snapper-Komponente Systemd-helper durch das neue Skript (Zeile 7). Ein Timer, der den nun neu definierten Dienst snapper-timeline stündlich startet, ist im Auslieferungszustand von OpenSuse vorinstalliert.

Damit haben Sie eine vollwertige Backup-Lösung erstellt, die das System nicht spürbar ausbremst. Wer die gesicherten Daten benötigt, könnte es nicht leichter haben: In jedem nummerierten Unterverzeichnis finden Sie die vollständigen Home-Verzeichnisse aller Benutzer. Die Daten lassen sich sowohl einzeln als auch am Stück zurückkopieren. Das Erstellungsdatum des Snapshots zeigt der Dateimanager.

Doch es gibt Verbesserungspotenzial: Die Daten liegen doppelt vor, einmal in Ihrer Home-Partition und zusätzlich auf der Backup-Festplatte. Auf der Home-Partition kümmert sich Snapper darum, obsolete Daten zu löschen, damit auf dem Speichermedium der Platz nicht ausgeht. Auf der Backup-Platte dagegen bleiben die gespiegelten Snapshots auch nach dem Löschen des Originals weiter erhalten. Die Platte läuft dadurch zwangsläufig irgendwann voll, was allerdings dank differenziellen Snapshots bei typischen Datenmengen meist Monate dauert. Wenn Sie, wie es sich dringend empfiehlt, regelmäßig die Integrität der Backups prüfen, bemerken Sie das in der Regel rechtzeitig.

Möchten Sie sich im Erstellen von Bash-Skripten üben, könnten Sie dem Skript eine Funktion hinzufügen, die die ältesten Snapshots unter /backup löscht, wenn ein Grenzwert für freien Speicherplatz unterschritten wird. Dabei gilt es, zu beachten, dass es sich bei den unter ~/.snapshots/ liegenden durchnummerierten Verzeichnissen nicht um gewöhnliche Dateiordner handelt, sondern um sogenannte Subvolumes [6], ein Feature des Btrfs-Dateisystems. Ein Versuch, sie auf herkömmliche Weise zu löschen, endet mit einem Fehler. Sie müssen die Volumes als Root mit dem Kommando aus Listing 5 entfernen.

# btrfs subvolume delete /backup/Verzeichnis

Datenhaltung

Bei Snapshots übernimmt das Dateisystem selbst die sogenannte Deduplikation: Es sorgt dafür, dass gleiche Dateien nur einmal Platz belegen, egal, in wie vielen Snapshots sie vorkommen. Die eingesetzte Technik heißt Copy on Write (CoW). Dabei verweisen alle Klone einer Datei zunächst auf dieselben Datenblöcke. Erst, wenn sich die Datei in einer Instanz verändert, teilt das Dateisystem neue Datenblöcke zu, während die unveränderten Fassungen weiterhin auf die alten Daten verweisen.

Differenzielle Backup-Verfahren nach der Methode der 2006 von Apple vorgestellten Time Machine [7] und deren Linux-Klon Back in Time [8] gehen genau umgekehrt vor (Abbildung 7): Sie durchkämmen zuerst das ganze Dateisystem nach Veränderungen. Alle veränderten Dateien kopieren sie in den neuen Snapshot, während sie für unveränderte Dateien lediglich Verknüpfungen (Hardlinks) auf den vorherigen Snapshot anlegen.

Abbildung 7: Halbstündige Snapshots mit Back in Time sind beim Schreiben von Artikeln nützlich, weil man jederzeit auf ältere Versionen zurückgreifen kann.

In beiden Fällen ergibt sich eine fortlaufende stündliche Reihe von Abbildern des früheren Zustands des Dateisystems. In beiden Fällen belegen nur veränderte Dateien Platz. Der Unterschied zum hier vorgestellten Verfahren hält dabei das Dateisystem selbst fest, welche Dateien sich verändern (Abbildung 8). Anderenfalls müsste man das ganze Home mit oft Zigtausend Dateien auf Änderungen durchforsten.

Abbildung 8: Rsync muss pro Snapshot alle Dateien auf Änderungen überprüfen, während das Dateisystem Btrfs in seiner Copy-on-Write-Technik live protokolliert, welche Datei(-blöcke) sich seit dem letzten Snapshot verändert haben.

Die Snapper-Konfigurationsdatei für das im Artikel erstellte Profil home liegt in der Datei /etc/snapper/configs/home. Hier sorgen die vorgegebenen Einstellungen von SPACE_LIMIT und FREE_LIMIT dafür, dass Snapshots maximal das halbe Laufwerk belegen und gleichzeitig 20 Prozent des Gesamtspeicherplatzes frei bleibt.

Im Rahmen der Speicherplatz-Quotas regeln die mit TIMELINE beginnenden Konfigurationsoptionen, wie viele der im Home erzeugten zeitgesteuerten Snapshots erhalten bleiben. Die Option TIMELINE_MIN_AGE="1800" garantiert in der Voreinstellung, dass Snapshots mindestens eine halbe Stunde (1800 Sekunden) verfügbar bleiben. Ansonsten konserviert das System entsprechend den TIMELINE_LIMIT-Optionen jeweils zehn Snapshots vom selben Tag, aus dem aktuellen Monat und pro Jahr.

Unser Skript würde mit einem Minimum von 2 für TIMELINE_LIMIT-HOURLY (letzter und vorletzter Snapshot) und 0 für alle anderen TIMELINE_LIMIT-Einstellungen funktionieren. Alle Snapshots außer dem letzten und vorletzten wären dann nur gespiegelt unter /backup verfügbar. Die Tatsache, dass Snapper 20 Prozent Speicherplatz frei hält, dürfte aber in der Regel genügen. Eine Anpassung des Snapper-Profils ist dann nicht erforderlich.

Zeiteinstellung

Tatsächlich lässt sich der zeitliche Abstand zwischen den Snapshots in der Snapper-Konfiguration selbst nicht verändern. Da Snapper jedoch den zeitgesteuerten Start einem Standard-Systemd-Timer überlässt, gelingt es ebenso leicht, ihn zu verändern, wie für den snapper_timeline-Dienst. Auch in diesem Fall überschreibt eine Kopie im Verzeichnis /etc/systemd/system/ die mitgelieferte Version und übersteht auch Updates von Snapper.

Erstellen Sie als Basis die Datei /etc/systemd/system/snapper-timeline.timer mit dem Inhalt aus Listing 6. Die dort gezeigte Konfiguration ist noch identisch mit der mitgelieferten, bei der der Timer den gleichnamigen Dienst snapper-timeline.service stündlich startet. Bei Bedarf verändern Sie nun den Wert für OnCalendar. Mögliche Textkurzfassungen dafür lauten daily (täglich) oder weekly (wöchentlich). Der Parameter *:0/XX startet das Backup dagegen alle XX Minuten.

[Unit]
Description=Timeline of Snapper Snapshots
Documentation=man:snapper(8) man:snapper-configs(5)
[Timer]
OnCalendar=hourly
[Install]
WantedBy=timers.target

Auswirkungen

Sowohl das Anpassen des Systemd-Diensts als auch des zugehörigen Timers betrifft alle Snapper-Profile, auch das nach der OpenSuse-Installation bereits aktive Profil root. Nach der Installation unter Leap 15.5 war jedoch das Erstellen von zeitgesteuerten Snapshots für die Systempartition ohnehin abgeschaltet: TIMELINE_CREATE in der Datei /etc/snapper/configs/root war auf no gesetzt. Solang das so bleibt, haben unsere Anpassungen keine Auswirkungen auf die Snapshots von Systemdaten nach Updates oder dem Einsatz von YaST. Selbst wenn Sie TIMELINE_CREATE für root aktivieren, erzeugt systemd-helper --timeline (Listing 3, Zeile 3) Snapshots für die System- und die Home-Partition.

Das Skript spiegelt weiterhin nur die Snapshots für home auf die externe Platte. Ein Verändern der Frequenz im Timer wirkt sich dann aber auf die Snapshots der Systempartition und des Homes aus. Auch sollten Sie TIMELINE_CREATE für home nicht deaktivieren, solang der Dienst snapper_timeline.service sich im beschriebenen angepassten Zustand befindet. Wenn Sie keine zeitgesteuerten Snapshots im Home mehr wünschen, müssen Sie auch die Datei /etc/systemd/system/snapper-timeline.service wieder löschen, sodass die ursprüngliche Dienstkonfiguration wieder zum Tragen kommt.

Weitere Details zu Snapper erläutert eine deutschsprachige Seite im OpenSuse-Wiki [1]. Außerdem gibt es eine ausführlichere, für Administratoren gedachte englischsprachige Beschreibung [9] für die Suse-Enterprise-Distribution, wo Snapper genauso funktioniert wie unter OpenSuse.

Fazit

Das bei OpenSuse vorinstallierte Tool Snapper lässt sich leicht so aufbohren, dass es äußerst ressourcenschonend differenzielle Backups automatisiert auf einer externen Festplatte ablegt. Damit lagern Sie Ihre wertvollen Daten ausfallsicher und leicht wiederherstellbar. (uba/jlu)