Linux Server Backup mit restic und duplicity
Bei Backupprogrammen haben Nutzer die Qual der Wahl. Kostenlose, open-source Lösungen konkurrieren mit kostenpflichtigen, kommerziellen Tools, neben Kommandozeilenprogrammen gibt es solche mit graphischen Benutzeroberflächen und auch bei der Backupmethodik gibt es ganz unterschiedliche Ansätze. Die Auswahl sollte also gut überlegt sein, schließlich vertraut man darauf, dass man im Ernstfall auch an alle seine Daten wieder ran kommt bzw. den eigenen Server ohne Datenverlust wieder aufsetzen kann. In der Vergangenheit hat unser Home Server Homie und unser Small Business Server Fellow auf duplicity in Kombination mit duply als Backuplösung vertraut. Mit dem Cockpit 2.0 haben wir duplicity/duply durch restic ersetzt. In diesem Artikel beschreiben wir die Unterschiede dieser beiden kommandozeilenbasierten open-source Lösungen und damit auch die Gründe für den Wechselentscheid.
duplicity – encrypted bandwidth-efficient backup using the rsync algorithm
duplicity erblickte im Jahre 2002 mit der Version 0.1 das Licht der Welt. Die konstante Weiterentwicklung seitdem resultiert in der aktuellen Version 0.8.11 (Stand Februar 2020), die für Linux, BSD und macOS zur Verfügung steht und mit vielen bekannten Linux Distributionen wie Ubuntu, Debian und Fedora ausgeliefert wird. Auch unter Windows lässt sich duplicity in Form von Cygwin verwenden. Die Versionsnummer 0.x sollte auch nicht zu voreiligen Schlüssen verleiten. duplicity ist ein zuverlässiges Programm, das im Produktiveinsatz seine Leistungsfähigkeit unter Beweis gestellt hat.
duplicitys Backups bestehen aus Vollbackups mit nachfolgenden inkrementellen Backups. Die inkrementellen Backups enthalten nur die Dateien, die sich seit dem letzten Backuplauf verändert haben bzw. neu inzugekommen sind. In Backupsprech sind das sogenannte forward deltas. Eine zusammengehörde Abfolge aus einem Voll- und dazugehörigen inkrementellen Backups ist eine Backup-Kette bzw. eine backup chain im englischen Original. (Eine detaillierte Beschreibung der Arbeitsweise von duplicity sowie der grundlegenden Kommandozeilenbefehlen gibt es in unserem Blog-Artikel duplicity/duply: Datensicherung auf die Verlass ist.)
Während des Backupvorgangs prüft duplicity mit Hilfe des rsync-Algorithmus auf Dateiänderungen seit des letzten Laufs. Geänderte und gelöschte Dateien werden dann in tar-Archive gepackt, ggf. komprimiert und/oder verschlüsselt und anschließend in ein gewünschtes Zielverzeichnis geschrieben. Beim Zielsystem beschränkt sich duplicity nicht nur auf den lokalen Datenspeicher, sondern kann die tar-Archive auch in Cloud Storages wie Amazon S3, Backblaze, Dropbox, Microsoft OneDrive/Azure schreiben. All diese Vorgänge erfolgen streng sequenziell, d.h. solange Dateien gepackt werden, werden keine Daten gespeichert; wenn tar-Dateien geschrieben werden, werden keine Dateien gepackt.
duplicity erzeugt drei Arten von Dateien im Zielverzeichnis:
- Die Manifest-Datei enthält Informationen über die gesicherten Dateien und deren Position in den gesicherten tar-Archiven.
- Difftar nennt duplicity die tar-Archive. Diese haben immer die gleiche Größe (z.B. 200 MB) und werden fortlaufend mit vol1 bis voln nummeriert.
- Sigtar-Dateien enthalten die Prüfsummen der gesicherten Backup-Dateien. Diese Prüfsummen werden für die Änderungsprüfung benötigt.
duplicity komprimiert die Difftar-Archive auf Wunsch mit gzip und verschlüsselt sämtliche Dateien mit GnuPG. So kann man seine Backups auch auf Cloud-Speichern ablegen, ohne die Vertraulichkeit der Daten zu kompromitieren.
Der Ansatz von duplicity ist sicher und zuverlässig. Bei Verzicht auf die optionale Verschlüsselung und Komprimierung erreicht man mit duplicity auch gute Schreibraten. Andererseits hat duplicity ein paar inhärente Nachteile:
- Ein Fehler in der Backup-Kette macht nachfolgenden Backups quasi wertlos.
- Zum Schutz vor Korruption sollten mehrere Backup-Ketten vorgehalten werden. Dies multipliziert den Backupspeicherplatz.
- Die sequenzielle Abarbeitung ist zeitaufwändig.
- Die regelmäßigen Vollbackups erfordern viel Geduld.
- Die Datenwiederherstellung – insbesondere bei vielen inkrementellen Backups – dauert lange.
restic – Backups done right!
Im Vergleich zu duplicity ist restic ein Jungspund. Gemäß Changelog auf Github wurde es erstmalig im Jahre 2017 mit der Version 0.6 veröffentlicht. Der Designansatz von restic unterscheidet sich grundsätzlich von duplicity, da nicht mehr fortlaufend Voll- und inkrementelle Backups gesichert werden, sondern die zu sichernden Daten als zerteilte Datenblöcke in einem Repository aufbewahrt werden. Dieses Datenmodell macht restic zu einem nahen Verwandten von Git und Seafile.
Das zentrale Ziel dieses Ansatzes ist die Vermeidung von doppelten Inhalten, die Beschleunigung des Backupvorgehens und eine fortlaufende Sicherung in Form von Snapshots. Man könnte fast sagen, dass jeder Backuplauf von restic ein Vollbackup ist, wobei restic selbst jede Sicherung als einen Snapshot bezeichnet.
Man kann sich die restic Sicherung am ehesten wie einen Setzkasten vorstellen, bei dem jedes Objekt nur einmal vorkommt. Bei einem Backuplauf wird zunächst jede Datei in kleine Datenblöcke zerteilt und deren Prüfsummen berechnet. Diese werden dann verwendet, um zu prüfen, ob die Datenblöcke im Setzkasten bereits existieren. Wenn nicht, dann werden Sie übertragen. Bei einer Dateiänderung muss somit nicht die gesamte Datei erneut gesichert werden, sondern lediglich der Datenblock mit dem veränderten Teil. Dabei ist es für restic nicht erforderlich, dass die neu hinzugekommene Datenblöcke auf dem Speichermedium in der Nähe der dazugehörigen Blöcke gespeichert werden. restic kümmert sich darum, dass aus den Datenblöcken jederzeit wieder Dateien zusammengesetzt werden können. Ein Snapshot enthält somit die Informationen, welche Dateien zum damaligen Zeitpunkt gesichert wurden und aus welchen Datenblöcken die einzelnen Dateien bestehen.
restic Repositories sind immer verschlüsselt. Gleichzeitig unterstützt restic eine beeindruckende Vielzahl an Speicherzielen wie Amazon S3, Backblaze, Google Cloud und Microsoft Azure. restic bietet darüber hinaus noch weitere spannende Fähigkeiten. Backupläufe können mit frei gewählten Tags versehen werden und jeder Snapshots kann zu jedem Zeitpunkt lokal gemountet werden. So wird die Wiederherstellung von einzelnen oder allen Daten zum Kinderspiel.
Bei restic entfallen praktisch alle Nachteile von duplicity: restic arbeitet schnell und effizient; restic benötigt deutlich weniger Speicherplatz auf dem Backupziel; ein Restore mit restic – egal ob einzelne Dateien oder der gesamte Umfang – erfolgt extrem schnell, da kein aufwändiges Zusammensetzen der Dateien aus den Difftars notwendig ist. Selbst wenn einzelne Datenblöcke im Repository von restic beschädigt sein sollten, hat dies keinen Einfluss auf den Gesamtzustand des Backups. Die Datei, zu der der fehlende oder beschädigte Datenblock gehört, lässt sich vielleicht nicht mehr herstellen, alle anderen Dateien sind davon aber nicht betroffen.
Backups so einfach und schnell wie noch nie
restic ist ein vergleichsweise neues Backuptool, welches jedoch in kürzester Zeit eine große Fangemeinde erworben hat. Auch uns haben die Vorteile von restic überzeugt. Die Geschwindigkeit, die Zuverlässigkeit und der geringe Speicherbedarf auf dem Backupziel in Kombination mit einer guten Dokumentation und einfachen Bedienung machen restic zu einem optimalen Backuptool für Linux Server.
Mit dem Cockpit 2.0 steht nun restic auch allen Besitzern eines datamate Servers als Backuptool zur Verfügung. Die Schritte zum Erstellen eines Backups im Cockpit sind identisch geblieben – die Technik im Hintergrund ist gänzlich neu. Einmal eingerichtet übernimmt restic die Sicherung des gesamten Servers.