Skip to content

Linux Backup mit Duply, Duplicity und Rdiff-Backup auf (potentiell unsichere) Online Speicher (Teil 1)

Same procedure as every year, James!

Der neue Rootserver ist fertig, aber benötigt noch ein Backup. Hat man nun nicht gerade ein Rechenzentrum im Keller und kann dort Bänder wechseln gehen, bietet sich für Rootserver ein Backup auf verfügbaren Onlinespeicher an. Das kann in einigen Fällen ein weiterer Rootserver mit noch reichlich Platz sein, aber auch ein vom Provider zur Verfügung gestellter FTP Server oder auch Amazons S3 sind gute Alternativen.

Diverse Tools machen einem das Leben deutlich leichter und Backups zum Vergnügen. Im Folgenden gehe ich auf Duply/Duplicity und Rdiff-Backup in Verbindung mit einem weiteren Backup-Server, FTP Server und Amazon S3 ein und zeige wie man sichere Backups erstellt, die man hinterher auch wieder brauchen kann.

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.

 

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Ted on :

Ich versteh nicht ganz , also wenn dupply die Backups auch inkrementell macht, wieso muss man da ein fullbackup machen und bei rdiff-backup nicht?

Marco on :

Normalerweise benötigt man für ein inkrementelles Backup zunächst ein Full-Backup als Basis.

Nur bei rdiff-backup ist das etwas anders aufgrund der Arbeitsweise. rdiff-backup sichert zwar nur die geänderten Daten, erzeugt dabei aber immer ein vollständiges Backup in dem es die unveränderten Dateien aus der letzten Sicherung nimmt und diese daher nicht mehr übertragen muss. Dabei behält es die alten Versionen der neu überschriebenen Dateien noch bei, so dass man auch auf ältere Dateien noch zugreifen kann.

Man könnte auch sagen: rdiff-backup sichert inkrementell, aber rückwärts. Es merkt sich die Änderungen zum jeweils älteren Stand, nicht zum neueren wie bei anderen Systemen üblich.

Add Comment

Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.
BBCode format allowed
You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.
Form options
tweetbackcheck cronjob