In diesem Artikel werden Softwarelösungen für die Datensicherung betrachtet, die durch das Aufteilen von Datenströmen in separate Komponenten (Chunks) ein Repository bilden.
Die Komponenten des Repositories können zusätzlich komprimiert und verschlüsselt werden und, das Wichtigste - bei wiederholten Sicherungsprozessen - erneut wiederverwendet werden.
Ein Backup in einem solchen Repository ist eine benannte Kette miteinander verbundener Komponenten, beispielsweise basierend auf verschiedenen Hash-Funktionen.
Es gibt mehrere solche Lösungen, ich werde mich auf drei konzentrieren: zbackup, borgbackup und restic.
Erwartete Ergebnisse
Da alle Bewerber mehr oder weniger die Erstellung eines Repositories erfordern, wird eine der wichtigsten Faktoren die Bewertung der Repository-Größe sein. Im Idealfall sollte seine Größe 13 GB gemäß der anerkannten Methode nicht überschreiten, oder sogar kleiner sein - vorausgesetzt, es gibt eine gute Optimierung.
Es ist auch äußerst wünschenswert, die Möglichkeit zu haben, Backups von Dateien direkt zu erstellen, ohne Archivierungsprogramme wie tar zu verwenden, sowie die Arbeit mit ssh/sftp ohne zusätzliche Mittel wie rsync und sshfs.
Verhalten bei der Erstellung von Backups:
- Die Größe des Repositories wird der Größe der Änderungen entsprechen oder kleiner sein.
- Es wird mit einer hohen CPU-Belastung beim Einsatz von Kompression und/oder Verschlüsselung gerechnet, und zudem ist eine erhebliche Belastung für das Netzwerk und das Speichersystem wahrscheinlich, wenn der Prozess der Archivierung und/oder Verschlüsselung auf dem Backup-Server ausgeführt wird.
- Falls das Repository beschädigt wird, ist eine verzögerte Fehleranmeldung sowohl bei der Erstellung neuer Backups als auch bei dem Versuch der Wiederherstellung wahrscheinlich. Es sollten zusätzliche Maßnahmen zur Gewährleistung der Integrität des Repositories eingeplant werden oder eingebaute Mittel zur Überprüfung seiner Integrität verwendet werden.
Als Referenzwert wurde die Arbeit mit tar angenommen, wie in einem der vorherigen Artikel gezeigt.
Testing zbackup
Der allgemeine Mechanismus von zbackup besteht darin, dass das Programm in dem Datenstrom, der an den Eingang gegeben wird, Bereiche identifiziert, die identische Daten enthalten, und diese dann optional komprimiert, verschlüsselt und jede Region nur einmal speichert.
Zur Deduplication wird eine 64-Bit-Ring-Hash-Funktion mit gleitendem Fenster für eine Byte-für-Byte-Überprüfung verwendet, um Übereinstimmungen mit bereits vorhandenen Datenblöcken zu erkennen (ähnlich wie es in rsync implementiert ist).
Für die Kompression werden lzma und lzo in multithreaded Ausführung eingesetzt, und für die Verschlüsselung kommt aes zum Einsatz. In den neuesten Versionen besteht die Möglichkeit, ältere Daten zukünftig aus dem Repository zu entfernen.
Das Programm ist in C++ mit minimalen Abhängigkeiten geschrieben. Der Autor ließ sich anscheinend vom Unix-Weg inspirieren, weshalb das Programm Daten über stdin beim Erstellen von Backups entgegennimmt und beim Wiederherstellen einen ähnlichen Datenstrom über stdout ausgibt. So kann zbackup als recht nützlicher "Baustein" zur Erstellung eigener Backup-Lösungen verwendet werden. Beispielsweise ist dieses Programm beim Autor des Artikels seit etwa 2014 das Hauptmittel zur Datensicherung für Heimcomputer.
Als Datenstrom wird standardmäßig tar verwendet, sofern nicht anders angegeben.
Lassen Sie uns sehen, welche Ergebnisse erzielt wurden:
Die Funktionsprüfung wurde in 2 Varianten durchgeführt:
- Ein Repository wird erstellt und zbackup wird auf dem Server mit den Quelldaten gestartet, anschließend wird der Inhalt des Repositories auf den Backup-Speicher-Server übertragen.
- Ein Repository wird auf dem Backup-Speicher-Server erstellt, zbackup wird über ssh auf dem Backup-Speicher-Server gestartet, die Daten werden ihm über eine Pipe bereitgestellt.
Die Ergebnisse der ersten Variante waren: 43m11s — bei Verwendung eines unverschlüsselten Repositories und des Kompressors lzma, 19m13s — bei Austausch des Kompressors gegen lzo.
Die Belastung des Servers mit den Quelldaten war wie folgt (beispielhaft dargestellt mit lzma; mit lzo war das Bild ungefähr ä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 kleinen Änderungen geeignet ist. Es ist auch dringend ratsam, die Arbeit von zbackup auf einen Thread zu beschränken, da sonst die CPU-Auslastung sehr hoch ist, da das Programm ziemlich gut in mehreren Threads arbeiten kann. Die Belastung der Festplatte war gering, was in der heutigen Festplattensubsystem auf SSD-Basis insgesamt unauffällig ist. Auch der Start des Daten-Synchronisationsprozesses des Repositories auf dem Remote-Server ist deutlich sichtbar; die Geschwindigkeit ist vergleichbar mit der von rsync und wird durch die Leistung des Speichersystems des Backup-Servers limitiert. Nachteil dieses Ansatzes ist die Speicherung des lokalen Repositories und somit die Duplizierung der Daten.
Interessanter und praktischer ist die zweite Option, zbackup direkt auf dem Backup-Speicherserver zu starten.
Zu Beginn wird die Funktion ohne die Verwendung von Verschlüsselung mit dem Komprimierungsalgorithmus lzma überprüft:
Die Laufzeit jeder Testausführung:
Ausführung 1
Ausführung 2
Ausführung 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Wenn die Verschlüsselung mit aes aktiviert wird, sind die Ergebnisse recht ähnlich:
Die Laufzeit mit denselben Daten, jedoch mit Verschlüsselung:
Ausführung 1
Ausführung 2
Ausführung 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Wenn die Verschlüsselung mit lzo-Kompression kombiniert wird, ergeben sich folgende Ergebnisse:
Die Laufzeit:
Ausführung 1
Ausführung 2
Ausführung 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
Die Größe des resultierenden Repositories war relativ gleich und betrug 13 GB. Das bedeutet, dass die Deduplizierung korrekt funktioniert. Außerdem hat die Anwendung von lzo auf bereits komprimierten Daten einen merklichen Effekt; die Gesamtlaufzeit von zbackup nähert sich stark an die von duplicity/duplicati an, bleibt jedoch 2-5 mal hinter denen zurück, die auf librsync basieren.
Die Vorteile sind offensichtlich – Einsparungen beim Speicherplatz auf dem Backup-Speicherserver. Was die Tools zur Überprüfung des Repositories betrifft, so sind diese von dem Autor von zbackup nicht vorgesehen, es wird empfohlen, ein fehlerresistentes RAID-System oder einen Cloud-Anbieter zu verwenden.
Insgesamt ein sehr positiver Eindruck, obwohl das Projekt seit etwa 3 Jahren stillsteht (die letzte Feature-Anfrage war vor etwa einem Jahr, blieb jedoch unbeantwortet).
Testen von borgbackup
Borgbackup ist ein Fork von attic, einem weiteren, ähnlich wie zbackup konzipierten System. Es wurde in Python geschrieben und hat eine ähnliche Liste von Funktionen wie zbackup, kann jedoch zusätzlich:
Borgbackup ist ein Fork von attic, einem weiteren, ähnlichen System wie zbackup. Es ist in Python geschrieben und bietet eine ähnliche Funktionalität wie zbackup, kann aber zusätzlich:
- Sicherheitskopien über fuse erstellen
- Den Inhalt des Repositories überprüfen
- Im Client-Server-Modus arbeiten
- Verschiedene Kompressoren für Daten verwenden sowie eine heuristische Bestimmung des Dateityps bei der Komprimierung.
- 2 Verschlüsselungsvarianten, aes und blake
- Integriertes Tool zur
Leistungsüberprüfung
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Die Ergebnisse sind wie folgt:
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 Zufallsdateien: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB Zufallsdateien: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB Zufallsdateien: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB Zufallsdateien: 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 Zufallsdateien: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB Zufallsdateien: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB Zufallsdateien: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB Zufallsdateien: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB All-Zero-Dateien: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB All-Zero-Dateien: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB All-Zero-Dateien: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB All-Zero-Dateien: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB Zufallsdateien: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB Zufallsdateien: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB Zufallsdateien: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB Zufallsdateien: 5.32s)
Bei den Tests wird eine Heuristik bei der Kompression mit Dateitypbestimmung (compression auto) verwendet, und die Ergebnisse sind folgende:
Zuerst prüfen wir die Leistung ohne Verschlüsselung:
Die Laufzeit:
Ausführung 1
Ausführung 2
Ausführung 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Wenn die Repository-Authentifizierung (authentifizierter Modus) aktiviert ist, sind die Ergebnisse nahezu identisch:
Die Laufzeit:
Ausführung 1
Ausführung 2
Ausführung 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Bei Aktivierung der aes-Verschlüsselung verschlechtern sich die Ergebnisse nicht merklich:
Ausführung 1
Ausführung 2
Ausführung 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Wenn aes durch blake ersetzt wird, verbessert sich die Situation erheblich:
Die Laufzeit:
Ausführung 1
Ausführung 2
Ausführung 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Wie im Fall von zbackup betrug die Größe des Repositories 13 GB und sogar etwas weniger, was insgesamt zu erwarten war. Die Arbeitszeit hat erfreulich gut abgeschnitten, sie ist vergleichbar mit Lösungen, die auf librsync basieren, und bietet erheblich umfassendere Möglichkeiten. Auch die Möglichkeit, verschiedene Parameter über Umgebungsvariablen festzulegen, bietet einen erheblichen Vorteil bei der Verwendung von borgbackup im automatischen Modus. Auch die Last während der Sicherung war ermutigend: Judging by the CPU usage—borgbackup operates in 1 thread.
Es wurden keine wesentlichen Nachteile bei der Nutzung festgestellt.
Tests mit restic
Trotz der Tatsache, dass Restic eine relativ neue Lösung ist (die ersten zwei Kandidaten sind seit 2013 oder älter bekannt), weist es recht gute Eigenschaften auf. Es ist in Go geschrieben.
Im Vergleich zu zbackup bietet es zusätzlich:
- Die Überprüfung der Integrität des Repositories (einschließlich der Überprüfung in Teilen).
- Eine riesige Liste unterstützter Protokolle und Anbieter für die Speicherung von Backups sowie die Unterstützung von rclone – rsync für "Cloud"-Lösungen.
- Den Vergleich von zwei Backups untereinander.
- Das Einbinden des Repositories über FUSE.
Insgesamt ist die Liste der Möglichkeiten relativ nah an borgbackup, manchmal mehr, manchmal weniger. Zu den Besonderheiten gehört das Fehlen der Möglichkeit, die Verschlüsselung auszuschalten, 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:
Die Laufzeit:
Ausführung 1
Ausführung 2
Ausführung 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Die Ergebnisse sind auch vergleichbar mit den Lösungen auf Basis von rsync und insgesamt sehr nah an borgbackup, aber die CPU-Auslastung ist höher (es arbeiten mehrere Threads) und von zackiger Natur.
Wahrscheinlich stößt das Programm an die Leistungsgrenze des Speichersystems auf dem Datenspeicherserver, wie es bereits bei rsync der Fall war. Die Größe des Repositories betrug 13 GB, ebenso wie bei zbackup oder borgbackup, es wurden keine offensichtlichen Nachteile bei der Verwendung dieser Lösung festgestellt.
Ergebnisse
Faktisch hatten alle Kandidaten ähnliche Werte, jedoch zu unterschiedlichen Preisen. Am besten schnitt borgbackup ab, gefolgt von Restic, während zbackup wahrscheinlich nicht mehr verwendet werden sollte,
und wenn es bereits verwendet wird, sollte man auf borgbackup oder Restic umsteigen.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Die vielversprechendste Lösung scheint Restic zu sein, da es das beste Verhältnis von Möglichkeiten zur Arbeitsgeschwindigkeit bietet, aber lassen Sie uns noch keine allgemeinen Schlussfolgerungen ziehen.
Borgbackup ist im Prinzip nicht schlechter, während zbackup wahrscheinlich besser ersetzt werden sollte. Allerdings kann zbackup weiterhin zur Einhaltung der 3-2-1-Regel eingesetzt werden. Zum Beispiel zusätzlich zu Backup-Lösungen auf Basis von (lib)rsync.
Ankündigung
Backup, Teil 5: Tests von Bacula und Veeam Backup für Linux
Backup, Teil 6: Vergleich von Backup-Tools
Backup, Teil 7: Zusammenfassungen
Autor der Veröffentlichung: Pavel Demković
Quelle: habr.com
