Zuverlässiger als jede Datenrettung ist ein aktuelles Backup. Damit es aber tatsächlich auch stattfindet, muss es einfach von der Hand gehen.

Die einfachste Form des Backups ist eine Kopie der Daten auf einen mobilen Datenträger wie einen USB-Stick oder eine externe USB-Festplatte. Das erledigen Sie entweder über den Dateimanager oder einen Kopierbefehl wie cp -a Quelle Ziel aus dem Terminal heraus. Das Kommando kopiert mit der Archiv-Option -a rekursiv und nimmt auch die Rechte der Dateien mit. Gibt es das Zielverzeichnis nicht, dann erstellt der Befehl es als Kopie der Quelle samt Inhalt. Existiert es dagegen bereits, dann enthält es nach dem Kopiervorgang ein Unterverzeichnis namens Quelle.

Der Cp-Befehl mit einer einzigen Option lässt sich einfach merken, hat aber eine Reihe von Nachteilen. Exotische Dateien und Attribute überfordern CP. Obendrein ist der Vorgang ineffizient, da er stur alle Quelldateien kopiert. Zudem erfolgt keinerlei Verifikation des Ergebnisses.

Aus diesem Grund verwenden Profis den komplizierteren Befehl aus Listing 1. Dabei kommt Rsync zum Einsatz, das bei so gut wie jeder Distribution zur Grundausstattung gehört. Auch hier gibt es die Archivoption -a. Die weiteren Optionen kümmern sich um erweiterte Attribute (-X), spezielle Attribute (ACLs: -A), Hardlinks (-H) und Sparse-Dateien (-S). Außerdem kopiert der Befehl nicht über Partitionsgrenzen hinweg (-x).

$ rsync -aXAHSx Quelle  Ziel
$ rsync -aXAHSx Quelle/ Ziel

Rsync erstellt das Zielverzeichnis, falls es noch nicht existiert. Ein Schrägstrich hinter dem Namen des Quellverzeichnisses sorgt dafür, das Rsync nicht das Verzeichnis selbst kopiert (erste Zeile), sondern nur dessen Inhalt mitsamt Unterverzeichnissen (zweite Zeile).

Führen Sie den Befehl mehrmals aus, dann kopiert Rsync nur noch geänderte Dateien. Außerdem überprüft es, ob die Kopie tatsächlich erfolgreich war. Fügen Sie noch die Option --delete hinzu, dann löscht der Befehl auf dem Ziel sogar Dateien, die in der Quelle nicht mehr existieren – Sie erhalten also eine perfekte Kopie.

Kopien genügen nicht

Das Problem der beschriebenen Backup-Methode liegt darin, dass eine einfache Replizierung der Daten auch defekte oder von Trojanern verschlüsselte Dateien übernimmt. Dabei geht die Gefahr speziell bei Linux weniger von Viren und Trojanern aus: Die größte Gefahr für die Daten sitzt oft vor dem PC. Schnell hat man eine Datei irrtümlicherweise gelöscht oder geändert. Fällt das erst nach der Sicherungskopie auf, ist die alte Version bereits überschrieben.

Zu einem ordentlichen Backup gehört deshalb auch das Archivieren alter Versionen. An dieser Stelle wird es meist kompliziert, und viele Anwender steigen aus. Aber zum Glück gibt es eine Vielzahl von Projekten, die sich dieser Aufgabe widmen. Meist machen die entsprechenden Lösungen zwar bei der Ersteinrichtung etwas Arbeit, die tägliche Sicherung fällt dann aber umso leichter.

Das gilt auch für das im Folgenden vorgestellte Verfahren. Es beruht letztlich auf Rsnapshot, das wir schon früher in einem ausführlichen Artikel vorgestellt haben [1]. Das dort beschriebene Server-Szenario passt aber nicht auf die Desktop- und Laptop-Welt, weshalb wir es hier in einer abgewandelten Form anwenden.

Bei der Ersteinrichtung müssen Sie zwei Hürden nehmen: das Erstellen eines geeigneten Backup-Mediums sowie die Software-Installation samt Konfiguration. Alles in allem müssen Sie aber trotzdem nicht mehr als eine Viertelstunde Vorarbeit investieren.

Das Backup-Medium

Für das Backup-Medium verwenden Sie entweder einen ausreichend dimensionierten USB-Stick oder eine externe USB-Festplatte. Beim Autor kommt mobil ein 8 GByte großer USB-Stick zum Einsatz. Die Kapazität genügt für das Home-Verzeichnis mit den selbst geschriebenen Programmen und Artikeln. Zu Hause für die große Mediensammlung braucht es hingegen eine 4-TByte-Platte. Stellen Sie sicher, dass das Backup-Medium keine wichtigen Daten enthält. Wenn wir im Folgenden von einem Backup-Stick reden, ist damit auch immer alternativ eine Festplatte gemeint.

USB-Sticks und Festplatten kommen ab Werk üblicherweise vorformatiert mit dem in der Windows-Welt vorherrschendem FAT32- oder NTFS-Dateisystem. Keines der beiden eignet sich für das Backup von Linux-Systemen. Bei Sticks kommt noch hinzu, dass je nach Kapazität eventuell eine Partitionierung fehlt. Im Zweifelsfall partitionieren Sie den Stick so um, dass er genau eine Partition enthält. In der Regel bringt die Desktop-Umgebung dazu ein Werkzeug mit, alternativ finden Sie eine Anwendung wie Gparted [2] in den Paketquellen.

Nach dem Anschließen des Sticks überprüfen Sie zuerst im Dateimanager, ob das Linux-System per Automounter die Partition des Mediums selbstständig eingehängt hat. Das muss nach einer Neupartitionierung eigentlich nicht sein, kann aber vorkommen. In diesem Fall hängen Sie die Partition wieder aus und formatieren sie anschließend mit Ext4.

Das geht grafisch sehr bequem mit Gparted (Abbildung 1) oder auf der Kommandozeile mit dem Befehl aus der zweiten Zeile von Listing 2. Dort ersetzen Sie /dev/sdXY durch den Gerätenamen des Mediums, etwa /dev/sdb1. Im Zweifelsfall kontrollieren Sie den Device-Namen am besten vor der Formatierung via Lsblk (Zeile 1). Der Befehl gibt die Partitionen, die Größen und gegebenenfalls die entsprechenden Mountpunkte aus. Ein Beispiel dafür zeigt Abbildung 2: Dort lässt sich der Stick anhand der Größe von knapp 8 GByte gut ausmachen.

$ lsblk /dev/sd?
$ sudo mkfs.ext4 -L "BACKUP" /dev/sdXY

Abbildung 1: Mit Gparted lassen sich Datenträger schnell partitionieren und formatieren. Hier erhält die neue Partition ein Label.

Abbildung 2: Die Ausgabe von Lsblk. Anhand der Partitionsgrößen lässt sich der für das Backup gedachte USB-Stick schnell identifizieren.

Der Formatierungsbefehl vergibt auch gleich noch ein Label für die Partition. Statt BACKUP dürfen Sie hier auch etwas anderes angeben. Sie benötigen den Bezeichner später wieder, denn das Backup soll nur dann starten, wenn Sie das richtige Medium an das System anhängen. Bei Gparted finden Sie die Funktion im Menü Partition | Dateisystem bezeichnen.

Systemanpassungen

Nach dem Einrichten des Backup-Mediums steht die Installation und Konfiguration einiger Pakete an. Zunächst spielen Sie über die Paketverwaltung die Pakete rsync, git sowie rsnapshot ein. Die erste Zeile von Listing 3 zeigt den entsprechenden Befehl für Debian, Ubuntu und deren Derivate. Falls Rsnapshot in den Repositories der von Ihnen genutzten Distribution fehlt, laden Sie das Skript von der Projektseite herunter [3].

$ sudo apt install rsync git rsnapshot
$ git clone https://github.com/bablokb/autobackup-service.git
$ cd autobackup-service
$ sudo tools/install
$ sudo cp /etc/rsnapshot.conf.autobackup-service /etc/rsnapshot.conf

Außerdem benötigen Sie noch das Autobackup-Skript samt Konfigurationsdateien des Autors [4], das Sie mit den Befehlen aus den Zeilen 2 bis 4 von Listing 4 herunterladen und installieren. Verwenden Sie ein auf Debian basierendes System wie etwa Ubuntu oder Linux Mint, dann erledigt das Kommando aus Zeile 4 auch die Installation der Pakete Rsync und Rsnapshot gleich mit. Möchten Sie das nicht, dann kommentieren Sie in der Datei tools/install vorab den Befehl install_packages am Ende aus.

Wenn Sie später den Backup-Stick einstecken, registriert der Kernel das und erzeugt ein sogenanntes Udev-Ereignis (Abbildung 3). Der ständig laufende Udev-Daemon startet daraufhin das Skript /usr/local/sbin/autobackup. Es überprüft, ob tatsächlich der Backup-Stick angeschlossen wurde und ob es am aktuellen Datum, in der laufenden Woche beziehungsweise im aktuellen Monat schon eine entsprechende Sicherung gab. Ist das nicht der Fall, dann startet das Skript das Rsnapshot-Skript mit den richtigen Parametern.

Abbildung 3: Mit dem Kommando udevadm monitor --property beobachten Sie das Geschehen unter der Haube von Udev in Echtzeit.

Damit das alles klappt, konfigurieren Sie das Autobackup-Skript wie in Listing 4 gezeigt. Die Konfigurationsdatei finden Sie in /etc/autobackup.conf. Hier müssen Sie normalerweise nur das Label eintragen, das in unserem Beispiel BACKUP lautet. Den Wert von SYSLOG können Sie auf 1 setzen: Dann schreibt das Skript ausführliche Meldungen ins Systemlog, sodass Sie bei Problemen mehr Informationen erhalten. Normalerweise nimmt das Skript nur ein Backup pro Tag vor; mit force_daily=1 ändern Sie das. Achten Sie bei allen Änderungen darauf, die Syntax der Shell nicht zu verletzen, also insbesondere keine Leerzeichen vor oder nach den Gleichheitszeichen zu setzen.

# /etc/autobackup.conf
LABEL=BACKUP
SYSLOG=0
# x Sekunde(n) auf Device warten
WAIT_FOR_DEVICE=2
# Wenn 1: Tagesbackup bei jedem Einstecken
force_daily=0
# Backup-Namen (laut /etc/rsnapshot.conf)
daily="Tag"
weekly="Woche"
monthly="Monat"
yearly=""

Als Zweites müssen Sie noch die Datei /etc/rsnapshot.conf erstellen. Die Installation von Rsnapshot bringt üblicherweise ein Beispiel mit, ebenso die Installation des Autobackup-Skripts. Kopieren Sie hierfür die Datei /etc/rsnapshot.conf.autobackup-service nach /etc/rsnapshot.conf (Listing 3, Zeile 5). Anpassungen müssen Sie nur in der Mitte sowie ganz am Ende der Datei vornehmen (Listing 5). In der Mitte definieren Sie, wie viele Generationen Sie für jedes Intervall aufbewahren wollen. Die Bezeichner (hier Tag, Woche, Monat und Jahr, Letzteres auskommentiert), müssen mit den Werten in den letzten vier Zeilen von Listing 4 übereinstimmen.

# /etc/rsnapshot.conf
[...]
#########################################
#     BACKUP LEVELS / INTERVALS
# Must be unique and in ascending order
# e.g. alpha, beta, gamma, etc.
#########################################
retain   Tag   7
retain   Woche 4
retain   Monat 3
#retain  Jahr  3
############################
# BACKUP POINTS / SCRIPTS
############################
# LOCALHOST
backup   /etc/    ./
backup   /home    ./

Am Ende der Datei legen Sie fest, welche Verzeichnisse das Skript sichern soll. Rsnapshot bietet hier diverse Möglichkeiten, um gezielt auch Dateien auszuschließen – aber das ist selten die Mühe wert.

Einen Fallstrick gibt es in der /etc/rsnapshot.conf allerdings: Die einzelnen Worte müssen Sie zwingend mit Tabulatoren und nicht mit Leerzeichen voneinander trennen. Deshalb sollten Sie nach dem Editieren den Befehl sudo rsnapshot check aufrufen. Das Kommando überprüft die Syntax und stellt so fest, ob ein Editor stillschweigend Tabs durch Leerzeichen ersetzt hat.

Und los

Nach diesen Vorarbeiten starten Sie das System neu. Die Installation hat eine neue Regel für den Udev-Daemon installiert; der Neustart sorgt dafür, dass diese auch automatisch greift. Stecken Sie nun den Backup-Stick an einen freien USB-Port, sollte das Backup selbstständig anlaufen. Sobald die LED des Sticks nicht mehr blinkt, ist das Backup beendet und der Stick ausgehängt. Lassen Sie ihn angesteckt und hängen ihn manuell wieder ein, sehen Sie im Dateimanager die erste Sicherung im Verzeichnis Tag.0 (Abbildung 4).

Abbildung 4: Pro Sicherung erstellt das Autobackup-Skript ein neues Verzeichnis. So haben Sie immer unterschiedliche Versionen Ihrer Daten zur Hand.

An jedem Folgetag erstellt das Skript weitere Backups. Dabei wandert am zweiten Tag der Inhalt von Tag.0 nach Tag.1 und Tag.0 enthält die aktuellste Sicherung. Das geht so weiter, bis sieben Tage voll sind – auch wenn Sie einzelne Tage auslassen. Danach legt das Skript eine Wochensicherung an: Tag.6 wird zu Woche.0. Das erfolgt nur einmal pro Kalenderwoche; nach vier Wochen setzt sich das Schema analog mit Monatssicherungen fort.

Bei einem Einsatz von Rsnapshot für einen Server, der jeden Tag läuft, sorgen Einträge in der Crontab für den geordneten Ablauf – etwa eine Wochensicherung jeden Sonntagabend, eine Monatssicherung am Ersten eines jeden Monats. Bei Desktops und Laptops, die nicht zwangsläufig jeden Tag laufen, klappt das nicht. Aus eben diesem Grund empfiehlt es sich, das Backup genau dann zu starten, wenn das Backup-Medium am Rechner hängt.

Falls Sie sich jetzt wundern, warum die Backups ab dem zweiten Tag so schnell laufen und auch der belegte Plattenplatz nur sehr langsam wächst, obwohl die Dateien in so vielen Tages- und Wochen-Verzeichnissen liegen: Das liegt an der “Magie” hinter Rsync. Das Tool kopiert nur die geänderten Dateien. Für Dateien, die sich nicht ändern, legt Rsync nur einen Verweis an, konkret einen sogenannten Hardlink. Dann handelt es sich bei der vermeintlichen Datei Tag.1/home/bablokb/Alter-Text.odt in Wirklichkeit nur um einen Verweis auf den Speicherort der Datei Tag.0/home/bablokb/Alter-Text.odt und Tag.1/home/bablokb/Alter-Text.odt auf dem Stick.

Das Verfahren bietet eine ganze Reihe von Vorteilen. Statt große Dateien über USB zu kopieren, legt Rsync nur den Eintrag an – das geht sehr schnell und spart viel Platz. Trotzdem zeigt jede Tagessicherung genau den Zustand der Verzeichnisse am Sicherungsdatum. Wenn Sie sehen wollen, was sich für eine Datei zwischen Heute und Vorgestern geändert hat, dann vergleichen Sie einfach Tag.0/[...]/Datei.txt mit Tag.2/[...]/Datei.txt.

Fazit

Nach ein wenig Vorarbeit läuft das regelmäßige Backup vollautomatisch ab. Das Verfahren empfiehlt sich insbesondere für diejenigen, die sowieso schon zumindest hin und wieder ihre Daten auf ein externes Medium kopiert haben. Wie immer in der Open-Source-Welt gilt: Passen Sie das Verfahren bei Bedarf ruhig an Ihre konkreten Bedürfnisse an.

So könnten Sie zum Beispiel den Auslöser des Backups (Einstecken des Sticks) durch etwas anderes ersetzen – bei einem Laptop etwa durch das Einbuchen ins heimische WLAN. Das Backup sollte dann auch folgerichtig auf ein Netzwerklaufwerk erfolgen. Betreiben Sie ein stationäres Gerät und wollen den Zeitpunkt des Backups nicht kontrollieren, sollten Sie den eingangs erwähnten Artikel durchlesen [1], den Sie auch auf der Heft-DVD dieser Ausgabe finden. Mit etwas Zusatzarbeit – etwa, indem Sie Cron durch Anacron ersetzen – funktioniert das dort beschriebene Verfahren auch einigermaßen für Desktop-Geräte, die nicht immer angeschaltet laufen.

Egal, welches Verfahren Sie nutzen: Entscheidend ist, dass Sie regelmäßig Backups anfertigen. Dabei sollten Sie nicht vergessen, von Zeit zu Zeit zu prüfen, ob die Backups auch das halten, was sie versprechen. Aus seiner beruflichen Vergangenheit weiß der Autor von einem Fall, bei dem jahrelang die Daten tagtäglich auf dieselben Magnetbänder gesichert wurden. Dummerweise waren diese aber nur auf eine kleine dreistellige Zahl von Schreibzyklen ausgelegt, was im Ernstfall eine erfolgreiche Datenwiederherstellung unmöglich gemacht hätte. Bei modernen Flash-Medien droht dieses Szenario zwar nicht – aber, wie es so schön heißt: Vorsicht ist die Mutter der Porzellankiste.