zurück zum Artikel

Hinter Schloss und Siegel

Christiane Rütten

Daten auf FTP-Servern bedürfen eines besonderen Schutzes, wenn unklar ist, wer darauf zugreifen kann. Der Einsatz von duplicity mit dem c't-Skript ftplicity sorgt für komfortable, verschlüsselte und signierte FTP-Backups.

Wer seine Daten auf einem unbekannten FTP-Server sichert, muss sie verschlüsseln und signieren, um sie zuverlässig vor neugierigen Blicken und Manipulationen zu schützen. Dafür ist duplicity das richtige Werkzeug, und das c't-Skript ftplicity [1] macht die Arbeit damit zu einem Kinderspiel.

Die meisten Provider stellen Mietern eines Root-Servers einen Zugang zu einem FTP-Server für Backups zur Verfügung. Dort ist in der Regel Platz für den gesamten Inhalt der Festplatte. Doch das bereitgestellte FTP-Archiv ist nicht unbedingt vertrauenswürdig: Es ist unklar, wer darauf Zugriff hat, was dort mit den gespeicherten Daten geschieht und ob der Server wirklich sicher vor unbefugtem Zugriff ist. Außerdem sind die Daten während der FTP-Übertragung zum Backup-Archiv unter Umständen neugierigen Blicken ausgesetzt.

Das in der Skriptingsprache Python entwickelte Backup-Werkzeug duplicity hilft dem Linux-Admin aus der Klemme: Es erstellt mit GPG verschlüsselte und signierte, komprimierte, inkrementelle Backups. Inkrementell bedeutet, dass nach einem Vollbackup immer nur geänderte Dateien gesichert werden. Das spart Speicherplatz und Übertragungsvolumen und erlaubt den Rückgriff auf ältere Datei-Versionen. Durch den Einsatz von GPG lassen sich die Backup-Daten guten Gewissens auch über ungesicherte Netzwerkverbindungen zu einem nicht vertrauenswürdigen Server übertragen, weil sie vor neugierigen Blicken und Manipulationen geschützt sind.

duplicity ist in Version 0.4.1 bereits Teil von Debian, Ubuntu (im Universe-Repository) und Fedora Core (in der Sektion "Extras"). Suse-Nutzer müssen noch Hand anlegen: Die aktuelle Version 0.4.2 steht auf der Homepage [1 [2]] als tar-Archiv (und Source-RPM für Fedora) zum Download bereit. Nach dem Entpacken des tar-Archivs erledigt ein

python setup.py install

im Quellverzeichnis alle notwendigen Schritte für die Installation. Voraussetzung dafür sind installierte Development-Pakete der verwendeten Python-Version und von librsync.

Backup-Kette

Duplicity speichert verschlüsselte, inkrementelle Backups in
kleinen Häppchen auf einem FTP-Server.

Ein Vollbackup besteht aus GPG-verschlüsselten tar-Archiven in etwa 5 MByte großen Häppchen ("Volumes"), so genannten Difftars (duplicity-full.*.difftar.gpg). Zusätzlich speichert duplicity ein raffiniertes System von Prüfsummen über Teile der gesicherten Dateien (ein "Sigtar") sowie ein Inhaltsverzeichnis ("Manifest"), alles ebenfalls verschlüsselt.

Übertragunsvolumen

Durch den rsync-Algorithmus verursacht ein typisches
inkrementelles Backup eines Servers mit 5 GByte nur wenige Megabyte
Übertragungsvolumen.

Um ein inkrementelles Backup anzulegen, holt sich duplicity vom FTP-Server zunächst die Sigtars des letzten Vollbackups sowie aller folgenden inkrementellen Backups. Anhand der darin gespeicherten Prüfsummen stellt es fest, welche Dateien sich geändert haben, und nicht nur das: Der rsync-Algorithmus, der auch beim gleichnamingen Synchronisationstool zum Einsatz kommt, erkennt sogar, was sich an einer Datei geändert hat und speichert nur die Differenz [2 [3]]. Das funktioniert so ähnlich wie ein diff bei Textdateien und hilft, die Datenmenge möglichst klein zu halten. Das inkrementelle Backup wandert dann – gegebenenfalls häppchenweise – in Dateien namens "duplicity-inc*", zusammen mit zugehörigem Sigtar und Manifest. Nach und nach entstehen so auf dem FTP-Server Backup- und Signaturketten aus Vollbackups mit anschließenden Inkrementen.

Beim Restaurieren von einzelnen Dateien macht sich die Volume-Aufteilung bezahlt. duplicity muss lediglich die Volumes aus dem FTP-Archiv zurückbeordern, die zur Rekonstruktion einer Datei nötig sind. Welche das sind, erkennt es an den Manifesten. Aus der letzten Vollversion und den Differenzen baut der rsync-Algorithmus den gewünschten Stand der Datei zusammen. Dafür benötigt duplicity im temporären Verzeichnis Platz für die gesamte Datei. Deshalb muss dort zur Wiederherstellung eines Backups genug Platz für die größte Datei im Backup sein.

Die Kommandozeilen-Arbeit mit duplicity, das eine umfangreiche englischsprachige Manpage mitbringt, ist recht mühsam: Man muss mit jedem Aufruf Umgebungsvariablen übergeben und teils längliche und immer gleiche Optionen eintippen. Unser Wrapper-Skript ftplicity [4] reduziert die stets wiederkehrende Tipparbeit auf ein Minimum. Der Grundgedanke von ftplicity ist, dass man alle Backup- und Restore-Vorgänge in derselben Arbeitsumgebung durchführt: Zugangsdaten zum FTP-Server, GPG-Schlüssel, Passwörter sowie Angaben zum Basisverzeichnis und zu den vom Backup ausgenommenen Dateien und Verzeichnissen ändern sich in der Regel nicht mehr.

Ein vollständiges Server-Backup erfordert Root-Rechte, weshalb im Folgenden davon ausgegangen wird, dass Sie als Root arbeiten. Das Skript können Sie ruhigen Gewissens beispielsweise unter /usr/local/bin ablegen und für alle Nutzer les- und ausführbar machen. Alle vertraulichen Daten wie GPG-Passwort und FTP-Zugangsdaten landen im Konfigurationsverzeichnis .ftplicity im Home-Verzeichnis des ausführenden Nutzers. Zur Sicherheit führt ftplicity bei jedem Aufruf ein

chmod -R go-rwx ~/.ftplicity

aus, um es vor unbefugtem Zugriff zu schützen. ftplicity legt dort beim ersten Aufruf eine Beispielkonfiguration in der Datei conf an.

Für ein Server-Backup sollten Sie sich zunächst als Root mit gpg --gen-key einen GPG-Schlüssel erzeugen, der ausschließlich für das Backup verwendet wird. Seine achtstellige Key-ID sowie das verwendete Passwort sind in die Variablen GPG_KEY und GPG_PW in der config-Datei einzutragen.

Die Variable QUELLE enthält das Basisverzeichnis für das Backup. Die Voreinstellung "/" ist für Root-Server geeignet, die sich nach einem Plattencrash mit möglichst wenig Aufwand in den vorherigen Zustand versetzen lassen sollen. Für ZIEL und ZIEL_PW tragen Sie die Zugangsdaten für Ihren FTP-Backup-Server ein, die Sie von Ihrem Provider erfahren. Es ist sinnvoll, auf dem FTP-Server ein eigenes Unterverzeichnis für Backups anzulegen, um leichter mit unterschiedlichen Versionen der Backups hantieren zu können.

Abschließend ist im Konfigurationsverzeichnis noch die Datei exclude zu erstellen. Sie enthält eine Liste von Verzeichnissen und Dateien – je ein Name pro Zeile – die vom Backup ausgenommen bleiben. Beim Backup des gesamten Dateisystems dürfen /dev, /proc und /sys nicht mitgesichert werden, da es beim Auslesen mancher Spezialdateien zu schwerwiegenden Problemen kommt. Ebenfalls sinnvoll ist der Ausschluss der Verzeichnisse /tmp, /var/tmp und /var/run. Beim Auslesen von Socket- oder Pipe-Dateien kann es zu Fehlermeldungen kommen. Diese sind nicht kritisch, lassen sich aber durch entsprechende Einträge in exclude abstellen.

Das Joker-Zeichen "*" hat dieselbe Bedeutung wie in der Shell: Es passt auf jeden Datei- und Verzeichnisnamen mit dem passenden Muster innerhalb des angegebenen Verzeichnisses. Der spezielle Joker "**" erfasst Unterverzeichnisse in beliebiger Tiefe. "/home/user/*.mp3" nimmt beispielsweise "/home/user/a.mp3" und "/home/user/b.mp3" vom Backup aus, nicht jedoch "/home/user/tmp/x.mp3". "/home/**.mp3" hingegen schließt sämtliche Dateien (und Verzeichnisse) mit der Endung ".mp3" aus, die sich in den Tiefen des /home-Verzeichnisses verstecken.

Beginnt eine Zeile in der exclude-Datei mit einem Pluszeichen gefolgt von einer Leerstelle, wird der nachfolgende Eintrag in das Backup aufgenommen, auch wenn ihn ein weiter hinten in der Liste stehender Eintrag ausschließen würde. Die Reihenfolge innerhalb der exclude-Datei ist also ebenfalls wichtig.

Sehr nützlich sind noch die beiden Dateien pre und post: Diese startet das Skript vor beziehungsweise nach einen Backup, sofern sie vorhanden und ausführbar sind. Dort können Sie zur Vor- und Nachbereitung des Backups notwendige Schritte durchführen lassen wie beispielsweise einen kritischen Dienst vorübergehend anhalten oder einen Dump einer stark frequentierten MySQL-Datenbank erstellen.

Nach erfolgreicher Konfiguration ist es Zeit für ein erstes globales Vollbackup. ftplicity backup ist der passende Befehl dafür. Bei weiteren Durchläufen erstellt duplicity automatisch die kleineren inkrementellen Backups, wenn es im FTP-Archiv bereits einen Backup-Satz vorfindet. ftplicity list zeigt alle Dateien im Backup-Satz an. Mit ftplicity verify ist eine Überprüfung möglich. Der Befehl erzeugt unter anderem eine Liste aller geänderten Dateien, die ein inkrementelles Backup sichern würde.

ftplicity clean zeigt unvollständige Backup-Archive auf dem FTP-Server an. Eine Entfernung mit ftplicity clean --force ist unter Umständen nötig, falls ein Backup-Vorgang unterbrochen wurde und folgende Backups oder ein Verify Fehlermeldungen produzieren.

In der config-Variablen HOECHSTALTER lässt sich angeben, wie weit das inkrementelle Backup in die Vergangenheit zurückreichen soll. Die Voreinstellung beträgt vier Wochen (28D). Veraltete Backup- und Signaturketten können Sie sich mit ftplicity purge anzeigen lassen. Wenn Sie dem Befehl noch ein --force anhängen, fliegen sie aus dem FTP-Archiv heraus. duplicity ist dabei intelligent genug, keine Ketten zu löschen, die für die Wiederherstellung des Standes von vor vier Wochen nötig sind. Das jüngste Voll-Backup muss also stets erhalten bleiben und vertopft unter Umständen das FTP-Verzeichnis, wenn es zu viele alte Dateien enthält, die durch spätere Inkremente abgelöst wurden.

Daher ist es ratsam, von Zeit zu Zeit mit ftplicity full ein weiteres Voll-Backup zu erzwingen und anschließend veraltete Ketten mit ftplicity purge --force zu entfernen. Bei einem täglichen inkrementellen Backup und einem Höchstalter von vier Wochen sollte man bei genügend FTP-Platz etwa alle zwei Wochen ein Voll-Backup nachschieben, mindestens jedoch alle zwei Monate.

Ein automatisches, nächtliches Backup mit monatlichem Vollbackup lässt sich am einfachsten durch den Zeitplandienst cron realisieren. Hängen Sie dazu beispielsweise am Ende der Datei /etc/crontab die beiden folgenden Zeilen an:

00 5 * * * root /usr/local/bin/ftplicity backup
00 6 1 * * root /usr/local/bin/ftplicity full && /usr/local/bin/ftplicity purge --force

Sie sorgen dafür, dass cron täglich um 5:00 Uhr morgens ein inkrementelles Backup durchführt. Am Erstem jedes Monats werden ein Vollbackup nachgelegt und veraltete Ketten gelöscht. Die Ausgabe des Skriptes schickt der Dienst per E-Mail an den Root-Account.

Sie dürfen in keinem Fall vergessen, das fertig konfigurierte .ftplicity-Verzeichnis an einen sicheren, für Fremde unzugänglichen Ort zu kopieren. Denn falls die einzige Schlüsselkopie beispielsweise zusammen mit der Server-Platte "den Bach runter geht", wäre das Backup unwiederbringlich verloren.

duplicity hat bekannte Probleme mit FTP-Servern, die den Fehlercode 550 beim Listing leerer Verzeichnisse liefern. Dies können Sie an der Fehlermeldung

duplicity.backends.BackendException: 550 *: No such file or directory.

beim ersten Backupversuch erkennen. Eine mögliche Lösung ist in diesem Fall, eine beliebige (auch leere) Datei in das Backupverzeichnis auf dem FTP-Server zu legen.

Einzelne Dateien aus dem Backup restauriert man mit ftplicity fetch. Der Befehl benötigt drei Optionen: Datei- beziehungsweise Verzeichnisname, Ziel und Alter:

ftplicity fetch etc/passwd /root/pw 4D

beispielsweise restauriert /etc/passwd im Stand von vor 4 Tagen nach /root/pw, "now" liefert den aktuellen Stand. Details zu dem verwendeten Zeitformat finden sie in der Manpage von duplicity im Abschnitt TIME FORMATS.

Kommt es zur Katastrophe, sollten Sie Ihren Server zunächst mit dem Rettungssystem des Providers booten, das ftplicity-Skript installieren sowie das gesichterte Konfigurationsverzeichnis nach /root/.ftplicity zurückkopieren. Den dort abgelegten GPG-Schlüssel importiert ftplicity automatisch. Sorgen Sie für die gewünschte Partitionierung der Festplatte und hängen Sie unter /mnt zunächst die neue, frisch formatierte Root-Partition ein. Erstellen Sie darin dann alle weiteren Einhängepunkte und mounten Sie dort die vorgesehenen Partitionen. Achten Sie dabei auf die korrekten Zugriffsrechte für das tmp-Verzeichnis (chmod 1777 /mnt/tmp) und die Erstellung der Einhängepunkte für virtuelle Dateisysteme, die vom Backup ausgenommen waren, in der Regel /dev, /proc und /sys. In /mnt/dev müssen sie auch gemäß der Dokumentation Ihrer Distribution die Gerätedateien wiederherstellen, falls das System kein devfs verwendet. ftplicity restore /mnt spielt das Backup dann vollständig im letzten Stand auf die neue Festplatte zurück. Nach der Restaurierung des Bootloaders sollte Ihr Server wieder der Alte sein.

[1] Homepage von Duplicity [5]

[2] Rsync-Homepage mit Dokumentation des Algorithmus [6]

[3] Jürgen Schmidt, Beruhigungsmittel, Backups für kleine Linux-Server, c't 7/06, S. 212 [7] (cr [8])

URL dieses Artikels:
https://www.heise.de/-270834

Links in diesem Artikel:
[1] http://www.heise.de/ct/06/13/links/216.shtml
[2] #uelit-u3
[3] #uelit-u3
[4] http://www.heise.de/ct/06/13/links/216.shtml
[5] http://www.nongnu.org/duplicity/
[6] http://rsync.samba.org/
[7] http://www.heise.de/kiosk/archiv/ct/06/07/212/
[8] mailto:cr@ct.de

Copyright © 2006 Heise Medien