In diesem Artikel werden Softwarelösungen für die Datensicherung behandelt, die durch die Aufteilung des Datenstroms in einzelne Komponenten (Chunks) ein Repository bilden.
Die Repository-Komponenten können zusätzlich komprimiert und verschlüsselt werden, und das Wichtigste ist, dass sie bei wiederholten Sicherungsprozessen wiederverwendet werden können.
Eine Sicherung in einem solchen Repository ist eine benannte Kette von miteinander verbundenen Komponenten, beispielsweise basierend auf verschiedenen Hash-Funktionen.
Es gibt mehrere solche Lösungen; ich werde auf drei eingehen: zbackup, borgbackup und restic.
Erwartete Ergebnisse
Da alle Kandidaten auf die eine oder andere Weise die Erstellung eines Repositories erfordern, wird eine der wichtigsten Bewertungen die Größe des Repositories sein. Im Idealfall sollte seine Größe gemäß der angenommenen Methodik 13 GB nicht überschreiten, möglicherweise sogar weniger – vorausgesetzt, es erfolgt eine gute Optimierung.
Es ist auch äußerst wünschenswert, die Möglichkeit zu haben, Sicherungen von Dateien direkt zu erstellen, ohne Archivierungsprogramme wie tar zu verwenden, sowie die Arbeit mit ssh/sftp ohne zusätzliche Hilfsmittel wie rsync und sshfs.
Verhalten beim Erstellen von Backups:
- Die Größe des Repositories entspricht der Größe der Änderungen oder ist sogar kleiner.
- Bei der Verwendung von Kompression und/oder Verschlüsselung ist mit einer hohen CPU-Auslastung zu rechnen, und es kann auch eine erhebliche Belastung für das Netzwerk und das Speichersystem auftreten, falls der Archivierungs- und/oder Verschlüsselungsprozess auf dem Backup-Server läuft.
- Wenn das Repository beschädigt wird, kann sowohl bei der Erstellung neuer Backups als auch beim Versuch der Wiederherstellung ein verzögertes Fehler auftreten. Es sind zusätzliche Maßnahmen zur Gewährleistung der Integrität des Repositories zu planen oder integrierte Integritätsprüfungen zu nutzen.
Als Referenzwert wird die Arbeit mit tar verwendet, wie in einem früheren Artikel gezeigt.
Testen von zbackup
Die grundlegende Funktionsweise von zbackup besteht darin, dass das Programm in dem gegebenen Datenstrom Bereiche identifiziert, die identische Daten enthalten, diese optional komprimiert, verschlüsselt und jeden Bereich nur einmal speichert.
Für die Deduplizierung wird eine 64-Bit-Ring-Hash-Funktion mit gleitendem Fenster verwendet, um byteweise auf Übereinstimmungen mit bereits vorhandenen Datenblöcken zu überprüfen (ähnlich wie es in rsync implementiert ist).
Für die Komprimierung werden lzma und lzo in multithreaded Ausführung verwendet, und für die Verschlüsselung kommt aes zum Einsatz. In den neuesten Versionen gibt es die Möglichkeit, künftig alte Daten aus dem Repository zu entfernen.
Das Programm ist in C++ mit minimalen Abhängigkeiten geschrieben. Der Autor wurde offensichtlich vom Unix-Prinzip inspiriert, weshalb das Programm Daten über stdin beim Erstellen von Backups annimmt und einen ähnlichen Datenstrom über stdout beim Wiederherstellen ausgibt. So kann zbackup als nützliches 'Baustein' beim Schreiben eigener Backup-Lösungen verwendet werden. Beispielsweise ist dieses Programm seit etwa 2014 das Hauptmittel für Backups auf den Heimcomputern des Autors.
Als Datenstrom wird standardmäßig tar verwendet, sofern nicht anders angegeben.
Sehen wir uns die Ergebnisse an:
Die Funktionsprüfung wurde in 2 Varianten durchgeführt:
- Ein Repository wird erstellt und zbackup auf dem Server mit den Ausgangsdaten gestartet, dann wird der Inhalt des Repositories auf den Backup-Server übertragen.
- Ein Repository wird auf dem Backup-Server erstellt, zbackup wird über ssh auf dem Backup-Server gestartet und erhält die Daten über eine Pipe.
Die Ergebnisse der ersten Variante waren wie folgt: 43m11s – unter Verwendung eines unverschlüsselten Repositories und eines lzma-Kompressors, 19m13s – bei Ersetzung des Kompressors durch lzo.
Die Serverlast mit den Ausgangsdaten war wie folgt (hier ein Beispiel mit lzma, mit lzo war es ähnlich, aber der Anteil von rsync betrug etwa ein Viertel der Zeit):
Es ist offensichtlich, dass ein solcher Backup-Prozess nur bei relativ seltenen und geringen Änderungen geeignet ist. Zudem ist es dringend empfehlenswert, die Arbeit von zbackup auf einen Thread zu beschränken, da die CPU-Auslastung sonst sehr hoch sein wird, da das Programm sehr gut mit mehreren Threads arbeiten kann. Die Disklast war gering, was insgesamt bei modernen SSD-basierten Speichersystemen kaum bemerkbar sein wird. Auch wird deutlich, dass der Prozess der Datensynchronisation des Repositories auf den Remote-Server gestartet wird, die Arbeitsgeschwindigkeit ist vergleichbar mit dem üblichen rsync und stößt an die Leistungsgrenzen des Speicher-Backup-Systems. Ein Nachteil dieses Ansatzes ist die Speicherung des lokalen Repositories und damit verbunden die Daten-Duplizierung.
Die zweite Option, das zbackup direkt auf dem Backup-Speicherserver zu starten, ist interessanter und praktischer.
Zunächst wird die Funktionalität ohne die Verwendung von Verschlüsselung mit dem lzma-Kompressor geprüft:
Die Laufzeit jedes Testdurchlaufs:
Start 1
Start 2
Start 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Wenn die AES-Verschlüsselung aktiviert wird, sind die Ergebnisse ausreichend nah:
Benötigte Zeit mit denselben Daten und Verschlüsselung:
Start 1
Start 2
Start 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Wenn die Verschlüsselung mit der Kompression mit lzo kombiniert wird, ergibt sich Folgendes:
Laufzeit:
Start 1
Start 2
Start 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Die Größe des resultierenden Repositories war relativ konstant und betrug 13 GB. Dies bedeutet, dass die Deduplication korrekt funktioniert. Auch bei bereits komprimierten Daten zeigt die Anwendung von lzo einen spürbaren Effekt. Insgesamt kommt zbackup hinsichtlich der Gesamtzeit für die Verarbeitung nahe an duplicity/duplicati heran, bleibt aber um das 2- bis 5-fache hinter den auf librsync basierenden Lösungen zurück.
Die Vorteile sind offensichtlich — Einsparungen beim Speicherplatz auf dem Backup-Speicherserver. Was die Überprüfung des Repositories betrifft, so sind dafür keine Werkzeuge vorgesehen. Es wird empfohlen, ein ausfallsicheres RAID-System oder einen Cloud-Anbieter zu verwenden.
Insgesamt ein recht guter Eindruck, trotz der Tatsache, dass das Projekt seit etwa 3 Jahren stagniert (die letzte Funktionenanfrage war vor etwa einem Jahr, jedoch ohne Antwort).
Borgbackup testen
Borgbackup ist ein Fork von attic, einem ähnlichen System wie zbackup. Es ist in Python geschrieben und hat eine ähnliche Liste von Funktionen wie zbackup, kann jedoch zusätzlich:
- Backups über FUSE einbinden
- Den Inhalt des Repositories überprüfen
- Im Client-Server-Modus arbeiten
- Verschiedene Komprimierungsalgorithmen für Daten verwenden und eine heuristische Dateityperkennung bei der Komprimierung durchführen.
- 2 Verschlüsselungsoptionen, AES und Blake
- Integriertes Werkzeug zur
Leistungsüberprüfung
borgbackup benchmark crud://backup_server/repo/path local_dir
Die Ergebnisse waren folgendermaßen:
C-Z-BIG 96,51 MB/s (10 100,00 MB All-Zero-Dateien: 10,36s)
R-Z-BIG 57,22 MB/s (10 100,00 MB All-Zero-Dateien: 17,48s)
U-Z-BIG 253,63 MB/s (10 100,00 MB All-Zero-Dateien: 3,94s)
D-Z-BIG 351,06 MB/s (10 100,00 MB All-Zero-Dateien: 2,85s)
C-R-BIG 34,30 MB/s (10 100,00 MB zufällige Dateien: 29,15s)
R-R-BIG 60,69 MB/s (10 100,00 MB zufällige Dateien: 16,48s)
U-R-BIG 311,06 MB/s (10 100,00 MB zufällige Dateien: 3,21s)
D-R-BIG 72,63 MB/s (10 100,00 MB zufällige Dateien: 13,77s)
C-Z-MEDIUM 108,59 MB/s (1000 1,00 MB All-Zero-Dateien: 9,21s)
R-Z-MEDIUM 76,16 MB/s (1000 1,00 MB All-Zero-Dateien: 13,13s)
U-Z-MEDIUM 331,27 MB/s (1000 1,00 MB All-Zero-Dateien: 3,02s)
D-Z-MEDIUM 387,36 MB/s (1000 1,00 MB All-Zero-Dateien: 2,58s)
C-R-MEDIUM 37,80 MB/s (1000 1,00 MB zufällige Dateien: 26,45s)
R-R-MEDIUM 68.90 MB/s (1000 1,00 MB zufällige Dateien: 14,51s)
U-R-MEDIUM 347.24 MB/s (1000 1,00 MB zufällige Dateien: 2,88s)
D-R-MEDIUM 48.80 MB/s (1000 1,00 MB zufällige Dateien: 20,49s)
C-Z-SMALL 11.72 MB/s (10000 10,00 kB vollständige Null-Dateien: 8,53s)
R-Z-SMALL 32.57 MB/s (10000 10,00 kB vollständige Null-Dateien: 3,07s)
U-Z-SMALL 19.37 MB/s (10000 10,00 kB vollständige Null-Dateien: 5,16s)
D-Z-SMALL 33.71 MB/s (10000 10,00 kB vollständige Null-Dateien: 2,97s)
C-R-SMALL 6.85 MB/s (10000 10,00 kB zufällige Dateien: 14,60s)
R-R-SMALL 31.27 MB/s (10000 10,00 kB zufällige Dateien: 3,20s)
U-R-SMALL 12.28 MB/s (10000 10,00 kB zufällige Dateien: 8,14s)
D-R-SMALL 18.78 MB/s (10000 10,00 kB zufällige Dateien: 5,32s)
Bei den Tests wird Heuristik zur Kompression unter Berücksichtigung des Dateityps verwendet (Kompression automatisch), die Ergebnisse sind wie folgt:
Zuerst prüfen wir die Funktion ohne Verschlüsselung:
Laufzeit:
Start 1
Start 2
Start 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Wenn die Authentifizierung des Repositories aktiviert ist (authentifizierter Modus), sind die Ergebnisse ähnlich:
Laufzeit:
Start 1
Start 2
Start 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Bei Aktivierung der AES-Verschlüsselung verschlechterten sich die Ergebnisse nicht wesentlich:
Start 1
Start 2
Start 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Wenn AES gegen Blake getauscht wird, verbessert sich die Situation erheblich:
Laufzeit:
Start 1
Start 2
Start 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Wie bei zbackup betrug die Repository-Größe 13 GB und sogar etwas weniger, was insgesamt zu erwarten war. Die Betriebszeiten haben mich positiv überrascht; sie sind vergleichbar mit Lösungen, die auf librsync basieren, und bieten viel breitere Möglichkeiten. Auch die Möglichkeit, verschiedene Parameter über Umgebungsvariablen festzulegen, ist ein ernsthaftes Plus, wenn man borgbackup im automatisierten Modus verwendet. Zudem war die Last während der Sicherung erfreulich niedrig: Anhand der CPU-Auslastung zu urteilen, arbeitet borgbackup in einem Thread.
Es wurden keine besonderen Nachteile bei der Nutzung festgestellt.
Test von restic
Obwohl restic eine relativ neue Lösung ist (die ersten zwei Kandidaten sind schon seit 2013 oder älter bekannt), bietet es recht ordentliche Eigenschaften. Es ist in Go geschrieben.
Im Vergleich zu zbackup bietet es zusätzlich:
- Die Integritätsprüfung des Repositories (einschließlich der Prüfung in Teilen).
- Eine riesige Liste unterstützter Protokolle und Anbieter für die Speicherung von Sicherungskopien sowie die Unterstützung von rclone — rsync für "Cloud"-Lösungen.
- Vergleich von zwei Sicherungskopien miteinander.
- Mounten des Repositories über fuse.
Insgesamt ist die Liste der Funktionen von borgbackup recht ähnlich, an manchen Stellen mehr, an anderen weniger. Ein besonderes Merkmal ist, dass die Möglichkeit, die Verschlüsselung zu deaktivieren, fehlt, daher sind die Backups immer verschlüsselt. Lassen Sie uns in der Praxis sehen, was wir aus dieser Software herausholen können:
Die Ergebnisse sind wie folgt:
Laufzeit:
Start 1
Start 2
Start 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Die Ergebnisse sind auch vergleichbar mit Lösungen auf Basis von rsync und insgesamt recht nah an borgbackup, allerdings ist die CPU-Belastung höher (es arbeiten mehrere Threads) und unregelmäßig.
Wahrscheinlich stößt das Programm an die Leistungsgrenzen des Speichersystems auf dem Datenspeicher-Server, wie es bereits bei rsync der Fall war. Die Größe des Repositories betrug 13 GB, genau wie bei zbackup oder borgbackup, wobei keine offensichtlichen Nachteile bei der Verwendung dieser Lösung festgestellt wurden.
Ergebnisse
In der Tat lagen die Ergebnisse aller Kandidaten nahe beieinander, jedoch zu unterschiedlichen Preisen. Borgbackup schnitt am besten ab, etwas langsamer waren restic und zbackup, das wahrscheinlich nicht eingesetzt werden sollte,
und wenn es bereits verwendet wird, sollten Sie in Erwägung ziehen, zu borgbackup oder restic zu wechseln.
Fazit
Die vielversprechendste Lösung scheint restic zu sein, da sie das beste Verhältnis von Funktionalität zu Arbeitsgeschwindigkeit bietet. Aber lassen Sie uns noch keine allgemeinen Schlussfolgerungen ziehen.
Borgbackup ist im Grunde genommen nicht schlechter, aber zbackup sollte wahrscheinlich ersetzt werden. Allerdings kann zbackup weiterhin zur Einhaltung der 3-2-1-Regel verwendet werden, beispielsweise neben Backup-Lösungen auf Basis von (lib)rsync.
Ankündigung
Backup, Teil 5: Test von Bacula und Veeam Backup für Linux
Backup, Teil 6: Vergleich von Backup-Tools.
Backup, Teil 7: Fazit
Autor der Publikation: Pavel Demkovich
Quelle: habr.com
