Mit den richtigen Tools erzeugen Sie verschlüsselte Backups in der Cloud, aus denen Sie selbst im Katastrophenfall Ihre wertvollen lokalen Daten jederzeit wiederherstellen können.

Proprietäre Lösungen gehören in meinen Augen stets in die Kategorie, die ich häufig mit “niedrigster Priorität” klassifiziere. Tatsächlich fühle ich mich immer dann besonders wohl, wenn ich Prozesse über Linux-Bordmittel abbilden kann oder sie zumindest nur wenig zusätzliche Software erfordern.

Vor allem wegen der Option --link-dest eignet sich Rsync [1] hervorragend zum Erzeugen von Backups. Der große Bonus von --link-dest liegt darin, dass es den aktuellen Rsync-Lauf mit einem bestehenden vergleicht. Neue und veränderte Dateien legt das Tool dabei im Zielverzeichnis wie gewohnt an, für unveränderte Dateien erstellt es im Zielverzeichnis Hardlinks.

Hardlinks sind ein Feature der gängigen Dateisysteme für Linux. Prinzipiell steckt dahinter ein Eintrag im Dateisystem. Jeder Hardlink besteht aus einem Namen und einer Inode-Adresse. Demzufolge gehört zu jeder Datei mindestens ein Hardlink, denn sonst ließe sich ihr Inhalt gar nicht finden. Gibt es nun mehrere Hardlinks zu ein und derselben Datei, lässt sich nicht ohne Weiteres sagen, hinter welchem davon sich das Original verbirgt (oder verborgen hat).

Rsync macht also nichts anderes, als den Inhalten, die im Dateisystem unverändert vorliegen, einen weiteren Namen zu geben. Tatsächlich ist das Vorgehen ebenso elegant und simpel wie genial. Wer fit im Scripting ist, kann sich so ein eigenes Backup-Skript auf Rsync-Basis anlegen.

Als ich mich vor vielen Jahren erstmals ernsthaft mit dem Thema Backup beschäftigte, war ich mir meiner Bash-Kenntnisse nicht sicher. Ich recherchierte deswegen nach einer Art Wrapper-Skript, das mir Themen wie vorgehaltene Kopien, automatisches Löschen nach Ablauf der Retention etc. abnehmen sollte. Fündig wurde ich schließlich bei Rsnapshot: Dabei handelt es sich um ein Perl-Skript, das außer Perl selbst keine weiteren Abhängigkeiten aufweist – also genau das, was ich suchte.

Rsnapshot

Die Konfiguration von Rsnapshot ging leicht von der Hand. Das liegt durchaus auch daran, dass die Entwickler die mitgelieferte Konfigurationsdatei /etc/rsnapshot.conf ausgezeichnet kommentiert haben und dementsprechend kaum Fragen offen blieben.

Im Kopfbereich haben die Maintainer Definitionen zu Abhängigkeiten zu externen Programmen eingebaut, die ich kurzerhand alle übernommen habe. Falls Sie hier erweiterte Funktionen wie Backups von Remote-Systemen benötigen, können Sie beispielsweise SSH aktivieren.

Zwei Variablen-Definitionen möchte ich noch explizit erwähnen: Mit cmd_preexec und cmd_postexec gibt es ein mächtiges Werkzeug, um bestimmte Vor- und Nachbedingungen zu einem Backup herzustellen, etwa eine Datenbank kurz zu stoppen oder ähnliches (Listing 1).

# Specify the path to a script (and any optional arguments)
# to run right before rsnapshot syncs files
# cmd_preexec> /path/to/preexec/script
#
# Specify the path to a script (and any optional arguments)
# to run right after rsnapshot syncs files
# cmd_postexec> /path/to/postexec/script

Der wohl wichtigste Parameter im Header-Bereich heißt snapshot_root (Listing 2). Er definiert, wo Rsnapshot die Backups ablegen soll. Je nach persönlichem Datenaufkommen müssen Sie dieses Volume entsprechend groß skalieren. Hier eine allgemeine Empfehlung abzugeben, fällt mir wahrlich nicht leicht: Der Bedarf an Backup-Speicherplatz richtet sich nach der Volatilität der zu sichernden Daten und deren Vorhaltezeit (Retention). Als Faustregel halte ich mich für snapshot_root an das Drei- bis Vierfache des ursprünglichen Festplattenspeichers.

# All snapshots will be stored under this root directory.
# snapshot_root> /var/cache/rsnapshot/
snapshot_root>  /backup/rsnapshot/

Backup Retention – der Begriff ist ja bereits gefallen – bestimmt die Aufbewahrungszeit von Backups. Rsnapshot bringt für die Retention vier Backup-Level oder Intervalle mit: hourly, daily, weekly und monthly. Alle Level nehmen einen ganzzahligen Wert in der Konfigurationsdatei an, der dann wiederum festlegt, wie viele Backups das Tool im entsprechenden Level vorhalten soll. Listing 3 definiert zum Beispiel vier stündliche, sieben tägliche, vier wöchentliche und ein monatliches Backup.

retain> >   hourly> 4$
retain> >   daily>  7$
retain> >   weekly> 4$
retain> >   monthly>1$

Bei jedem Aufruf von rsnapshot hourly entsteht ein neues Backup des Dateisystems, das Rsnapshot in $snapshot_root/hourly.0/ ablegt. Der Rest der vorgehaltenen Backups rotiert es durch, indem es die Ziffer im Ordnernamen erhöht. Sprich: Wenn ich rsnapshot hourly drei Mal aufrufe, liegt das ursprüngliche Backup 0 nun in $snapshot_root/hourly.3/. Mit einem vierten Aufruf würde dieses Backup aus der Retention fallen.

Der Übertrag auf den Daily-Level funktioniert folgendermaßen: Stoße ich ein rsnapshot daily an, erzeugt Rsnapshot aus $snapshot_root/hourly.3 ein $snapshot_root/daily.0/. Das älteste Hourly-Backup wird somit zum nächsten Daily-Backup. Bei der Rotation von Daily auf Weekly funktioniert der Vorgang analog: Rsnapshot erzeugt aus $snapshot_root/daily.6/ das Backup $snapshot_root/weekly.0, und so weiter.

Man ruft die jeweiligen Rsnapshot-Level idealerweise über eine eigene Crontab auf. In meinem Fall ist das /etc/cron.d/rsnapshot (Listing 4).

$$nonumber
42 */6 * * * root /usr/bin/rsnapshot hourly
7    1 * * * root /usr/bin/rsnapshot daily
13   3 * * 1 root /usr/bin/rsnapshot weekly
35   4 1 * * root /usr/bin/rsnapshot monthly

Da ich nur vier Hourly-Backups anfertige, muss ich sie so über den Tag verteilen, dass nicht mehr Sicherungen starten als vorgehalten werden. Anderenfalls könnte es unter Umständen zu Datenverlusten kommen. Wie Sie in der Crontab erkennen können, erzeugt Rsnapshot bei mir alle sechs Stunden zur Minute 42 ein Backup. Abbildung 1 zeigt, wie $snapshot_root/ nach einem Monat aussieht.

Abbildung 1: In meinem Fall legt Rsnapshot alle sechs Stunden zur Minute 42 ein Backup an.

Katastrophenschutz

Im September 2021 kam es zu einem Ereignis, mit dem in dieser Art wohl kaum jemand gerechnet hatte. Das Tief Bernd brachte massive Niederschläge und löste damit eine der schwersten Überschwemmungskatastrophen aus, die Deutschland je sah. Innerhalb weniger Stunden wurden Menschen obdachlos und standen plötzlich vor dem Nichts.

Das Hochwasser vor allem im Ahrtal diente retrospektiv als Anlass für mich, zu überdenken, wie ich meine Daten sichern wollte. Ich digitalisierte daraufhin tatsächlich einen großen Teil meiner wichtigen Dokumente. Sofern ich in der Lage wäre, das ein oder andere Medium zu retten, wäre ich mit einem gewissen Aufwand durchaus zügig wieder in der Lage, beispielsweise bestimme Nachweise zu erbringen – vorausgesetzt, ich schaffe es, eben diese Datenträger zu retten.

Die Überschwemmungskatastrophe im Ahrtal zeigte mir jedoch, dass dies letztlich nichts mehr als ein frommer Wunsch ist. Unwahrscheinlich, dass es mir gelingt, in solch einer lebensbedrohlichen Situation kühlen Kopf zu bewahren und die wichtigsten SSDs mitzunehmen. Hier musste also eine andere Lösung her.

Qual der Wahl

Im März dieses Jahres besuchte ich auf den Chemnitzer Linux-Tagen den Vortrag “Verschlüsseltes Cloud-Backup mit Linux-Bordmitteln” [2], gehalten von Bernd Strößenreuther. Er warf einige offene Fragen in den Raum, denen ich so bislang nicht allzu viel Beachtung geschenkt hatte. Etwa (sinngemäß): “Wie kommt ihr an eure Daten, wenn sämtliche Password-Safes und 2FA-Devices verloren sind?” Das gab mir zu denken. Vor allem aber motivierte es mich, mein bisheriges Offsite-Backup in eines der vielen WebDAV-basierten Cloud-Drives zu hinterfragen.

Die im Vortrag erwähnte Lösung Gocryptfs [3] mochte praktikabel sein, traf aber nicht so richtig meinen Geschmack. Deswegen begann ich in den darauffolgenden Tagen nach Tools zu recherchieren, die meine Ansprüche besser bedienten. Meine Ansprüche waren:

• wenige Abhängigkeiten,
• keine Daten verlassen unverschlüsselt das Haus, und
• als Protokoll dienen SSH oder Rsync.

Letztlich landete ich bei BorgBackup [4] und Restic [5]. Tatsächlich war BorgBackup meine erste Wahl. Restic probierte ich zunächst nur aus, um sicherzustellen, dass ich bei BorgBackup richtig liege. Beide Tools erfüllen meine Anforderungen, wie Verschlüsselung vor dem Upload, beide unterstützen geeignete Protokolle, beide deduplizieren. Am Ende machte dann doch Restic das Rennen, da es mir zum einen in Sachen Look & Feel sympathischer war und zum anderen mehrere Systeme pro Repository sichern kann. Letzteres würde voraussichtlich deutlich bessere Ergebnisse bei der Deduplizierung liefern.

Hoster, die die entsprechenden Protokolle anbieten, gibt es viele. Die persönliche Suchmaschine des Vertrauens wird bei den Begriffen “storage as a service sftp rsync” sicher mehrere ausspucken, die ich hier nicht thematisieren will. Worauf ich aber definitiv hinweise, ist ein wichtiger Punkt von Bernd Strößenreuther: Bitte bedenken Sie stets, dass im Fall der Fälle mit den eigenen Geräten obendrein kryptografische Schlüsselpaare verlorengehen. Wer seine Daten per Public Key verschlüsselt, steht am Ende ohne USB-Stick, FIDO2-Token, Smartphone oder Notebook da.

Demzufolge beschloss ich, auf die erwähnten starken Authentifizierungsmethoden zu verzichten. Stattdessen wählte ich sämtliche Passwörter maximal komplex und druckte sie zusammen mit weiteren Informationen zum Restore-Prozess zweifach aus. Die beiden Kuverts mit den Credentials befinden sich an unterschiedlichen Orten fernab meiner Wohnung, sodass ich – einen Atomkrieg oder einen massiven Asteroideneinschlag ausgenommen – vermutlich bestens aufgestellt bin.

Restic einrichten

Restic einzurichten fällt nicht weiter schwer (Listing 5, erste Zeile). Das Setup geht ebenfalls leicht von der Hand: Zunächst initialisiere ich mein neues Repository, also den Ort der Backups (zweite Zeile). Restic fordert anschließend ein Passwort für das Repository an. Da ich mich ganz bewusst gegen Public Key Authentication entschieden habe, wähle ich das Passwort dementsprechend komplex.

Das Backup wird hoffentlich nie oder im Fall der Fälle auch nur dann zum Einsatz kommen, wenn alle anderen Sicherungen nicht mehr zu gebrauchen sind und ich das Passwort vom Papier abtippen muss. Daher beschränke ich mich im Passwortgenerator auf alphanumerische Zeichen und einige wenige Symbole. Die notwendige Komplexität erreiche ich über die Passwortlänge von 30 Zeichen. Eingabe und Bestätigung des Passworts quittiert Restic, wie in Listing 5 zu sehen, mit einer unmissverständlichen Warnung.

$ sudo apt install restic
$ restic -r sftp:user@host:/pfad/zum/repo init
enter password for new repository: ********************
enter password again: ********************
created restic repository e2f4317359 at sftp:user@host:/pfad/zum/repo
Please note that knowledge of your password is required to access the repository.
Losing your password means that your data is irrecoverably lost.

Das Repository steht nach erfolgreichem Init-Prozess bereit für einen Sicherungslauf. Ein Backup nennt sich im Restic-Jargon Snapshot. Um einen solchen Schnappschuss zu erzeugen, benötige ich neben dem Passwort die Adresse des Repositorys – und zwar bei jeder Interaktion, sei es nun ein Backup oder lediglich ein Status-Check über den belegten Speicherplatz beziehungsweise die vorhandenen Snapshots.

Da ich bei manuellen Prozessen notorisch nachlässig bin, muss ich das Passwort auf der Backup-Maschine hinterlegen und beim Ausführen eines Backups an Restic übergeben. Freilich birgt es ein Sicherheitsrisiko, ein Klartextpasswort auf einem Server zu lagern. Allerdings ist mir keine Alternative zum Umschiffen dieser Klippe bekannt. Andere Authentifizierungsmechanismen kommen aus erwähnten Gründen nicht infrage.

Meine Konstruktion fiel daher folgendermaßen aus: Repository-Adresse und Passwort stehen als Export-Anweisung in einem Shell-Skript, das ausschließlich Root lesen kann und das in /usr/local/sbin/ liegt. Das Skript exportiert die Umgebungsvariablen RESTIC_REPOSITORY und RESTIC_PASSWORD. Die eigentlichen Worker-Skripts lesen beim Start das Environment-Skript rstcenv.sh ein (Listing 6, zweite Zeile), führen somit die enthaltenen Export-Kommandos aus und kommen auf diese Weise an die Zugangsdaten. Daraufhin erzeugt das Backup-Skript eine neue Sicherung.

#!/bin/bash
source /usr/local/sbin/rstcenv.sh
# Restic ausführen
restic backup \
    /home \
    /etc \
    /root \
    /usr/local/bin \
    /usr/local/sbin

Daten wiederherstellen

Backup ist gut, Restore ist noch besser. Wenn Sie Daten sichern, sollten Sie unbedingt regelmäßig verifizieren, dass sich die Sicherungen auch tatsächlich wiederherstellen lassen. Restic gibt per restic snapshots über die enthaltenen Snapshots Auskunft (Abbildung 2)

Abbildung 2: Der Befehl restic snapshot informiert Sie über den Status der Backups.

Das Restore von Dateien gestaltet sich mit Restic ebenso intuitiv wie das Backup. Gesetzt den Fall, ich habe mein bevorzugtes Katzenvideo versehentlich aus sämtlichen lokalen Sicherungen gelöscht, dann stelle ich es mithilfe eines einzigen Befehls einfach wieder her. Im entsprechenden Kommando aus der ersten Zeile von Listing 7 bezeichnet latest den aktuellen Snapshot. Restic sichert in diesem Fall sämtliche Dateien unterhalb von target zurück, die den Namen fav_cat_video.mp4 tragen.

Gelegentlich kann es passieren, dass Sie eine vollständige Rücksicherung benötigen. Dafür benötigt Restic lediglich die Snapshot-ID (oder auch latest) sowie ein Zielverzeichnis (Listing 7, zweite Zeile).

$ restic restore latest --target /mnt/restore --include fav_cat_video.mp4
$ restic restore 42ccc106 --target /mnt/restore

Fazit

Ich wollte zuallererst ein vernünftiges, automatisches Backup auf einer zusätzlichen lokalen Platte haben. Mit Rsnapshot und Restic habe ich überaus zuverlässige Werkzeuge aufgetan, die Backups in einer Art und Weise erzeugen, die ein Restore zum Kinderspiel macht – noch dazu bei minimalen Abhängigkeiten und ausgesprochen unkomplizierter Konfiguration. (csi)