rss feed articles all_comments

indeedgeek.de

Florian Eitel

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!

Comments:

(howto comment?)

http://kerneltrap.org/node/16428 TuX3 Versionion Filesystem, läuft darauf hinaus, dass es ‘besser’ als ZFS sein soll… ;)

Postet on by anonymous.

Naja ich bin da etwas skeptisch. TuX3 FS ist erstmal angekündigt. Programmiert ist da noch nicht viel. Und soweit ich gelesen habe war Tux2 schon so ein Reinfall, da man nach der Ankündigung nicht mehr viel gehört hat.

Aber Versionierung auf FS-Ebene hört sich schon nicht schlecht an. Allerdings wird es kaum an den Feature-Reichtum und der Sicherheit von ZFS heran kommen, da hier einfach SUN als große Firma dahinter steht.

Meine Backupstrategie erfasst nur meinen Server im Keller. Desktop und Notebook syncen beim An- und Abmelden an der Domäne im heimischen LAN, online greife ich über https auf die Daten auf dem Server zu, sofern ich vergessen habe, die neuesten Dateien vor Abmarsch aufs Notebook zu bügeln.

Im Server läuft ein RAID 1, von dem per Volume Shadow Copy alle 4 Stunden ein Snapshot der Dateien gezogen wird. Die Historie geht über 14 Tage. Einmal wöchentlich wird ein inkrementelles Backup der Daten auf eine externe Festplatte abgelegt und in unregelmäßigen Abständen, wenn ~4gb zusammen gekommen sind auf DVD gebrannt.

Aktuell bin ich dabei, scriptgesteuert ein vollständiges Backup der Platten anlegen zu lassen, sobald sich die SMART Daten der eingesetzten Festplatten über eine definierte Einheit (zum negativen hin) verändern.

Postet on by anonymous.

Ich habe zuhause eine NSLU2 mit Debian und zwei Platten im RAID. Über NFS mounte ich beim Start meiner Rechner die RAID-Partition und arbeite damit. In unregelmäßigen Abständen mach ich von den wichtigsten Daten Backup auf DVD.

Die Festplatten rausche ich alle 2 Jahre aus, auch wenn sie noch (ein bisschen) funktionieren. Da ist mir das Risiko zu hoch, dass sie irgend wann (im unpassensten Moment) den Geist aufgeben.

Zur Zeit experimentiere ich etwas mit Amazons S3 und Jungledisk herum. Wenn ich da was lauffähiges/sinnvolles habe, melde ich mich nochmal.

Abgesehen vom Backup gibt es auch noch ein weiteres wichtiges Kriterium, auf das ich seit Jahren schaue: Kann ich mit den Daten noch was anfangen, wenn ich das Programm dazu nicht mehr habe? Sind die Daten wertlos, wenn ich auf ein anderes Programm umsteige? Kann ich mit meinen Daten auch auf ein anderes Betriebssystem umziehen?

Ein Anmerkung zu storeBackup:

Es wird offensichtlich aktiv weiterentwickelt. Inzwischen ist die Version 3.0 verfügbar, die auch große Image Dateien (z.B. von VMware, Xen, oder auch mbox-Dateien) schnell und effizient sichern kann.

Die Aussage O(2) zur Performance ist völlig falsch. StoreBackup berechnet nur bei neuen bzw. geänderten Dateien die md5 Summe neu.

Siehe auch: http://savannah.gnu.org/projects/storebackup