In diesem Artikel geht es um Backup-Software, die durch die Aufteilung des Datenstroms in separate Komponenten (Blöcke) ein Repository bildet.
Repository-Komponenten können weiter komprimiert und verschlüsselt und – was am wichtigsten ist – bei wiederholten Backup-Vorgängen wiederverwendet werden.
Eine Sicherungskopie in einem solchen Repository ist eine benannte Kette von Komponenten, die beispielsweise auf Basis verschiedener Hash-Funktionen miteinander verbunden sind.
Es gibt mehrere ähnliche Lösungen, ich konzentriere mich auf 3: zbackup, borgbackup und restic.
Erwartete Ergebnisse
Da alle Antragsteller auf die eine oder andere Weise die Einrichtung eines Endlagers fordern, wird einer der wichtigsten Faktoren die Schätzung der Größe des Endlagers sein. Idealerweise sollte seine Größe gemäß der akzeptierten Methodik nicht mehr als 13 GB betragen, oder sogar weniger – vorbehaltlich einer guten Optimierung.
Es ist außerdem äußerst wünschenswert, Sicherungskopien von Dateien direkt erstellen zu können, ohne Archivierungsprogramme wie tar zu verwenden, und mit ssh/sftp ohne zusätzliche Tools wie rsync und sshfs arbeiten zu können.
Verhalten beim Erstellen von Backups:
- Die Größe des Repositorys entspricht der Größe der Änderungen oder ist kleiner.
- Bei Verwendung von Komprimierung und/oder Verschlüsselung ist mit einer hohen CPU-Auslastung zu rechnen, und wenn der Archivierungs- und/oder Verschlüsselungsprozess auf einem Backup-Speicherserver ausgeführt wird, ist eine recht hohe Netzwerk- und Festplattenlast wahrscheinlich.
- Wenn das Repository beschädigt ist, ist sowohl beim Erstellen neuer Backups als auch beim Wiederherstellungsversuch ein verzögerter Fehler wahrscheinlich. Es ist notwendig, zusätzliche Maßnahmen zu planen, um die Integrität des Repositorys sicherzustellen, oder integrierte Tools zur Überprüfung seiner Integrität zu verwenden.
Als Referenzwert wird die Arbeit mit Teer genommen, wie in einem der vorherigen Artikel gezeigt wurde.
Zbackup testen
Der allgemeine Mechanismus von zbackup besteht darin, dass das Programm im Eingabedatenstrom Bereiche findet, die dieselben Daten enthalten, diese dann optional komprimiert und verschlüsselt und jeden Bereich nur einmal speichert.
Bei der Deduplizierung wird eine 64-Bit-Ring-Hash-Funktion mit einem Schiebefenster verwendet, um nach Byte-für-Byte-Übereinstimmungen mit vorhandenen Datenblöcken zu suchen (ähnlich wie rsync sie implementiert).
Multithreaded lzma und lzo werden zur Komprimierung und aes zur Verschlüsselung verwendet. Die neuesten Versionen bieten die Möglichkeit, alte Daten in Zukunft aus dem Repository zu löschen.
Das Programm ist in C++ mit minimalen Abhängigkeiten geschrieben. Der Autor hat sich offenbar von der Unix-Methode inspirieren lassen, sodass das Programm beim Erstellen von Backups Daten auf stdout akzeptiert und beim Wiederherstellen einen ähnlichen Datenstrom auf stdout erzeugt. Daher kann zbackup als sehr guter „Baustein“ beim Schreiben eigener Backup-Lösungen verwendet werden. Beispielsweise verwendet der Autor des Artikels dieses Programm seit etwa 2014 als wichtigstes Backup-Tool für Heimcomputer.
Sofern nicht anders angegeben, handelt es sich beim Datenstrom um einen regulären Tar-Datenstrom.
Mal sehen, was die Ergebnisse sind:
Die Arbeit wurde in 2 Optionen geprüft:
- Es wird ein Repository erstellt und zbackup mit den Quelldaten auf dem Server gestartet. Anschließend werden die Inhalte des Repositorys auf den Backup-Speicherserver übertragen.
- Auf dem Backup-Speicherserver wird ein Repository erstellt, Zbackup wird über SSH auf dem Backup-Speicherserver gestartet und Daten werden per Pipe dorthin gesendet.
Die Ergebnisse der ersten Option waren wie folgt: 43 Min. 11 Sek. – bei Verwendung eines unverschlüsselten Repositorys und des LZMA-Kompressors, 19 Min. 13 Sek. – beim Ersetzen des Kompressors durch LZO.
Die Belastung des Servers mit den Originaldaten war wie folgt (gezeigt ist ein Beispiel mit lzma; mit lzo ergab sich ungefähr das gleiche Bild, aber der Anteil von rsync betrug ungefähr ein Viertel der Zeit):
Es ist klar, dass ein solches Backup-Verfahren nur für relativ seltene und kleine Änderungen geeignet ist. Es ist außerdem sehr empfehlenswert, zbackup auf 1 Thread zu beschränken, da es sonst zu einer sehr hohen CPU-Last kommt, denn Das Programm ist sehr gut darin, in mehreren Threads zu arbeiten. Die Belastung der Festplatte war gering, was bei einem modernen SSD-basierten Festplattensubsystem im Allgemeinen nicht spürbar wäre. Sie können auch deutlich den Beginn des Prozesses der Synchronisierung von Repository-Daten mit einem Remote-Server erkennen; die Betriebsgeschwindigkeit ist vergleichbar mit normalem rsync und hängt von der Leistung des Festplatten-Subsystems des Backup-Speicherservers ab. Der Nachteil dieses Ansatzes ist die Speicherung eines lokalen Repositorys und die daraus resultierende Duplizierung von Daten.
Interessanter und in der Praxis anwendbarer ist die zweite Möglichkeit, zbackup direkt auf dem Backup-Speicherserver auszuführen.
Zuerst testen wir den Betrieb ohne Verschlüsselung mit dem lzma-Kompressor:
Laufzeit jedes Testlaufs:
Starten Sie 1
Starten Sie 2
Starten Sie 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Wenn Sie die Verschlüsselung mit aes aktivieren, sind die Ergebnisse recht ähnlich:
Betriebszeit auf denselben Daten, mit Verschlüsselung:
Starten Sie 1
Starten Sie 2
Starten Sie 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Wenn die Verschlüsselung mit der Komprimierung mittels lzo kombiniert wird, sieht das so aus:
Arbeitszeit:
Starten Sie 1
Starten Sie 2
Starten Sie 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Die Größe des resultierenden Repositorys war mit 13 GB relativ gleich. Dies bedeutet, dass die Deduplizierung ordnungsgemäß funktioniert. Auch bei bereits komprimierten Daten hat die Verwendung von lzo einen spürbaren Effekt; in Bezug auf die Gesamtbetriebszeit kommt zbackup nahe an duplicity/duplicati heran, bleibt aber zwei- bis fünfmal hinter denen zurück, die auf librsync basieren.
Die Vorteile liegen auf der Hand: Sie sparen Speicherplatz auf dem Backup-Speicherserver. Tools zur Repository-Überprüfung werden vom Autor von zbackup nicht bereitgestellt. Es wird empfohlen, ein fehlertolerantes Festplatten-Array oder einen Cloud-Anbieter zu verwenden.
Insgesamt ein sehr guter Eindruck, obwohl das Projekt schon seit ca. 3 Jahren stillsteht (die letzte Feature-Anfrage liegt ca. ein Jahr zurück, allerdings ohne Antwort).
Borgbackup testen
Borgbackup ist eine Abspaltung von Attic, einem weiteren System, das Zbackup ähnelt. Es ist in Python geschrieben und verfügt über eine Liste ähnlicher Funktionen wie zbackup, kann aber zusätzlich:
- Backups über Sicherung einbinden
- Überprüfen Sie den Repository-Inhalt
- Arbeiten Sie im Client-Server-Modus
- Nutzen Sie verschiedene Kompressoren für Daten sowie eine heuristische Bestimmung des Dateityps beim Komprimieren.
- 2 Verschlüsselungsoptionen, AES und Blake
- Eingebautes Werkzeug für
Leistungskontrollen
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Die Ergebnisse waren wie folgt:
CZ-BIG 96.51 MB/s (10 100.00 MB reine Nulldateien: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB reine Nulldateien: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB reine Nulldateien: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB reine Nulldateien: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB zufällige Dateien: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB zufällige Dateien: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB zufällige Dateien: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB zufällige Dateien: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB reine Nulldateien: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB reine Nulldateien: 13.13 s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB reine Nulldateien: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB reine Nulldateien: 2.58 s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB zufällige Dateien: 26.45 s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB zufällige Dateien: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB zufällige Dateien: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB zufällige Dateien: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB reine Nulldateien: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB reine Nulldateien: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB reine Nulldateien: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB reine Nulldateien: 2.97 s)
CR-SMALL 6.85 MB/s (10000 10.00 kB Zufallsdateien: 14.60 s)
RR-SMALL 31.27 MB/s (10000 10.00 kB Zufallsdateien: 3.20 s)
UR-SMALL 12.28 MB/s (10000 10.00 kB Zufallsdateien: 8.14 s)
DR-SMALL 18.78 MB/s (10000 10.00 kB Zufallsdateien: 5.32 s)
Beim Testen werden Komprimierungsheuristiken verwendet, um den Dateityp zu bestimmen (Komprimierung automatisch), und die Ergebnisse sind wie folgt:
Schauen wir uns zunächst an, wie es ohne Verschlüsselung funktioniert:
Arbeitszeit:
Starten Sie 1
Starten Sie 2
Starten Sie 3
4m6s
4m10s
4m5s
56er-Jahre
58er-Jahre
54er-Jahre
1m26s
1m34s
1m30s
Wenn Sie die Repository-Autorisierung aktivieren (authentifizierter Modus), sind die Ergebnisse ähnlich:
Arbeitszeit:
Starten Sie 1
Starten Sie 2
Starten Sie 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Bei aktivierter AES-Verschlüsselung verschlechterten sich die Ergebnisse nicht wesentlich:
Starten Sie 1
Starten Sie 2
Starten Sie 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Und wenn Sie aes in blake ändern, wird sich die Situation völlig verbessern:
Arbeitszeit:
Starten Sie 1
Starten Sie 2
Starten Sie 3
4m33s
4m43s
4m40s
59er-Jahre
1m0s
1m0s
1m38s
1m43s
1m40s
Wie im Fall von zbackup betrug die Repository-Größe 13 GB und sogar etwas weniger, was allgemein erwartet wird. Mit der Laufzeit war ich sehr zufrieden; sie ist vergleichbar mit Lösungen auf Basis von librsync und bietet viel umfassendere Möglichkeiten. Ich war auch zufrieden mit der Möglichkeit, verschiedene Parameter über Umgebungsvariablen festzulegen, was bei der Verwendung von Borgbackup im automatischen Modus einen erheblichen Vorteil darstellt. Auch mit der Auslastung beim Backup war ich zufrieden: Gemessen an der Prozessorauslastung arbeitet Borgbackup in einem Thread.
Es gab keine besonderen Nachteile bei der Verwendung.
Restic-Test
Obwohl es sich bei Restic um eine relativ neue Lösung handelt (die ersten beiden Kandidaten waren bereits 2 und älter bekannt), weist sie recht gute Eigenschaften auf. Geschrieben in Go.
Im Vergleich zu zbackup bietet es zusätzlich:
- Überprüfung der Integrität des Repositorys (einschließlich Einchecken von Teilen).
- Eine riesige Liste unterstützter Protokolle und Anbieter zum Speichern von Backups sowie Unterstützung für rclone – rsync für Cloud-Lösungen.
- Vergleich von 2 Backups miteinander.
- Montage des Repositorys über Sicherung.
Im Allgemeinen ähnelt die Liste der Funktionen der von Borgbackup, an manchen Stellen mehr, an anderen weniger. Eines der Features besteht darin, dass es keine Möglichkeit gibt, die Verschlüsselung zu deaktivieren, weshalb Sicherungskopien immer verschlüsselt werden. Sehen wir uns in der Praxis an, was aus dieser Software herausgeholt werden kann:
Die Ergebnisse waren wie folgt:
Arbeitszeit:
Starten Sie 1
Starten Sie 2
Starten Sie 3
5m25s
5m50s
5m38s
35er-Jahre
38er-Jahre
36er-Jahre
1m54s
2m2s
1m58s
Die Leistungsergebnisse sind auch mit rsync-basierten Lösungen vergleichbar und kommen im Allgemeinen denen von borgbackup sehr nahe, allerdings ist die CPU-Auslastung höher (mehrere Threads laufen) und sägezahnförmig.
Höchstwahrscheinlich ist das Programm durch die Leistung des Festplattensubsystems auf dem Datenspeicherserver begrenzt, wie dies bereits bei rsync der Fall war. Die Repository-Größe betrug 13 GB, genau wie bei zbackup oder borgbackup, es gab keine offensichtlichen Nachteile bei der Verwendung dieser Lösung.
Ergebnisse
Tatsächlich erzielten alle Kandidaten ähnliche Ergebnisse, allerdings zu unterschiedlichen Preisen. Borgbackup schnitt am besten ab, Restic war etwas langsamer, zbackup ist es wahrscheinlich nicht wert, damit anzufangen,
und wenn es bereits verwendet wird, versuchen Sie es in borgbackup oder restic zu ändern.
Befund
Die vielversprechendste Lösung scheint Restic zu sein, denn... Er ist es, der das beste Verhältnis von Fähigkeiten zur Arbeitsgeschwindigkeit hat, aber lassen Sie uns vorerst keine voreiligen Schlussfolgerungen ziehen.
Borgbackup ist im Grunde nicht schlechter, aber zbackup wird wahrscheinlich besser ersetzt. Zwar kann zbackup weiterhin verwendet werden, um sicherzustellen, dass die 3-2-1-Regel funktioniert. Beispielsweise zusätzlich zu (lib)rsync-basierten Backup-Funktionen.
Ankündigung
Backup Teil 5: Testen von Bacula- und Veeam-Backups für Linux
Backup Teil 6: Vergleich von Backup-Tools
Backup Teil 7: Schlussfolgerungen
Geschrieben von: Pavel Demkovich
Source: habr.com