Mit Rsnapshot legen Sie auf einfache Art sowohl lokale Backups als auch Sicherungen auf entfernten Maschinen an. Das Rotationsprinzip des Tools gibt Ihnen dabei schnellen Zugriff auf ältere Dateiversionen.

Das “R” in Rsnapshot [1] lässt dessen Herkunft bereits erahnen – die Backup-Software baut auf Rsync auf, also auf ein bewährtes Werkzeug zur Datensynchronisation. Statt blind sämtliche Verzeichnisse zu archivieren, beherrscht Rsync verschiedene Mechanismen, anhand derer es neue oder geänderte Dateien erkennt und dann platzsparend nur die Änderungen überträgt. Viele Administratoren binden nicht zuletzt deswegen schon lange Rsync in die eigene Backupstrategie ein. Doch die Vielzahl der Rsync-Optionen überfordert gerade Einsteiger schnell. Wohl aus diesem Grund spendierten die Entwickler von Rsnapshot der kryptischen Rsync-Kommandozeile eine einfache Konfigurationsmöglichkeit.

Rsnapshot sichert sowohl lokale als auch entfernte Dateien und beherrscht zudem das Einbinden externer Tools, beispielsweise für MySQL-Dumps. Es kennt verschiedene Intervalle und legt die Sicherungen gruppiert und nach Alter sortiert ab. Durch dieses Rotationsprinzip haben Sie stets Zugriff auf mehrere vergangene Dateiversionen, wobei Sie die Anzahl der vorgehaltenen Intervalle frei wählen können – beispielsweise drei stündliche, sieben tägliche, vier wöchentliche, und zwei monatliche Backups. Der eigentliche Clou: Rsnapshot überträgt nur die seit dem letzten Durchlauf geänderten Dateien. Das schont nicht nur Plattenplatz, sondern auch die Netzwerkbandbreite.

Installation und Konfiguration

Auf unserem Testsystem, einem Server unter Ubuntu 10.04 LTS, ging die Installation dank fertiger Pakete schnell von der Hand. Ein simples apt-get install rsnapshot befördert das Programm auf das System. Anschließend legen Sie mittels touch /etc/rsnapshot.exclude eine leere Exclude-Datei an (dazu später mehr) und sperren sie mittels chmod 711 /etc/rsnapshot.exclude vor allzu neugierigen Blicken. Damit ist die Installation bereits abgeschlossen.

Die Konfiguration selbst nehmen Sie in /etc/rsnapshot.conf vor. Beim Bearbeiten im Editor Ihrer Wahl gilt es unbedingt zu beachten, dass Rsnapshot als Trennzeichen zwischen den einzelnen Optionen zwingend einen Tabulator erwartet – greifen Sie indes aus Gewohnheit auf das Leerzeichen zurück, verweigert das Backupwerkzeug seinen Dienst. Wichtig ist auch, dass Sie Verzeichnisnamen entgegen der üblichen Konvention stets mit einem Slash abschließen. Die einzelnen Optionen sind gut dokumentiert.

Zunächst wählen Sie ein Backup-Wurzelverzeichnis (snapshot_root) – auf unserem Testsystem liegt es auf einem RAID-System, wir benutzen dazu das Verzeichnis /backup/snapshots/ (beachten Sie den abschließenden Slash). Für externe Geräte wie USB-Festplatten ist zusätzlich die Option no_create_root von Interesse. Rsnapshot greift bei Bedarf auch auf eine ganze Reihe von externen Hilfsmitteln zurück, die Sie in der Konfiguration zusätzlich aktivieren. Auf unserem Testsystem betraf das die Optionen cmd_cp und cmd_du (die Pfade zu den Tools cp und du) mit den entsprechenden Vorgabewerten sowie cmd_ssh mit /usr/bin/ssh und cmd_rsnapshot_diff mit /usr/bin/rsnapshot-diff.

Der Übersichtlichkeit halber aktivieren Sie auch rsync_short_args, rsync_long_args und du_args. Die Option exclude_file sollte auf das vorab angelegte Excludes-File in /etc/rsnapshot.exclude zeigen, und zum Schluss setzen Sie link_dest[Tab]1.

Am Rotieren

Nach Abschluss der Grundkonfiguration ist es an der Zeit, zunächst die einzelnen Rotationszyklen mittels interval zu konfigurieren. Für den privaten Einsatz hat es sich bewährt, Backups in stündlichen und täglichen Zyklen anzulegen, was Sie mit der folgenden Konfiguration bewerkstelligen:

interval        hourly  2
interval        daily   7

Damit hält Rsnapshot jeweils zwei Revisionen des stündlichen Backups vor sowie sieben Ausgaben der Tagessicherung, also eine volle Woche. Analog konfigurieren Sie bei Bedarf auch die anderen Intervalle.

Nun teilen Sie Rsnapshot noch mit, was es eigentlich sichern soll – der dazugehörige Parameter heißt naheliegenderweise backup. Falls bloßes Kopieren nicht reicht, binden Sie Skripts mittels backup_script ein. Auch hier müssen Sie alle Parameter per Tabulator trennen und alle Pfadnamen mit einem Slash abschließen. Ein Beispiel zeigt Listing 1. Dessen Zeilen weisen Rsnapshot an, die wichtigsten System- und Datenverzeichnisse der lokalen Ubuntu-Installation zu sichern. Der erste Parameter gibt dabei das zu sichernde Verzeichnis an, der zweite Parameter das Unterverzeichnis innerhalb des Backupverzeichnisses (snapshot_root).

backup  /opt/   webserver.local/
backup  /root/  webserver.local/
backup  /srv/   webserver.local/
backup  /var/   webserver.local/
backup  /home/  webserver.local/
backup  /etc/   webserver.local/
backup  /usr/local/     webserver.local/
backup  /lib/ufw/       webserver.local/

Ähnlich verhält es sich mit backup_script (Listing 2): Die ersten beiden Zeilen sichern die aktuelle Quota-Tabelle in die Datei webserver.local/dumps/repquota.user bzw. repquota.group, der Befehl in der dritten Zeile tut dies für die Liste der installierten Pakete. Auch Dumps von MySQL- oder PostgreSQL-Datenbanken sind möglich, wie Zeile 4 beweist. Achten Sie aber darauf, gegebenenfalls die Berechtigung der rsnapshot.conf anzupassen und separate Backup-Benutzer für MySQL zu verwenden, damit ein möglicher Angreifer nicht etwa Root-Zugriff auf die Datenbank erhält.

backup_script   /usr/sbin/repquota -avcsu > repquota.user       webserver.local/dumps/repquota.user
backup_script   /usr/sbin/repquota -avcsg > repquota.group      webserver.local/dumps/repquota.group
backup_script   /usr/bin/dpkg --get-selections > packages.lst   webserver.local/dumps/packages.lst
backup_script   /usr/bin/mysqldump --all-databases --complete-insert --user=backup --password=12345 > mysql.dump        webserver.local/dumps/mysql

Haben Sie die Rotationszyklen und die zu sichernden Daten in der rsnapshot.conf konfiguriert, starten Sie einen ersten Testlauf. Führen Sie dazu als Root rsnapshot -v hourly aus. Nach einer Weile meldet Rsnapshot den erfolgreichen Backuplauf.

Ein Blick ins Backup-Wurzelverzeichnis fördert bei Erfolg das Unterverzeichnis hourly.0 zutage. Unterhalb dieses Verzeichnisses legt Rsnapshot die Kopien ab – /lib/ufw beispielsweise in hourly.0/lib/ufw, die Ergebnisse der Backupskripte entsprechend im dumps-Verzeichnis. Die angehängte Null zeigt an, dass es sich dabei um das erste stündliche Backup in der Rotation handelt.

Rufen Sie jetzt rsnapshot -v hourly erneut auf, gesellt sich ein zweites Verzeichnis dazu – Rsnapshot verschiebt das bisherige hourly.0 nach hourly.1 und befüllt das .0-Verzeichnis neu. Dieser Prozess setzt sich solange fort, bis die Maximalzahl an Rotationszyklen erreicht ist. Danach entfernt Rsnapshot beim Durchlauf das jeweils älteste Verzeichnis.

Genauso verhält es sich mit anderen Intervallen, wie etwa den täglichen oder wöchentlichen Backups: Ein Blick in die Verzeichnisse mit .0 öffnet den Zugriff auf die jeweils jüngste Sicherung; je höher die Zahl ausfällt, desto älter ist die Kopie.

Löschen dürfen Sie bestimmte Verzeichnisse indes nicht, denn Rsnapshot verbindet diese mit Hardlinks untereinander. Beim Backup-Lauf sichert Rsnapshot jeweils nur die neuen Dateien, für bereits bestehende verweist es aufs Nachbarverzeichnis. So liegen im Beispiel alle Mails seit dem letzten Durchlauf in hourly.0, ältere Mails sind nur in hourly.1 gespeichert.

/home/mirrorbrain/LOCK-mirrorprobe
.mhonarc.lck
*.vdi
*.cache

Eine Frage des Intervalls

Bislang starten die Backups nur durch manuellen Aufruf auf der Kommandozeile – ruft niemand Rsnapshot auf, kann es auch nichts sichern. Deswegen sollte der manuelle Lauf die Ausnahme bleiben und die Sicherung stattdessen per Cronjob erfolgen. Ubuntu bringt dazu in /etc/cron.d/rsnapshot eine entsprechende Vorlage mit, die Sie nur noch anpassen müssen. Die Namenskonvention “Intervall” ist insofern in der Konfiguration irreführend, da sie keine Aussage darüber macht, ob und in welchen Zeiträumen der Backup-Lauf auch tatsächlich startet – das regelt ausschließlich der Cronjob. Achten Sie immer darauf, dass sich die Cron-Zeiten nicht überlagern, dass also nicht gleichzeitig ein stündliches und ein tägliches Backup laufen würden.

Das Beispiel in Listing 4 verdeutlicht ein mögliches Vorgehen. Damit setzen Sie fest, dass der stündliche Backup-Durchgang nur alle drei Stunden startet (er könnte ja theoretisch auch länger als 60 Minuten benötigen) und das tägliche Backup frühmorgens um fünf Uhr erfolgt. Zusammen mit der Anzahl der konfigurierten Rotationszyklen legen Sie damit gleichzeitig fest, welchen Zeitraum das Backup abdeckt: Das daily-Backup läuft einmal am Tag und wird sieben Mal vorgehalten, ergo lassen sich sieben Tagesstände rekonstruieren. Das hourly-Backup läuft alle drei Stunden und wird im Beispiel zwei Mal vorgehalten, womit sich theoretisch die letzten sechs Stunden wieder herstellen lassen.

0 */3  * * *  root  /usr/bin/rsnapshot hourly
0 5  * * *  root  /usr/bin/rsnapshot daily

Backupserver einrichten

Bis jetzt sichert Rsnapshot nur die lokalen Dateien automatisch. Möchten Sie eine Datensicherung für mehrere Maschinen aufsetzen, könnten Sie theoretisch pro Gerät eine eigene Rsnapshot-Instanz installieren. Das macht jedoch großen Aufwand und birgt das Risiko, am Schluss die Daten dezentral zu sichern. Wesentlich sinnvoller ist es, eine einzelne Rsnapshot-Instanz am Server für die Sicherung aller Clients sorgen zu lassen. Rsnapshot in Verbindung mit SSH macht genau das möglich.

Am Client müssen Sie dazu nicht viele Voraussetzungen erfüllen – ein SSH-Zugang per Key sowie ein lokal installiertes Rsync genügen. Rsnapshot startet dann über eine verschlüsselte Verbindung und gleicht die Daten per Netzwerk ab. Den notwendigen Key erstellen Sie – ohne Passwort, denn das können Sie beim automatischen Backup-Lauf ja nicht eingeben – einfach mittels

# ssh-keygen -t rsa -C root@localnet -f /root/.ssh/backup

Dabei entstehen zwei Dateien: Einmal der geheimen Schlüssel selbst (backup), und einmal der sogenannten Public Key mit der Endung .pub. Ersteren kopieren Sie auf den Backup-Server in ein geschütztes Verzeichnis, Letzteren fügen Sie am zu sichernden Client zur Datei .ssh/authorized_keys im Home-Verzeichnis des entsprechenden Benutzers hinzu. Ein solcher Eintrag sieht beispielsweise so aus:

from="backupserver.localnet",command="/usr/local/bin/rsnapshot-ssh" ssh-rsa Key root@localnet

Die Zeile besagt, dass der Host backupserver.localnet sich mit dem entsprechenden Key verbinden, jedoch nur den Befehl /usr/local/bin/rsnapshot-ssh benutzen darf – im Fall einer Kompromittierung des Schlüssels kommt ein Angreifer dann dennoch nicht so leicht aufs System.

Den hier genannten SSH-Wrapper bringt Rsnapshot allerdings nicht selbst mit, eine Grundlage dazu finden Sie aber beispielsweise unter [2]. Für einen ersten Test geht es natürlich auch erst einmal ohne, lassen Sie in dem Fall die command-Anweisung einfach weg. Erweitern Sie den Wrapper um die benötigten Befehle und machen Sie ihn mittels chmod 755 auf ausführbar. Das Listing 5 bietet einen Anhaltspunkt.

#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\(*)
echo "Rejected"
;;
*\{*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
*\<*)
echo "Rejected"
;;
*\`*)
echo "Rejected"
;;
*\|*)
echo "Rejected"
;;
rsync\ --server*)
$SSH_ORIGINAL_COMMAND
;;
mysqldump*)
$SSH_ORIGINAL_COMMAND
;;
su\ -\ postgres\ -c\ pg_dumpall*)
$SSH_ORIGINAL_COMMAND
;;
/usr/sbin/repquota\ -avcsu*)
$SSH_ORIGINAL_COMMAND
;;
/usr/sbin/repquota\ -avcsg*)
$SSH_ORIGINAL_COMMAND
;;
dpkg\ --get-selections*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Rejected"
;;
esac

Vor allen Dingen die Tatsache, dass je nach zu sichernden Daten der Zugriff als Root erfolgen muss, macht diese Sicherheitsmaßnahme. Damit der Root-Zugriff funktioniert, aktivieren Sie zusätzlich noch die SSH-Option PermitRootLogin yes in der Datei /etc/ssh/sshd_config, da die Anmeldung als Superuser sonst fehlschlägt. Erscheint Ihnen ungesichertes Keyfile mit Root-Rechten zu riskant, erstellen Sie stattdessen eine mit Passwort geschützte Schlüsseldatei und greifen auf die Dienste von Keychain [3] zurückgreifen.

Die Konfiguration des Clients ist damit abgeschlossen. Nun gilt es, in der rsnapshot.conf auf dem Server die richtigen Einstellungen vorzunehmen. Die Syntax lautet dabei fast identisch wie bei der lokalen Sicherung, wie das Beispiel in Listing 6 zeigt.

backup_script   /usr/bin/ssh root@mailserver.localnet -i /root/.ssh/backup "mysqldump --all-databases --complete-insert --user=backup --password=12345" > mysql.dump    mailserver.localnet/dumps/mysql
backup  root@mailserver.localnet:/home/ mailserver.localnet/    +ssh_args=-i /root/.ssh/backup

Damit verbindet sich Rsnapshot mit dem Host mailserver.localnet und präsentiert bei der Anmeldung den SSH-Schlüssel in /root/.ssh/backup. Erst führt es einen MySQL-Dump aus, dessen Inhalte übers Netz transportiert werden, und sichert danach das Home-Verzeichnis. Diese Daten liegen dann wie schon beim vorherigen Durchlauf im Backupverzeichnis unterhalb von mailserver.localnet, wobei Rsnapshot sie ebenfalls in Intervalle untergliedert.

Fazit

Rsnapshot vereint die Flexibilität von Rsync mit dem Komfort einer übersichtlichen Konfiguration und nimmt dem Administrator die Bürde, lokale Clients zu sichern. In Verbindung mit dem SSH-Feature eignet es sich hervorragend als zentrale Sicherungsinstanz im Netzwerk. Sinnvoll ist dabei übrigens, auf eine zentrale Benutzerverwaltung zu setzen, um die Dateiberechtigungen serverweit konstant abzubilden.