Marco Gabriel

Anforderungen

• Ein Backup sollte in der Regel automatisch laufen und am Ende des Vorgangs idealerweise auch noch jemanden über Erfolg oder Mißerfolg benachrichtigen können.
• Es sollte mehrere Backup-Stände haben verwalten, so dass man auch den Stand von vor einer Woche oder einem Monat wieder herstellen kann.
• Vollsicherungen mit anschließenden inkrementellen Sicherungen verbessern die Speicherausnutzung und sorgen dafür, dass nur geänderte Dateien zusätzlichen Speicherplatz benötigen.
• Backups sollten komprimiert abgelegt werden können, damit der zur Verfügung stehende Speicherplatz möglichst effizient genutzt wird.
• Sicherungen auf unsicherem Speicher müssen verschlüsselt abgelegt werden können. 
• Die Übertragung der Datensicherung muss verschlüsselt geschehen können (oder alternativ die Daten zur Übertragung bereits verschlüsselt sein)

Die Möglichkeiten

Duplicity ist ein Open Source Projekt, welches ein verschlüsseltes Backup auf potentiell unsicherem, öffentlichen Speicher ermöglicht. Duplicity nimmt dabei die zu sichernden Daten, packt diese in Archive und verschlüsselt die Archive mittels GnuPG. Die so entstandenen Archive können von Duplicity auf viele Arten von Onlinespeicher übertragen werden, zum Beispiel auf einen FTP Server oder direkt zu Amazons Simple Storage Service (S3). Die Archive sind dort zwar möglicherweise für andere Personen zugänglich, allerdings braucht uns das nicht zu kümmern, da die Archive ja bereits verschlüsselt wurden.

Auch auf eine direkt angeschlossene Festplatte, auf einen anderen Server mit SFTP oder sogar auf Online-Speicher wie GoogleMail kann Duplicity sichern, da es als Storage Backend sogar IMAP unterstützt. Allerdings würde ich für ein verlässliches Backup auch verlässliche Storage Systeme verwenden. Das schönste Backup nützt einem nichts, wenn's nicht wiederherstellbar ist.

Es nutzt dafür den rsync-Algorithmus und hält einen lokalen Cache vor, damit es den aktuellen Stand der Sicherung kennt. Somit sind auch inkrementelle Sicherungen schnell durchzuführen. Bei Duplicity sollten also in regelmässigem Abstand Vollsicherungen mit anschließenden inkrementellen Sicherungen durchgeführt werden. Damit für ein Restore allerdings keine 300 Inkremente zurückgesichert werden müssen, empfiehlt sich je nach Strategie mindestens eine Vollsicherung wöchentlich oder monatlich zu machen.

Rdiff-Backup ist ein Schwesterprojekt von Duplicity und geht einen anderen Weg. Es bietet längst nicht so viele Storage Backends wie Duplicity und legt seine Daten auch nicht verschlüsselt ab, aber es überträgt sie verschlüsselt (SFTP, SSH) und nutzt dafür eine sehr interessante Ablageform.

Der aktuelle Stand ist dabei immer der vollständige Stand und die älteren Stände werden als Differenz abgelegt. Im Vergleich mit Duplicity braucht man hier also nicht zwischen Vollsicherung und Inkrementen zu unterscheiden, da die aktuelle Sicherung immer eine vollständige ist. Einstellen muss man dabei nur noch maximale Haltezeit der alten Daten bevor sie gelöscht werden. Da die Differenzen auch nur sehr wenig Speicher belegen geht Rdiff-Backup sehr effizient mit dem verfügbaren Backup Store um.

UPDATE 04.04.2015

Der Unterschied zwischen rdiff-backup und duply wird deutlich, wenn man sich anschaut, welche Backup-Daten man benötigt, um eine bestimmte Datei wiederherzustellen. Schauen wir uns das mal genauer an.

Wenn wir aus dem letzten gesicherten Stand eine Datei wiederherstellen müssen, dann brauchen wir bei rdiff-backup einfach nur den aktuellen Stand. Die Datei liegt im Zielverzeichnis (Backup Store) direkt schon vor und man kann sie zurück kopieren oder mittels rdiff-backup auch wiederherstellen. Bei Duplicity benötigen wir das letzte Full-Backup sowie alle inkrementellen Backups um zum letzten Stand zu kommen. Hier ist ein einfaches zurückkopieren nicht möglich.

Dieser Nachteil von Duplicity kann aber auch ein Vorteil sein. Die Dateien im Backupspeicher können damit verschlüsselt sein. Bei rdiff-backup benötigt man auf der anderen Seite immer ebenfalls rdiff-backup und somit nicht nur einen FTP Speicher.

Empfehlung

Wird das Backup auf einen sicheren Datenspeicher abgelegt (weiterer eigener Rootserver, externe Festplatte), bietet sich Rdiff-Backup ganz klar an, da die Daten weniger Speicher benötigen und bei einer Rücksicherung direkt im Zugriff sind. Nutzt man unsicheren Speicher wie einen vom Provider gestellten FTP Server oder Amazon S3 bietet sich die Nutzung von Duplicity an.

In der Überschrift habe ich Duply noch erwähnt. Kurz gesagt: Duply macht Duplicity bedienbar und automatisierbar. Es entstand als Weiterentwicklung eines Scripts namens ftplicity, welches zunächst von einem Redakteur der Zeitschrift c't entwickelt wurde, allerdings nicht mehr weiter gepflegt wird. Wenn wir uns dem Thema Duplicity widmen, wird Duply eine Rolle spielen.