Mit Time Machine hat Apple etwas Kurioses bewerkstelligt: Da gab es plötzlich ein System, das vielen tausenden von Anwendern nicht nur die Möglichkeit gab, Backups zu machen, sondern sie sogar dazu brachte, das auch zu tun. Leider hat es zwei große Schwachstellen: Erstens existiert es nur für Mac OS X, und zweitens ist es nicht in der Lage, Backups über ein Rechnernetz auf einen Server zu legen (außer freilich dieser Server ist eine von Apple verkaufte Time Capsule oder ein Macintosh).

Wenn man im Haushalt mehrere Computer am Laufen hat, ist der Gedanke naheliegend, einen zentralen Server für alle Backups einzurichten. Auch ist es leichter, auf einen Server zu backuppen, wenn man zwischen verschiedenen Wohnorten hin- und herwechselt (wie viele Studenten das regelmäßig zum Beginn und zum Ende der Vorlesungszeit tun) oder häufig unterwegs ist, da es bei entsprechender Konfiguration (z.B. über ein VPN) möglich ist, Backups auch über das Internet durchzuführen.

Wenn Time Machine nun für diesen Zweck also nicht zu gebrauchen ist, was sind dann gute Alternativen?

rsync

Da wäre erst einmal das gute, alte rsync. Eine eher unbekannte Funktion dieses mächtigen Programms besteht darin, beim Synchronisieren ein bestehendes Verzeichnis (ein früheres Backup) als Ausgangspunkt zu nehmen und ein neues Verzeichnis mit dem neuen Inhalt anzulegen, wobei unveränderte Dateien mithilfe von Hardlinks nur ein Mal auf der Platte abgelegt werden. Das Resultat ist, daß man mehrere vollständige Backups vorhalten kann, die aber vom Platzverbrauch her inkrementellen Backups entsprechen.

rsync allein macht freilich noch kein automatisches Backupsystem. Mit ein wenig Skripterei sollte es jedoch machbar sein, sich ein vollständiges Backupsystem damit zu bauen, das sich im Großen und Ganzen genau so verhält wie Apples Time Machine.

Ein Nachteil von rsync ist, daß erweiterte Metadaten zu Dateien, wie sie zum Beispiel wichtigerweise auf Macs in Form von Resource Forks vorkommen, nur dann gespeichert werden können, wenn das Zieldateisystem sie auch unterstützt. Speziell für die Sicherung von Mac-Metadaten auf ein inkompatibles Dateisystem gibt es jedoch einen Patch namens rsync+hfsmode.

rsnapshot

Einen Schritt weiter geht rsnapshot. Es ist bereits als Time-Machine-ähnliches Backupsystem konzipiert und nimmt dem Anwender daher weit mehr ab als rsync allein. Die Einrichtung von rsnapshot ist sehr einfach und schnell erledigt. Leider hakt es an einer Kleinigkeit: Übers Netzwerk kann man zwar Backups anfertigen, aber leider nur vom Server aus. Dieser muß sich dazu durch paßwortlosen Login an dem Rechner anmelden, für den ein Backup gemacht werden soll — und die entsprechenden Zugriffsrechte haben, um auf alles zuzugreifen, was in das Backup hineingehört. Eine solche Konfiguration kann ein nicht zu verachtendes Sicherheitsrisiko darstellen. Schließlich könnte so jemand, der den Backupserver knackt, jeden Rechner infiltrieren, der für Backups vorbereitet ist. Viele weitere Backupsysteme, die sich am Prinzip des inkrementellen Backups durch Hardlinks orientieren, weisen dieselbe Schwäche auf.

rdiff-backup

Einen etwas anderen Ansatz verfolgt rdiff-backup. Im Gegensatz zu den hardlinkbasierten Systemen behält es nur das jüngste Backup als vollständigen Verzeichnisbaum, während zu älteren Datenbeständen die Unterschiede zum jeweils nächsten Backup gespeichert werden. Diese Vorgehensweise ermöglicht einfachen Zugriff auf das neueste Backup und eine platzsparende Sicherung älterer Daten. Es ist allerdings nicht so einfach möglich wie in den hardlinkbasierten Systemen, ältere Datenbestände zu löschen, ohne auch alle früheren unbrauchbar zu machen.

Um mit rdiff-backup Backups über ein Rechnernetz erstellen zu können, muß auf dem Server die passende Version von rdiff-backup installiert sein. Da es sich dabei um ein Python-Programm mit zusätzlichen Abhängigkeiten handelt, das nicht sehr weit verbreitet ist, kann das unter Umständen zu Problemen führen.

gibak

Übers Netzwerk ist es manchmal schwierig, sich das verwendete Dateisystem auszusuchen. Je nach Situation kann es sein, daß man mit Zugriffsmethoden wie sshfs, FTP, WebDAV oder CIFS auskommen muß, die unter anderem keine Hardlinks unterstützen. Ein System, das über das Dateisystem eine Ebene legt, die konzeptionell auf Hardlinks basiert, diese aber in den unteren Ebenen nicht voraussetzt, ist git.

git ist am besten als Versionsverwaltungssystem für Programmcode bekannt, eigentlich aber ist es im Kern nicht mehr und nicht weniger als ein Verwaltungssystem für Datenpakete (lies: Dateien), die in Bäumen (lies: Verzeichnissen) organisiert sind. Ein offensichtlicher Kandidat für ein Backupsystem also, besonders in Verbindung mit den Möglichkeiten der Versionsverwaltung, die git mitbringt.

gibak macht aus git ein solches Backupsystem. Man kann Backups lokal anfertigen und sie dann mit dem in git eingebauten push-Befehl auf beliebig viele Server verteilen. Alternativ dazu kann man die git-Datenbank auch gleich in ein Verzeichnis auf einem Server legen. Das Schöne an dem System ist, daß es einerseits transparent und leicht zu durchschauen ist, andererseits Daten aber sehr wirkungsvoll komprimiert werden, um Platz zu sparen und das Netz zu schonen. Außerdem ist es bei von git verwalteten Datensätzen stets möglich, die Geschichte umzuschreiben, und zwar insbesondere auch, einzelne Versionen aus der Versionsgeschichte zu entfernen, ohne Gefahr zu laufen, andere Versionen destruktiv zu beeinflussen.

Der Nachteil von gibak gegenüber Time-Machine-ähnlichen Systemen ist natürlich, daß Letztere Backups erzeugen, die man ohne jegliche Hilfsmittel in vollem Umfang lesen kann (soweit man in der Lage ist, das Dateisystem zu verstehen). Möchte man von einem Backup vielleicht in 10 Jahren noch etwas haben, ist das ein wichtiger Punkt, den man bei der Wahl eines Backupsystems auf jeden Fall berücksichtigen sollte.