In diesem Artikel werden Sicherungssoftwaretools erläutert, die durch Aufteilen des Datenstroms in separate Komponenten (Chunks) ein Repository bilden.
Repository-Komponenten können zusätzlich komprimiert und verschlüsselt und vor allem bei wiederholten Sicherungsvorgängen wieder verwendet werden.
Eine Sicherung in einem ähnlichen Repository ist eine benannte Kette verwandter Komponenten, die beispielsweise auf verschiedenen Hash-Funktionen basiert.
Es gibt mehrere ähnliche Lösungen, ich werde mich auf 3 konzentrieren: zbackup, borgbackup und restic.
Erwartete Ergebnisse
Da alle Antragsteller auf die eine oder andere Weise die Erstellung eines Endlagers benötigen, ist die Schätzung der Größe des Endlagers einer der wichtigsten Faktoren. Im Idealfall sollte seine Größe nach der akzeptierten Methodik nicht mehr als 13 GB oder sogar weniger betragen - vorbehaltlich einer guten Optimierung.
Es ist auch sehr wünschenswert, Dateien direkt ohne Verwendung von Tar-Archivierern sichern zu können und mit ssh / sftp ohne zusätzliche Tools wie rsync und sshfs zu arbeiten.
Sicherungsverhalten:
- Die Größe des Repositorys entspricht der Größe der Änderungen oder weniger.
- Bei Verwendung von Komprimierung und / oder Verschlüsselung wird eine große Prozessorlast erwartet, und eine ziemlich große Belastung des Netzwerk- und Festplattensubsystems ist wahrscheinlich, wenn der Archivierungs- und / oder Verschlüsselungsprozess auf dem Sicherungsspeicherserver funktioniert.
- Wenn Sie das Repository beschädigen, ist ein verzögerter Fehler wahrscheinlich, sowohl beim Erstellen neuer Sicherungen als auch beim Versuch, eine Wiederherstellung durchzuführen. Es ist erforderlich, zusätzliche Maßnahmen zu planen, um die Integrität des Repositorys sicherzustellen, oder die integrierten Mittel zur Überprüfung seiner Integrität zu verwenden.
Die Arbeit mit Teer wird als Referenzwert akzeptiert, wie in einem der vorherigen Artikel gezeigt wurde.
Zbackup-Test
Der allgemeine Mechanismus der Zbackup-Operation besteht darin, dass das Programm Bereiche findet, die dieselben Daten in dem am Eingang bereitgestellten Datenstrom enthalten, diese dann optional komprimiert und verschlüsselt, wobei jeder Bereich nur einmal gespeichert wird.
Für die Deduplizierung wird eine 64-Bit-Ring-Hash-Funktion mit einem Schiebefenster verwendet, um die Übereinstimmung mit vorhandenen Datenblöcken zu überprüfen (ähnlich wie sie in rsync implementiert ist).
Für die Komprimierung werden lzma und lzo in der Multithread-Ausführung und für die Verschlüsselung verwendet. In den neuesten Versionen besteht in Zukunft die Möglichkeit, alte Daten aus dem Repository zu löschen.
Das Programm ist in C ++ mit minimalen Abhängigkeiten geschrieben. Der Autor war anscheinend von der Unix-Methode inspiriert, daher empfängt das Programm beim Erstellen von Backups Daten zu stdin und gibt stdout beim Wiederherstellen einen ähnlichen Datenstrom. Somit kann zbackup als ziemlich guter „Baustein“ verwendet werden, wenn Sie Ihre eigenen Backup-Lösungen schreiben. Zum Beispiel, der Autor des Artikels, ist dieses Programm seit etwa 2014 das wichtigste Backup-Tool für Heimcomputer.
Sofern nicht anders angegeben, wird ein regulärer Teer als Datenstrom verwendet.
Mal sehen, was die Ergebnisse sein werden:Die Überprüfung der Arbeit wurde in 2 Versionen durchgeführt:
- Ein Repository wird erstellt und zbackup wird auf dem Server mit den Quelldaten gestartet. Anschließend wird der Inhalt des Repositorys auf den Sicherungsspeicherserver übertragen.
- Auf dem Backup-Speicherserver wird ein Repository erstellt, zbackup wird über ssh auf dem Backup-Speicherserver gestartet, Daten werden über Pipe an das Repository übergeben.
Die Ergebnisse der ersten Option waren wie folgt: 43m11s - bei Verwendung eines unverschlüsselten Repositorys und eines lzma-Kompressors, 19m13s - beim Ersetzen des Kompressors durch lzo.
Die Belastung des Servers mit den Quelldaten war wie folgt (das Beispiel mit lzma wird gezeigt, mit lzo gab es ungefähr das gleiche Bild, aber der Anteil von rsync betrug ungefähr ein Viertel der Zeit):
Es ist klar, dass ein solcher Sicherungsprozess nur für relativ seltene und kleine Änderungen geeignet ist. Es ist auch sehr wünschenswert, den Betrieb von zbackup auf 1 Thread zu beschränken, da sonst der Prozessor sehr stark belastet wird, weil Das Programm kann sehr gut in mehreren Threads arbeiten. Die Festplattenlast war gering, was bei einem modernen ssd-basierten Festplattensubsystem im Allgemeinen nicht erkennbar ist. Sie können auch deutlich den Beginn des Prozesses zum Synchronisieren von Repository-Daten mit einem Remote-Server sehen. Die Geschwindigkeit ist vergleichbar mit der regulären rsync und hängt von der Leistung des Festplattensubsystems des Sicherungsspeicherservers ab. Der Nachteil des Ansatzes ist die Speicherung des lokalen Repositorys und infolgedessen die Verdoppelung von Daten.
Interessanter und praktischer in der Praxis ist die zweite Option, bei der zbackup sofort auf dem Backup-Speicherserver ausgeführt wird.
Zuerst werden wir den Betrieb ohne Verschlüsselung mit dem lzma-Kompressor überprüfen:
Die Laufzeit jedes Testlaufs:
Wenn Sie die Verschlüsselung mit aes aktivieren, sind die Ergebnisse ziemlich ähnlich:
Betriebszeit für dieselben Daten mit Verschlüsselung:
Wenn die Verschlüsselung mit der Komprimierung auf lzo kombiniert wird, sieht es folgendermaßen aus:
Arbeitszeit:
Die Größe des resultierenden Repositorys war relativ gleich und betrug 13 GB. Dies bedeutet, dass die Deduplizierung ordnungsgemäß funktioniert. Bei bereits komprimierten Daten führt die Verwendung von lzo zu einem spürbaren Effekt. In Bezug auf die Gesamtbetriebszeit nähert sich zbackup der Duplizität / Duplizierung, liegt jedoch 2-5-mal hinter den auf Librsync basierenden zurück.
Die Vorteile liegen auf der Hand: Sie sparen Speicherplatz auf dem Backup-Speicherserver. Für die Tools zum Überprüfen des Repositorys - sie werden nicht von zbackup bereitgestellt - wird empfohlen, ein ausfallsicheres Festplattenarray oder einen Cloud-Anbieter zu verwenden.
Im Allgemeinen ein sehr guter Eindruck, trotz der Tatsache, dass das Projekt ungefähr 3 Jahre läuft (die letzte Feature-Anfrage war vor ungefähr einem Jahr, aber ohne Antwort).
Borgbackup testen
Borgbackup ist eine Gabelung des Dachbodens, ein weiteres Zbackup-ähnliches System. Es ist in Python geschrieben, hat eine Liste von Funktionen ähnlich wie zbackup, weiß aber zusätzlich wie:
- Montieren Sie die Backups durch die Sicherung
- Überprüfen Sie den Inhalt des Repositorys
- Arbeiten Sie im Client-Server-Modus
- Verwenden Sie beim Komprimieren verschiedene Kompressoren für Daten sowie eine heuristische Definition des Dateityps.
- 2 Optionen für Verschlüsselung, AES und Blake
- Eingebautes Werkzeug für
Leistungsprüfungenborgbackup Benchmark Crud SSH: // Backup-Server / Repo / Pfad local_dir
Die Ergebnisse sind wie folgt:
CZ-BIG 96,51 MB / s (10 100,00 MB All-Zero-Dateien: 10,36 s)
RZ-BIG 57,22 MB / s (10 100,00 MB All-Zero-Dateien: 17,48 s)
UZ-BIG 253,63 MB / s (10 100,00 MB All-Zero-Dateien: 3,94 s)
DZ-BIG 351,06 MB / s (10 100,00 MB All-Zero-Dateien: 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 All-Zero-Dateien: 9,21 s)
RZ-MEDIUM 76,16 MB / s (1000 1,00 MB All-Zero-Dateien: 13,13 s)
UZ-MEDIUM 331,27 MB / s (1000 1,00 MB All-Zero-Dateien: 3,02 s)
DZ-MEDIUM 387,36 MB / s (1000 1,00 MB All-Zero-Dateien: 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 All-Zero-Dateien: 8,53 s)
RZ-SMALL 32,57 MB / s (10000 10,00 kB All-Zero-Dateien: 3,07 s)
UZ-SMALL 19,37 MB / s (10000 10,00 kB Null-Dateien: 5,16 s)
DZ-SMALL 33,71 MB / s (10000 10,00 kB All-Zero-Dateien: 2,97 s)
CR-SMALL 6,85 MB / s (10000 10,00 kB zufällige Dateien: 14,60 s)
RR-SMALL 31,27 MB / s (10000 10,00 kB zufällige Dateien: 3,20 s)
UR-SMALL 12,28 MB / s (10000 10,00 kB zufällige Dateien: 8,14 s)
DR-SMALL 18,78 MB / s (10000 10,00 kB zufällige Dateien: 5,32 s)
Während des Tests werden Heuristiken bei der Komprimierung mit der Definition des Dateityps (automatische Komprimierung) verwendet. Die Ergebnisse lauten wie folgt:
Überprüfen Sie zunächst den Vorgang ohne Verschlüsselung:
Arbeitszeit:
Wenn Sie die Repository-Autorisierung aktivieren (authentifizierter Modus), werden die Ergebnisse geschlossen:
Arbeitszeit:
Wenn die aes-Verschlüsselung aktiviert wurde, verschlechterten sich die Ergebnisse nicht wesentlich:
Und wenn Sie aes in blake ändern, wird sich die Situation vollständig verbessern:
Arbeitszeit:
Wie im Fall von Zbackup betrug die Größe des Repositorys 13 GB und sogar etwas weniger, was im Allgemeinen erwartet wird. Die Arbeitszeit war sehr erfreulich, sie ist vergleichbar mit Lösungen, die auf Librsync basieren und viel breitere Möglichkeiten bieten. Ich war auch zufrieden mit der Möglichkeit, verschiedene Parameter über Umgebungsvariablen einzustellen, was einen sehr gravierenden Vorteil bei der Verwendung von Borgbackup im automatischen Modus darstellt. Auch zufrieden mit dem Laden während des Backups: Gemessen an der Prozessorlast - Borgbackup funktioniert in 1 Thread.
Es gab keine besonderen Minuspunkte bei der Verwendung.
Restic testen
Trotz der Tatsache, dass Restic eine ziemlich neue Lösung ist (die ersten beiden Kandidaten sind seit 2013 und älter bekannt), weist es recht gute Eigenschaften auf. Geschrieben in Go.
Im Vergleich zu zbackup gibt es zusätzlich:
- Überprüfen der Integrität des Repositorys (einschließlich Einchecken von Teilen).
- Eine riesige Liste unterstützter Protokolle und Anbieter zum Speichern von Backups sowie rclone-rsync-Unterstützung für Cloud-Lösungen.
- Vergleich von 2 Backups untereinander.
- Montage des Repositorys über Sicherung.
Im Allgemeinen ist die Liste der Möglichkeiten ziemlich nahe an Borgbackup, an einigen Stellen mehr, an einigen Stellen weniger. Von den Funktionen - das Fehlen der Fähigkeit, die Verschlüsselung zu deaktivieren, und daher werden Backups immer verschlüsselt. Lassen Sie uns in der Praxis sehen, was Sie aus dieser Software herausholen können:
Die Ergebnisse sind wie folgt:
Arbeitszeit:
Die Ergebnisse sind auch mit rsync-basierten Lösungen vergleichbar und liegen im Allgemeinen sehr nahe am Borgbackup, aber die Prozessorlast ist höher (mehrere Threads funktionieren) und Sägezahn.
Höchstwahrscheinlich hängt das Programm von der Leistung des Festplattensubsystems auf dem Speicherserver ab, wie dies bei rsync der Fall war. Die Repository-Größe betrug 13 GB, genau wie bei Zbackup oder Borgbackup. Bei Verwendung dieser Lösung gab es keine offensichtlichen Nachteile.
Ergebnisse
Tatsächlich erhielten alle Kandidaten enge Indikatoren, jedoch zu einem anderen Preis. Borgbackup hat sich als das beste erwiesen, etwas langsamer - restic, zbackup, wahrscheinlich sollten Sie nicht mit der Bewerbung beginnen,
und wenn es bereits verwendet wird, versuchen Sie, zu borgbackup oder restic zu wechseln.
Schlussfolgerungen
Die vielversprechendste Lösung ist restic, as Er hat das beste Verhältnis von Fähigkeiten zu Geschwindigkeit, aber im Moment werden wir nicht zu allgemeinen Schlussfolgerungen eilen.
Borgbackup ist im Prinzip nicht schlechter, aber Zbackup ist wahrscheinlich besser zu ersetzen. Um jedoch sicherzustellen, dass Regel 3-2-1 funktioniert, kann zbackup weiterhin verwendet werden. Zum Beispiel zusätzlich zu Backup-Tools, die auf (lib) rsync basieren.
Ankündigung
Backup, Teil 1: Warum benötigen Sie ein Backup, einen Überblick über Methoden und Technologien?
Backup, Teil 2: Übersicht und Testen von rsync-basierten Backup-Tools
Backup, Teil 3: Übersicht und Testen der Duplizität, Duplikate
Backup, Teil 4: Übersicht und Testen von zbackup, restic, borgbackup
Backup, Teil 5: Testen von Bacula und Veeam Backup für Linux
Backup: Teil von Lesern angefordert: AMANDA Review, UrBackup, BackupPC
Backup, Teil 6: Vergleichen der Backup-Tools
Backup Teil 7: Schlussfolgerungen
Gepostet von Finnix