In diesem Artikel werden Backup-Tools betrachtet, die Sicherungen durch die Erstellung von Archiven auf einem Backup-Server durchführen.
Diejenigen, die die Anforderungen erfüllen, sind duplicity (für den es eine benutzerfreundliche Oberfläche in Form von deja dup gibt) und duplicati.
Ein weiteres bemerkenswertes Backup-Tool ist dar, aber da es eine sehr umfangreiche Liste von Optionen hat – die Testmethodik deckt wahrscheinlich kaum 10 % dessen ab, wozu es fähig ist – wird es im aktuellen Zyklus nicht getestet.
Erwartete Ergebnisse
Da beide Kandidaten auf die eine oder andere Weise Archive erstellen, kann als Referenz ein normales tar verwendet werden.
Zusätzlich bewerten wir, wie gut die Datenspeicherung auf dem Speicherserver optimiert wird, indem Backup-Kopien erstellt werden, die nur die Unterschiede zwischen dem vollständigen Backup und dem aktuellen Zustand der Dateien oder zwischen den früheren und aktuellen Archiven (inkrementell, dekremental etc.) enthalten.
Verhalten bei der Erstellung von Backups:
- Eine vergleichsweise geringe Anzahl von Dateien auf dem Backup-Speicher (verglichen mit der Anzahl der Backups oder der Datengröße in GB), aber eine ziemlich große Größe (Dutzende bis Hunderte von Megabyte).
- Die Größe des Repositories umfasst nur Änderungen – Duplikate werden nicht gespeichert, sodass die Größe des Repositories kleiner ist als bei Software, die auf rsync basiert.
- Es wird eine hohe CPU-Auslastung bei der Verwendung von Kompression und/oder Verschlüsselung erwartet, und wahrscheinlich auch eine erhebliche Belastung des Netzwerks und der Datenspeichersysteme, wenn der Archivierungs- und/oder Verschlüsselungsprozess auf dem Backup-Speicherserver läuft.
Als Referenzwert führen wir den folgenden Befehl aus:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Die Ergebnisse der Ausführung waren folgende:
Die Ausführungszeit betrug 3m12s. Es ist zu erkennen, dass die Geschwindigkeit an das Datenspeichersystem des Backup-Servers gebunden ist, wie im Beispiel mit . Nur etwas schneller, da die Daten in einer Datei geschrieben werden.
Um die Kompression zu bewerten, führen wir dasselbe Beispiel aus, aber aktivieren 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 einsträngige Kompressor auf der Empfangsseite.
Das gleiche Team, aber mit Kompressionstransfer auf den Server mit den Quelldaten, um die Hypothese zu prüfen, dass der Engpass der einsträngige Kompressor ist.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Es ergab sich folgendes:
Die Ausführungszeit betrug 9m37s. Es ist deutlich zu erkennen, dass ein Kern vom Kompressor ausgelastet ist, da die Netzwerkgeschwindigkeit und die Belastung des Datenträgersystems ähnlich sind.
Für die Bewertung der Verschlüsselung kann openssl oder gpg verwendet werden, indem ein zusätzlicher Befehl hinzugefügt wird openssl oder gpg im Pipe. Zur Orientierung könnte folgender Befehl verwendet werden:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Die Ergebnisse sind folgende:
Die Ausführungszeit betrug 10m30s, da 2 Prozesse auf der Empfangsseite gestartet wurden – der Engpass ist erneut der einsträngige Kompressor, zusätzlich gibt es geringe Overheads bei der Verschlüsselung.
UPD: Auf Wunsch von bliznezz füge ich Tests mit pigz hinzu. Wenn nur der Kompressor verwendet wird, ergab sich eine Zeit von 6m30s, wenn auch die Verschlüsselung hinzugefügt wird – etwa 7m. Der Rückgang im unteren Diagramm ist der nicht zurückgesetzte Festplattencache:
Testen von duplicity
Duplicity ist eine Software auf Python-Basis zur Erstellung von Backups durch Verschlüsselung von Tar-Archiven.
Für inkrementelle Archive wird librsync verwendet, daher kann man ein Verhalten erwarten, das 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.
Lassen Sie uns sehen, welche Ergebnisse erzielt wurden:
Das sind die Ergebnisse ohne Verschlüsselung:
Spoiler
Die Laufzeit jeder Testausführung:
Ausführung 1
Ausführung 2
Ausführung 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Dies sind die Ergebnisse mit aktivierter gnupg-Verschlüsselung, mit einer Schlüssellänge von 2048 Bit:
Die Laufzeit mit denselben Daten, jedoch mit Verschlüsselung:
Ausführung 1
Ausführung 2
Ausführung 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Die Blockgröße wurde auf 512 Megabyte eingestellt, was deutlich auf den Grafiken zu sehen ist; die CPU-Auslastung lag tatsächlich bei etwa 50 %, was bedeutet, dass das Programm nicht mehr als einen Prozessoren-Kern nutzt.
Man sieht auch gut, wie das Programm funktioniert: Es nimmt einen Datensatz, komprimiert ihn und sendet ihn auf den Backup-Speicherserver, der möglicherweise relativ langsam sein kann.
Eine weitere Besonderheit ist die vorhersehbare Laufzeit des Programms, die nur von der Größe der geänderten Daten abhängt.
Die Aktivierung der Verschlüsselung hat die Programmlaufzeit nicht besonders verlängert, jedoch die CPU-Auslastung um etwa 10 % erhöht, was durchaus ein netter zusätzlicher Vorteil sein kann.
Leider konnte dieses Programm die Situation mit der Umbenennung des Verzeichnisses nicht korrekt erkennen, und die resultierende Repository-Größe entsprach der Größe der Änderungen (d.h. alle 18 GB), aber die Möglichkeit, einen nicht vertrauenswürdigen Server für die Sicherung zu verwenden, überwiegt eindeutig dieses Verhalten.
Testen von duplicati
Diese Software ist in C# geschrieben und läuft unter Verwendung von Bibliotheken von Mono. Es gibt eine GUI sowie eine CLI-Version.
Die Liste der Hauptfunktionen ist ähnlich wie bei duplicity, einschließlich verschiedener Anbieter für die Speicherung von Sicherungskopien. Im Gegensatz zu duplicity stehen jedoch die meisten Funktionen ohne Drittanbietertools zur Verfügung. Ob dies ein Plus oder Minus ist, hängt vom Einzelfall ab, jedoch ist es für Anfänger wahrscheinlich einfacher, eine vollständige Listung aller Funktionen zu sehen, anstatt Pakete für Python wie bei duplicity nachträglich zu installieren.
Ein weiterer kleiner Hinweis: Das Programm schreibt aktiv eine lokale SQLite-Datenbank im Namen des Benutzers, der die Sicherung startet, daher muss man bei jedem Start des Prozesses über die CLI zusätzlich darauf achten, die richtige Datenbank anzugeben. Bei der Verwendung von GUI oder WEBGUI werden die Details für den Benutzer verborgen.
Schauen wir uns an, welche Leistungskennzahlen diese Lösung liefern kann:
Wenn man die Verschlüsselung deaktiviert (obwohl das WEBGUI davon abrät), sind die Ergebnisse:
Die Laufzeit:
Ausführung 1
Ausführung 2
Ausführung 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Mit aktivierter Verschlüsselung unter Verwendung von AES ergeben sich folgende Zeiten:
Die Laufzeit:
Ausführung 1
Ausführung 2
Ausführung 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Wenn man das externe Programm GnuPG verwendet, sind die Ergebnisse:
Ausführung 1
Ausführung 2
Ausführung 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Wie man sieht, kann das Programm in mehreren Threads arbeiten, aber das macht es nicht zu einer leistungsfähigeren Lösung, und beim Vergleich der Verschlüsselungsleistung — der Start des externen Programms
war schneller als die Verwendung der Bibliothek aus dem Mono-Set. Möglicherweise liegt das daran, dass das externe Programm besser optimiert ist.
Ein angenehmer Aspekt war auch die Tatsache, dass die Größe des Repositories genau so viel beträgt, wie tatsächlich geänderte Daten vorhanden sind, d.h. duplicati hat die Umbenennung des Verzeichnisses erkannt und die Situation korrekt behandelt. Dies kann beim Durchlauf des zweiten Tests gesehen werden.
Insgesamt bin ich mit dem Programm recht positiv eingestellt, einschließlich einer ausreichenden Freundlichkeit für Anfänger.
Ergebnisse
Beide Kandidaten haben relativ gemächlich gearbeitet, aber insgesamt gibt es im Vergleich zum üblichen tar Fortschritte, zumindest bei duplicati. Der Preis dieses Fortschritts ist ebenfalls klar – eine spürbare Belastung
des Prozessors. Insgesamt gibt es keine wesentlichen Abweichungen bei der Prognose der Ergebnisse.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Wenn es nicht eilig ist und wenn zusätzliche Kapazität des Prozessors vorhanden ist, kann jede der betrachteten Lösungen verwendet werden; immerhin wurde eine ziemlich große Arbeit geleistet, die nicht wiederholt werden sollte, indem Skripte über tar geschrieben werden. Vorhandensein von Verschlüsselung ist eine sehr nützliche Eigenschaft, wenn der Server für die Speicherung von Backups nicht voll vertrauenswürdig ist.
Wenn man es mit Lösungen vergleicht, die auf basiert, kann die Leistung trotz der Tatsache, dass reines tar 20-30 % schneller als rsync war, um ein Vielfaches schlechter sein.
Es gibt eine Einsparung bei der Größe des Repositories, aber nur bei duplicati.
Ankündigung
Backup, Teil 3: Überblick und Test von duplicity, duplicati, deja dup
Sicherung, Teil 4: Überblick und Test von zbackup, restic, borgbackup
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
