Backuptools

Backups sind ein leidiges aber eben auch wichtiges Thema. Zum Glück gibt es heutzutage wirklich tolle Tools um auch umfangreiche Backup zu erzeugen. Wenn dabei dann noch die anfallenden Datenmengen klein genug werden, dass selbst eine normale DSL-Leitung ausreicht um das Backup zu externen Speichern zu übertragen, ist man Nahe dran am heiligen Backupgral.

Lange Zeit habe ich nach Tools gesucht, die ein Backup in kurzer Zeit, mit geringen Bandbreitenbedarf, Verschlüsselung, einwandfreier und vollständiger Überprüfbarkeit und einfacher Wiederherstellung gewährleisten.

Meine ersten Backups habe ich einfach per Hand gemacht, das ist natürlich sowohl zeit- als auch fehleranfällig, außerdem nervt es und wird deswegen nicht regelmäßig gemacht. Also hat man das irgendwann automatisiert. Am einfachsten ist es hier natürlich, wenn man einfach die zu sichernden Daten irgendwo hinkopiert. Der Nachteil, man hat nur eine einzige Kopie und während man ein neues Backup erstellt, ist diese Kopie nicht einmal konsistent. Geht während des Backups das Quelllaufwerk kaputt, steht man im schlimmsten Fall ohne funktionierendes Backup da.

Also wollen wir mehrere Backupgenerationen. Auch schon, weil ja Fehler nicht immer sofort auffallen. Wenn ich nur eine Backupgeneration zurückgehen kann, ist der Fehler dort vielleicht auch schon enthalten. Wenn ich jetzt aber 7 oder mehr Tage zurückgehen möchte, brauche ich mind. 7 mal so viel Speicherplatz.

rsnapshot

Mein erstes Backuptool für mehrere Generationen war rsnapshot¹. Es erstellt Backups mittels rsync². Das ist schon einmal gut, weil ich dadurch sehr flexibel darin bin wohin ich meine Backups speichern möchte. Außerdem überträgt rsync nur Daten, die auf den Ziel noch nicht vorhanden sind. Das spart Zeit und Bandbreite. Dem Speicherplatzproblem trägt rsnapshot insofern Rechnung, als dass Daten, die sich zwischen den Backupläufen nicht geändert haben, nicht erneut gespeichert werden. Stattdessen wird einfach ein Hardlink³ - also eine Referenz - auf die unveränderte Datei gesetzt.

Wie viele Backupgenerationen ich haben möchte, kann ich flexibel einstellen. Ich könnte z.B. sagen ich möchte 24 stündliche Backup, 7 tägliche und 4 monatliche Backupgenerationen aufbewahren. rsnapshot erstellt dann eine passende Ordnerstruktur und kümmert sich darum die Daten entsprechend zu rotieren.

Da rsnapshot Hardlinks setzt, sieht jeder Ordner/jede Backupgeneration so aus, wie ein vollständiges Backup. Es wird aber für jede (unveränderte) Datei nur einmal Speicherplatz belegt. Eine Wiederherstellung (Restore) der Daten ist denkbar einfach. Einfach die gewünschte Generation an die gewüschte Stelle kopieren, fertig. Auch eine Überprüfung des Backups ist recht einfach, da man die Dateien ja direkt öffnen kann. Auch ein Vergleich der Anzahl und Größe der Dateien ist leicht machbar. Man könnte das Backup sogar direkt im Netzwerk freigeben, damit versehentlich gelöschte Dateien von den Benutzern direkt und selbst wiederhergestellt werden können.

Leider dauert ab einem gewissen Punkt der Abgleich der zu sichernden Daten relativ lang. Weiterer Nachteil, ändert sich in einer sehr großen Datei auch nur ein einziges Bit, muss sie komplett neu und in voller Größe neu gesichert werden. Außerdem verfügt rsnapshot über keine Möglichkeit die Backupdaten zu verschlüsseln, weshalb es für Remote-Locations eher ungeeignet ist.

duplicity

duplicity⁴ kann hier ein paar der Nachteile von rsnapshot beseitigen, bringt dafür jedoch leider eigene Nachteile mit sich. Auch duplicity nutzt rsync, kann die Daten aber mittels GnuPG⁵ verschlüsseln. Unabhängig davon, ob man von dieser Option Gebrauch macht, werden die Daten in tarballs⁶ gespeichert. Anders als rsnapshot nutzt duplicity keine Hardlinks um die Datenmenge zu reduzieren sondern setzt auf inkrementelle Backups und rdiff⁷. Bei inkrementellen Backups wird zunächst ein Fullbackup der zu sichernden Daten erzeugt. Danach werden dann nur noch die Daten gesichert, die sich geändert haben. Hierbei bauen alle inkrementellen Backups aufeinander auf. Das spart zwar Speicherplatz, macht aber ein Restore der Daten auf Dauer sehr komplex. Außerdem müssen alle Backupgenerationen vollständig intakt sein, damit eine Wiederherstellung einwandfrei möglich ist. Man ist also gut beraten nur für eine gewisse Zeit auf inkrementelle Backups zu setzen und mind. einmal im Monat ein neues Fullbackup anzufertigen.⁸ Das ist natürlich für Remote-Locations eventuell problematisch, da hier natürlich immer sehr große Datenmengen anfallen können.

Was mir an duplicity gut gefällt, es setzt auf Standardtools (GnuPG, tar, (r)diff, rsync) um seine Backups zu erzeugen. Man könnte also ein Restore auch ohne die Nutzung von duplicity selbt bewerkstelligen und im Zweifel kleinere Probleme beim Restore manuell umschiffen. Auf der anderen Seite macht das aber den Restoreprozess auch relativ komplex und vor allem langwierig.

Eine Alternative zu duplicity ist rdiff-backup⁹.

borg

borg¹⁰ (oder früher attic) ist angetreten all die o.g. Probleme zu lösen. Ich bezeichne borg auch gerne als den heiligen Gral der Backuptools. borg nutzt ein eigenes Repository-Format um die Backupdaten zu verwalten. Das erscheint auf den ersten Blick wie ein Nachteil (so wie bei duplicity), da ich ja nicht mehr einfach so auf meine gesicherten Daten zugreifen kann. borg verfügt aber um einen eigenen mount Befehl, mit dem sich das Backuprepo einfach als (virtuelles) Dateisystem einbinden lässt.

borg setzt, statt auf inkrementelle Backups, auf Deduplizierung. Ähnlich wie ein Packprogramm speichert borg wiederkehrende Datenblöcke nur ein einziges Mal. Kommt der Block an einer anderen Stelle erneut vor, wird er nicht erneut gespeichert, sondern nur referenziert. Das ist gerade im Hinblick auf viele Backupgenerationen natürlich besonders Sinnvoll, da hierbei per Definition ständig gleiche Datenblöcke entstehen. borg setzt aber nicht nur für die Backupgenerationen auf Deduplizierung, sondern nutzt diese auch innerhalb von Dateien. Habe ich z.B. eine 500GB große Datenbank und verändere in dieser nur ein Byte, dann wird auch nur dieses Byte (plus etwas Kontext, wo dieses Byte sich befindet) gespeichert.

Das Resultat sind nicht nur extrem kleine Backups (oft sogar, trotz mehrerer Generationen, kleiner als die Originaldaten), sondern auch eine sehr geringe Bandbreitennutzung. Dank des mount Befehls ist ein Restore extrem schnell und einfach. Darüber hinaus bietet borg einen verify Befehl, um die Integrität des Backup-Repositories zu testen.

Der größte Nachteil von borg sind der Ressourcenverbrauch (vor allem RAM) während des Backups, da der Deduplizierungsvorgang recht aufwändig ist. Außerdem legt borg einen lokalen Cache an, der schnell mehrere GB groß werden kann. Außerdem benötigt borg bei Remotebackups eine entsprechende Gegenstelle, daher kommen nicht alle Remotespeicher in Frage.

restic

restic¹¹ wirkt auf den ersten Blick vom Funktionsumfang absolut identisch mit borg. Und tatsächlich nutzt restic ebenfalls ein eigenes Repository-Format und Deduplizierung. Auch hier gibt es einen mount Befehl und generell fühl sich restic in der Nutzung sehr ähnlich an. Der Hauptunterschied: restic benötigt keine spezielle Gegenstelle. Somit kann quasi jeder Remotespeicher genutzt werden.

Diesen Vorteil erkauft man sich jedoch mit einem Geschwindigkeitsnachteil. Während des Backups und Restores tritt dieser nicht so sehr in den Vordergrund, aber Abfragen zum Repo-Status dauern mitunter deutlich länger als bei borg.

Und ich meine deutlich länger, wo ein borg info etwa 1,5 Sekunden für eine Antwort braucht, nimmt sich ein restic stats gerne mal mehrere Minuten:

                       Original size      Compressed size    Deduplicated size
All archives:              290.93 GB            152.01 GB             23.70 GB

                       Unique chunks         Total chunks
Chunk index:                  394806              5733043
borg status  1.41s user 0.47s system 35% cpu 5.337 total

Stats in restore-size mode:
Snapshots processed:   14
   Total File Count:   5284261
         Total Size:   791.021 GiB
restic stats  218.19s user 10.75s system 104% cpu 3:39.81 total

Und ja, die Repositories sind deutlich unterschiedlich, in der Praxis macht das aber kaum einen Unterschied, borg ist immer deutlich schneller. Mir gefällt zudem der Output von borg deutlich besser.

Dennoch restic ist in meinen Augen on-par mit borg. In der Nutzung liegt mir borg zwar mehr, aber am Ende zählt, ob ich mir sicher sein kann, dass meine Backups funktionieren und genau das gewährleistet restic ebenso wie borg, ist dabei aber noch einen Tick flexibler einsetzbar.

Eine Sache an restic stört mich jedoch, auch wenn sie wahrscheinlich gut gemeint ist. Wenn man die Liste der Verzeichnisse/Dateien die restic sichern soll ändert, rotiert restic die alten Backupgenerationen (Snapshots) nicht mehr. Das kann gut sein, wenn man versehentlich ein Verzeichnis aus der Liste entfernt. Aber wenn man einfach nur ein Verzeichnis hinzufügt oder eines absichtlich entfernt, dann muss man - wenn einem die Belegung des Backupsspeichers wichtig ist - manuell darum kümmern, die alten Snapshots nach und nach loszuwerden.

Fazit

Alle genannten Tools haben ihre Daseinsberechtigung. In der Praxis nutze ich rsnapshot gerne als Backup für Fileserver (z.B. samba). Das erzeugte Backup kann man mit Samba auch gleich wieder freigeben (sollte natürlich bestenfalls auf einem anderen Server liegen) und Benutzer können versehentlich gelöschte Dateien - oder ältere Versionen - ohne mein Zutun wiederherstellen.

Duplicity nutze ich nicht mehr, für eher kleinere Backups (z.B. vom eigenen Homeverzeichnis) ist es aber dennoch gut geeignet.

borg und restic nutze ich beide, insbesondere für Backups von Servern. borg ist hierbei mein Standardtool. restic nutze ich vornehmlich als zusätzliches Backup für besonders wichtige Daten. Dabei verteile ich die Daten auf unterschiedlichen Remotesystemen. borg nutze ich hierbei meist im gleichen Rechenzentrum in denen sich auch der zu sichernde Server befindet. So ist eine besonders schnelle Wiederherstellung gewährleistet. restic nutze ich für ein Backup bei einem anderen Anbieter, so sind die Daten auch bei Insolvenz, Brand oder massiven technischen Problem meines Hostinganbieters sicher. Da restic keine besonderen Voraussetzungen auf der Gegenstelle benötigt, habe ich hier eine große Auswahl von Speichermöglichkeiten. Außerdem bin ich durch die Nutzung von borg und restic einigermaßen sicher vor eventuellen Bugs in den Backuptools, die eventuell eine Wiederherstellung unmöglich machen könnten.