In diesem Beitrag werden Backup-Tools betrachtet, die durch das Erstellen von Archiven auf einem Backup-Server Sicherungen erstellen.
Von den Anforderungen erfüllenden Tools sind duplicity (mit einer benutzerfreundlichen Oberfläche in Form von deja dup) und duplicati.
Ein weiteres bemerkenswertes Backup-Tool ist dar, aber da es eine sehr umfangreiche Liste von Optionen hat — die getestete Methodik deckt kaum 10 % dessen ab, was es kann — wird es im aktuellen Zyklus nicht getestet.
Erwartete Ergebnisse
Da beide Kandidaten auf die eine oder andere Weise Archive erstellen, kann als Referenz das gängige tar verwendet werden.
Zusätzlich bewerten wir, wie gut die Speicherung von Daten auf dem Backup-Server optimiert wird, indem Sicherungen erstellt werden, die nur die Unterschiede zwischen einer vollständigen Kopie und dem aktuellen Status der Dateien oder zwischen früheren und aktuellen Archiven enthalten (inkrementell, dekrementell usw.).
Verhalten beim Erstellen von Backups:
- Eine vergleichsweise geringe Anzahl von Dateien auf dem Backup-Server (im Vergleich zur Anzahl der Backups oder der Datenmenge in GB), aber deren Größe ist ausreichend groß (Zehntausende bis Hunderttausende Megabyte).
- Die Größe des Repositories umfasst nur die Änderungen — Duplikate werden nicht gespeichert, sodass die Größe des Repositories kleiner ist als bei Software, die auf rsync basiert.
- Bei der Verwendung von Komprimierung und/oder Verschlüsselung wird eine hohe CPU-Auslastung erwartet, ebenso wahrscheinlich eine erhebliche Belastung des Netzwerks und des Speichersystems, wenn der Archivierungs- und/oder Verschlüsselungsprozess auf dem Backup-Server ausgeführt wird.
Wir starten den folgenden Befehl als Referenzwert:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Die Ergebnisse der Ausführung sind wie folgt:
Die Ausführungszeit beträgt 3m12s. Es ist deutlich zu erkennen, dass die Geschwindigkeit durch das Speichersystem des Backup-Servers begrenzt wird, wie im Beispiel mit . Nur etwas schneller, da die Daten in eine einzige Datei geschrieben werden.
Um die Kompression zu bewerten, führen wir die gleiche Variante aus, jedoch aktivieren wir die Kompression auf der Seite des Backup-Servers:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Die Ergebnisse sind wie folgt:
Die Ausführungszeit betrug 10m11s. Wahrscheinlich ist der Flaschenhals der einseitige Kompressor auf der Empfängerseite.
Dasselbe Kommando, aber mit Verlagerung der Kompression auf den Server mit den Quelldaten, um die Hypothese zu überprüfen, dass der Flaschenhals der einseitige Kompressor ist.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Entstanden ist folgendes:
Die Ausführungszeit betrug 9m37s. Deutlich ist die Auslastung eines Kerns durch den Kompressor, da die Übertragungsgeschwindigkeit im Netzwerk und die Belastung des Datenträgersystems der Quelle ähnlich sind.
Für die Bewertung der Verschlüsselung kann openssl oder gpg verwendet werden, wobei ein zusätzlicher Befehl openssl oder gpg in der Pipe angeschlossen wird. Zur Orientierung wäre dieser Befehl:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Die Ergebnisse waren folgende:
Die Ausführungszeit betrug 10m30s, da 2 Prozesse auf der Empfängerseite gestartet wurden – der Flaschenhals ist wieder der einseitige Kompressor, plus einige geringe Overheadkosten für die Verschlüsselung.
UPD: Auf Wunsch von bliznezz füge ich Tests mit pigz hinzu. Wenn nur der Kompressor verwendet wird, betrug die Zeit 6m30s; wenn auch die Verschlüsselung hinzugefügt wird, etwa 7m. Der Einbruch im unteren Diagramm ist der nicht zurückgesetzte Festplattencache:
Testen von duplicity
Duplicity — eine Python-Software zur Datensicherung, die verschlüsselte Archive im tar-Format erstellt.
Für inkrementelle Archive wird librsync verwendet, daher kann man mit dem in .
Backups können mit gnupg verschlüsselt und signiert werden, was besonders wichtig ist, wenn verschiedene Anbieter für die Speicherung von Backups (s3, backblaze, gdrive usw.) verwendet werden.
Sehen wir uns die Ergebnisse an:
Das sind die Ergebnisse beim Start ohne Verschlüsselung.
Spoiler
Die Laufzeit jedes Testdurchlaufs:
Start 1
Start 2
Start 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Und hier sind die Ergebnisse bei aktivierter gnupg-Verschlüsselung mit einer Schlüssellänge von 2048 Bit:
Benötigte Zeit mit denselben Daten und Verschlüsselung:
Start 1
Start 2
Start 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Die Blockgröße wurde auf 512 Megabyte festgelegt, was auf den Diagrammen deutlich zu erkennen ist; die CPU-Auslastung lag tatsächlich bei etwa 50%, was bedeutet, dass das Programm nur einen Prozessor-Kern nutzt.
Der Arbeitsprinzip der Software ist ebenfalls gut nachvollziehbar: Ein Datenstück wird genommen, komprimiert und dann auf einen Backup-Server geschickt, der relativ langsam sein kann.
Ein weiteres Merkmal ist die vorhersehbare Betriebszeit der Anwendung, die nur von der Größe der geänderten Daten abhängt.
Die Aktivierung der Verschlüsselung hat die Laufzeit der Anwendung nicht wesentlich erhöht, jedoch die CPU-Auslastung um etwa 10% gesteigert, was ein durchaus brauchbarer Vorteil sein kann.
Leider konnte die Software die Situation mit der Umbenennung des Verzeichnisses nicht korrekt erkennen, wodurch die resultierende Größe des Repositories der Größe der Änderungen entsprach (d.h. insgesamt 18 GB). Dennoch überwiegt die Möglichkeit, einen nicht vertrauenswürdigen Server für Backups zu verwenden, eindeutig dieses Verhalten.
Test von Duplicati
Diese Software ist in C# geschrieben und läuft unter Verwendung eines Mono-Bibliothekssatzes. Sie bietet sowohl eine GUI- als auch eine CLI-Version an.
Eine exemplarische Liste der Hauptfunktionen ist ähnlich wie bei Duplicity und umfasst verschiedene Anbieter für die Datensicherung. Im Gegensatz zu Duplicity sind jedoch die meisten Funktionen ohne zusätzliche Tools verfügbar. Ob das als Vorteil oder Nachteil zu werten ist, hängt vom Einzelfall ab. Für Anfänger kann es jedoch einfacher sein, eine Übersicht aller Funktionen zu haben, als zusätzliche Python-Pakete wie bei Duplicity installieren zu müssen.
Ein weiterer kleiner Punkt ist, dass das Programm aktiv eine lokale SQLite-Datenbank im Namen des Benutzers schreibt, der die Sicherung startet. Daher muss darauf geachtet werden, dass bei jedem Start des Prozesses die richtige Datenbank über die CLI angegeben wird. Bei der Verwendung von GUI oder WEBGUI sind die Details für den Benutzer verborgen.
Schauen wir uns an, welche Werte diese Lösung liefern kann:
Wenn die Verschlüsselung deaktiviert wird (was von WEBGUI nicht empfohlen wird), sind die Ergebnisse wie folgt:
Laufzeit:
Start 1
Start 2
Start 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Mit aktivierter Verschlüsselung, unter Verwendung von AES, ergibt sich Folgendes:
Laufzeit:
Start 1
Start 2
Start 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Wenn eine externe Software wie GnuPG verwendet wird, ergeben sich folgende Ergebnisse:
Start 1
Start 2
Start 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Wie zu sehen ist, kann das Programm in mehreren Threads arbeiten, doch das macht es nicht unbedingt zu einer leistungsstärkeren Lösung. Im Vergleich zur Verschlüsselungsarbeit — dem Start einer externen Anwendung.
war es schneller als die Verwendung der Library aus dem Mono-Paket. Dies könnte daran liegen, dass die externe Anwendung besser optimiert ist.
Ein angenehmer Aspekt war auch, dass die Größe des Repositories genau der Menge der tatsächlich geänderten Daten entspricht, d.h. duplicati hat die Umbenennung des Verzeichnisses erkannt und die Situation korrekt verarbeitet. Dies ist bei der Durchführung des zweiten Tests sichtbar.
Insgesamt ist der Eindruck vom Programm durchweg positiv, einschließlich einer ausreichenden Benutzerfreundlichkeit für Anfänger.
Ergebnisse
Beide Kandidaten haben relativ langsam gearbeitet, aber insgesamt gibt es im Vergleich zu einem normalen tar Fortschritte, zumindest bei duplicati. Der Preis für diesen Fortschritt ist ebenfalls klar — eine spürbare CPU-Belastung.
Insgesamt gab es keine besonders auffälligen Abweichungen bei der Prognose der Ergebnisse.
Fazit
Wenn es nicht eilig ist und auch genügend CPU-Ressourcen vorhanden sind, kann jede der betrachteten Lösungen eingesetzt werden. In jedem Fall wurde jedoch bereits eine erhebliche Arbeit geleistet, die nicht durch das Schreiben von Wrapper-Skripten über tar wiederholt werden sollte. Die Verfügbarkeit von Verschlüsselung ist eine sehr nützliche Eigenschaft, insbesondere wenn der Server für die Speicherung von Sicherungskopien nicht vollständig vertrauenswürdig ist.
Wenn man es mit Lösungen auf Basis von vergleicht, kann die Leistung um ein Vielfaches schlechter sein, obwohl reines tar 20–30 % schneller als rsync gearbeitet hat.
Es gibt Einsparungen bei der Größe des Repositoriums, aber nur bei duplicati.
Ankündigung
Backup, Teil 3: Überblick und Test von duplicity, duplicati, deja dup
Backup, Teil 4: Überblick und Test von zbackup, restic, borgbackup
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
