Backups

Für eine anständige Backup-Strategie bin ich schon fast so lange am überlegen wie für meine Groupware-Verwaltung. Nachdem ich mir extra dafür eine externe 500 GB Festplatte gekauft hatte, fehlte nur noch die passende Softwarelösung. Neidisch schaut man im ersten Moment auf Apple's TimeMachine. Rein Objektiv ist dies aber auch nichts anderes als ein Inkrementelles Backup mit kurzen Iterationszeiten und einer netten GUI. Alternativen für Linux wie Flyback sind vorhanden. Allerdings ist dies nicht die einzige Möglichkeit eines sinnvollen Backups.

Fakt ist wohl, ein Backup sollte möglichst nicht jedes mal eine eins-zu-eins Kopie anlegen, da so viel zu viel Speicher verbraucht wird. Lösung sind Inkrementelle oder Differenzielle Backups. So werden nur die Änderungen gespeichert die sich verändert haben. Fast jede Lösung bietet dieses Konzept mittlerweile an. Außerdem wollte ich ein Backup auf Datei-Ebene und nicht auf Partitionsebenen wie es zum Beispiel das Tool dd anbietet. Da ich denke so Flexibler bin und außerdem glaube ich nicht das Inkrementelle Backups auf Partitionsebene möglich ist.

Zuerst plante ich ein Backup mit einem Selbstgeschriebenden Skriptes. Über die Linux-Boardmittel lassen sich eine Vielzahl der der Anforderungen wie Verschlüsselung und Komprimierung recht einfach implementieren. Allerdings wenn man alle Möglichkeiten mit allen kombinieren möchte so wird es irgendwann richtig komplex. So habe ich meine ersten Versuche verworfen und plante mit einem umfangreichen Backup-Programm wie BoxBackup oder Bacula. Hier habe ich aber auch recht schnell erkannt das diese für große Netzwerke ausgelegt sind und für meinen kleinen Laptop etwas überdimensioniert sind. Etwas einfaches musste her!

Über Chaosradio bin ich auf ZFS gestoßen. Ein Filesystem mit einer unglaublichen Feature-Liste. Angefangen von automatischer Größen-Anpassung von Partitionen über automatische Komprimierung bis hin zu gesicherter Konsistenz des Dateisystems bietet es alles was man sich wünschen kann. ZFS bietet auch die Möglichkeit von Snapshots auf Block-Ebene an. Man kann die Daten, die sich geändert haben, einfach über die alten drüber kopieren und anschließend ein Snapshot machen. So hat man im Grunde jedes mal ein Vollbackup obwohl man nur die geänderten Blöcke speichern muss. Leider kommt ZFS aus der Solaris-Welt und kann in den Linux-Kernel im Moment wegen Lizenzproblemen nicht integriert werden. Es existiert zwar eine FUSE-Erweiterung, aber alles noch recht Beta. Das Risiko wollte ich leider nicht beim Backup eingehen und musste mich so nach Alternativen umschauen.

Das System mit den Snapshots hat mir aber gefallen und so bin ich auf das recht populäre Tool rsnapshot gestoßen. Das Programm setzt auf Hardlinks auf. Bei normalen (Soft-)Links hat man eine Datei und erstellt dann Referenzen auf diese Datei. Löscht man eine Referenz interessiert das niemanden. Löscht man die ursprüngliche Datei werden alle Referenzen ungültig. Bei Hardlinks referenziert man nicht auf eine Datei sondern auf ein INode-Eintrag. Also sozusagen eine Ebene Tiefer. Der Vorteil ist, alle Hardlinks sind gleichberechtigt. Die eigentlichen Daten werden erst gelöscht, wenn kein Hardlink mehr darauf verweist. Das Prinzip von rsnapshot ist dadurch recht einfach: Man kopiert das letzte Backup mittels Hardlinks in ein neues Verzeichnis und ändert dann über rsync die veränderten Dateien. So erhält man jeden Tag ein Vollbackup welches nur den Speicherplatz der Änderungen verbraucht.

Ein weiters sehr nützliches Feature ist die Möglichkeit eigene Scripte (z.B. um ein Datenbankdump zu erstellen) in das Backup einzubinden. Und wenn man zum Beispiel einen zweiten Computer mit sichern will, so ist es möglich Daten von diesem über ssh+rsync zu hohlen. Somit sichere ich mein Laptop mein Server und die Datenbank auf meinem Server recht einfach mit nur einem Programm

Leider kann rsnapshot, anders wie ZFS nur auf Datei-Ebene arbeiten. So wird eine Datei in der sich nur ein Buchstabe ändert komplett neu übertragen. Auch wird es nicht erkannt wenn man ein Verzeichnis oder eine Datei umbenennt. Auch in diesem Fall wird die Datei neu abgespeichert. Aber wenn man sich der Problematik bewusst ist, stört sie kaum.

Programme wie Storebackup umgehen das Problem indem sie zu jeder Datei Prüfsummen anlegen und diese vergleichen. Allerdings ergibt sich so ein worst-case-Aufwand von O(n^2) da ja jede Checksumme erst einmal erstellt, und dann mit jeder Datei verglichen werden muss. Man sieht schon, diese Lösung braucht um einiges länger als mein rsnapshot. (180 GB in ca 10 Minuten täglich bei einem diff von gerade mal einigen hundert MB). Außerdem wollte ich auch ein gut getestetes Konzept und habe mich so für das weit verbreitete rsnapshot entschieden satt das (evtl gar nicht mehr weiter entwickelte) Storebackup.

Und nun die Zuschauerfrage: Wie macht ihr eure Backups? Ich denke jeder der am Computer arbeitet braucht ein Backup, da Datenverlust nur eine Frage des Wann ist. Und wenn die Dateien nur einmal pro Woche auf DVD gebrannt werden. Auf jeden Fall würde mich euer Setup interessieren. Gerne auch in einem eigenen Blog-Post bei euch. Verlinkt euch einfach in den Kommentaren!