In diesem Beitrag wird
die Reihe über Backup-Lösungen fortgesetzt
- Backup, Teil 2: Überblick und Testen von rsync-basierten Backup-Methoden
- Backup, Teil 3: Überblick und Test von duplicity, duplicaty, 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
Wie bereits im ersten Artikel erwähnt, gibt es eine Vielzahl von Backup-Programmen, die auf rsync basieren.
Von den Optionen, die am besten zu unseren Anforderungen passen, werde ich drei betrachten: rdiff-backup, rsnapshot und burp.
Testdateisätze
Die Testdateisätze werden für alle Kandidaten identisch sein, einschließlich zukünftiger Artikel.
Erster Satz: 10 GB Mediendateien und etwa 50 MB — Quellcode der Webseite in PHP, mit Dateigrößen von wenigen Kilobyte für den Quellcode bis hin zu mehreren Megabyte für die Mediendateien. Ziel ist die Simulation einer statischen Webseite.
Zweiter Satz: entsteht aus dem ersten durch Umbenennung eines Unterordners mit Mediendateien von 5 GB. Ziel ist es, das Verhalten des Backup-Systems beim Umbenennen eines Verzeichnisses zu untersuchen.
Dritter Satz: entsteht aus dem ersten, indem 3 GB Mediendateien gelöscht und 3 GB neue Mediendateien hinzugefügt werden. Ziel ist die Analyse des Verhaltens des Backup-Systems bei einer typischen Aktualisierungsoperation der Website.
Ergebnisse erhalten
Jede Sicherung wird mindestens dreimal durchgeführt und begleitet von den Befehlen zum Leeren des Dateisystem-Caches. sync und echo 3 > /proc/sys/vm/drop_caches sowohl auf dem Testserver als auch auf dem Backup-Speicherserver.
Auf dem Server, der die Backups erstellt, ist Monitoring-Software installiert – netdata, mit deren Hilfe die Serverlast während des Kopierens bewertet wird. Dies ist notwendig, um die Belastung des Servers durch den Backup-Prozess zu beurteilen.
Ich denke auch, dass der Backup-Speicherserver einen schwächeren Prozessor hat als der Hauptserver, aber über größere Festplatten mit relativ niedrigerer zufälliger Schreibgeschwindigkeit verfügt – was beim Backup sehr häufig vorkommt. Da der Backup-Server idealerweise keine anderen Aufgaben als das Backup durchführen sollte, werde ich seine Belastung mit netdata nicht überwachen.
Ich habe auch die Server geändert, auf denen ich verschiedene Systeme zur Datensicherung testen werde.
Sie haben jetzt folgende Eigenschaften.Prozessor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (unter Verwendung von system LuaJIT 2.0.4)
Test wird mit folgenden Optionen ausgeführt:
Anzahl der Threads: 2
Zufallszahlengenerator von der aktuellen Zeit initialisieren
Grenze der Primzahlen: 20000
Arbeiter-Threads werden initialisiert...
Threads gestartet!
CPU-Geschwindigkeit:
Ereignisse pro Sekunde: 1081.62
Allgemeine Statistiken:
Gesamtdauer: 30.0013s
Gesamtzahl der Ereignisse: 32453
Latenz (ms):
min: 1.48
avg: 1.85
max: 9.84
95. Perzentile: 2.07
Summe: 59973.40
Fairness der Threads:
Ereignisse (Durchschnitt/Streuung): 16226.5000/57.50
Ausführungszeit (Durchschnitt/Streuung): 29.9867/0.00
RAM, Lesen…
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.0.17 (mit system LuaJIT 2.0.4)
Führen Sie den Test mit folgenden Optionen durch:
Anzahl der Threads: 4
Zufallszahlengenerator wird von der aktuellen Zeit initialisiert
Durchführen des Speichertests mit folgenden Optionen:
Blockgröße: 1KiB
Gesamte Größe: 102400MiB
Operation: lesen
Umfang: global
Initialisierung der Arbeiter-Threads...
Threads gestartet!
Gesamtoperationen: 104857600 (5837637.63 pro Sekunde)
102400.00 MiB übertragen (5700.82 MiB/sec)
Allgemeine Statistiken:
Gesamte Zeit: 17.9540s
Gesamtzahl der Ereignisse: 104857600
Latenz (ms):
min: 0.00
avg: 0.00
max: 66.08
95. Perzentil: 0.00
Summe: 18544.64
Threads Fairness:
Ereignisse (avg/stddev): 26214400.0000/0.00
Ausführungszeit (avg/stddev): 4.6362/0.12
… und Schreiben
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.0.17 (verwendet system LuaJIT 2.0.4)
Test wird mit den folgenden Optionen durchgeführt:
Anzahl der Threads: 4
Zufallszahlengenerator wird von der aktuellen Zeit initialisiert
Speichergeschwindigkeitstest wird mit den folgenden Optionen durchgeführt:
Blockgröße: 1KiB
Gesamte Größe: 102400MiB
Operation: Schreiben
Bereich: global
Arbeiter-Threads werden initialisiert...
Threads gestartet!
Gesamtoperationen: 91414596 (3046752,56 pro Sekunde)
89272,07 MiB übertragen (2975,34 MiB/sec)
Allgemeine Statistiken:
Gesamtzeit: 30,0019s
Gesamtanzahl der Ereignisse: 91414596
Latenz (ms):
min: 0,00
avg: 0,00
max: 1022,90
95. Perzentil: 0,00
Summe: 66430,91
Fairness der Threads:
Ereignisse (avg/stddev): 22853649,0000/945488,53
Ausführungszeit (avg/stddev): 16,6077/1,76
Die Festplatte auf dem Server der Datenquelle
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (unter Verwendung von system LuaJIT 2.0.4)
Test wird mit folgenden Optionen ausgeführt:
Anzahl der Threads: 4
Initialisierung des Zufallszahlengenerators aus der aktuellen Zeit
Zusätzliche Dateiöffnungsflags: (keine)
128 Dateien, jeweils 8MiB
1GiB Gesamtdateigröße
Blockgröße 4KiB
Anzahl der IO-Anfragen: 0
Lese-/Schreibverhältnis für kombinierte zufällige IO-Tests: 1,50
Periodisches FSYNC aktiviert, fsync() wird alle 100 Anfragen aufgerufen.
fsync() am Ende des Tests aufrufen, aktiviert.
Verwendung des synchronen I/O-Modus
Durchführung eines zufälligen r/w-Tests
Initialisierung der Arbeits-Threads...
Threads gestartet!
Dateioperationen:
reads/s: 4587,95
writes/s: 3058,66
fsyncs/s: 9795,73
Durchsatz:
read, MiB/s: 17,92
geschrieben, MiB/s: 11,95
Allgemeine Statistiken:
gesamte Zeit: 60,0241s
Gesamtanzahl der Ereignisse: 1046492
Latenz (ms):
min: 0,00
avg: 0,23
max: 14,45
95. Perzentil: 0,94
Summe: 238629,34
Thread-Gerechtigkeit:
Ereignisse (avg/stddev): 261623,0000/1849,14
Ausführungszeit (avg/stddev): 59,6573/0,00
Die Festplatte auf dem Backup-Speicherserver
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (unter Verwendung des System LuaJIT 2.0.4)
Test wird mit folgenden Optionen ausgeführt:
Anzahl der Threads: 4
Zufallszahlengenerator wird von der aktuellen Zeit initialisiert
Zusätzliche Dateiöffnungsflags: (keine)
128 Dateien, jeweils 8MiB
1GiB Gesamtdatengröße
Blockgröße 4KiB
Anzahl der IO-Anfragen: 0
Lese-/Schreibverhältnis für kombinierten zufälligen IO-Test: 1,50
Periodisches FSYNC aktiviert, fsync() wird nach jeder 100. Anfrage aufgerufen.
fsync() am Ende des Tests aufrufen, aktiviert.
Verwendung des synchronen I/O-Modus
Durchführung des zufälligen Lese-/Schreibtests
Initialisierung der Arbeits-Threads...
Threads gestartet!
Dateioperationen:
liest/s: 11,37
schreibt/s: 7,58
fsyncs/s: 29,99
Durchsatz:
gelesen, MiB/s: 0,04
geschrieben, MiB/s: 0,03
Allgemeine Statistiken:
Gesamtzeit: 73,8868s
Gesamtanzahl der Ereignisse: 3104
Latenz (ms):
min: 0,00
avg: 78,57
max: 3840,90
95. Perzentil: 297,92
Summe: 243886,02
Fairness der Threads:
Ereignisse (Avg/Stddev): 776,0000/133,26
Ausführungszeit (Avg/Stddev): 60,9715/1,59
Die Netzgeschwindigkeit zwischen den Servern
iperf3 -c backup
Verbindung zu Host backup, Port 5201
[ 4] lokal x.x.x.x Port 59402 verbunden mit y.y.y.y Port 5201
[ ID] Intervall Übertragung Bandbreite Retr Cwnd
[ 4] 0.00-1.00 Sek 419 MByte 3.52 Gbit/Sek 810 182 KByte
[ 4] 1.00-2.00 Sek 393 MByte 3.30 Gbit/Sek 810 228 KByte
[ 4] 2.00-3.00 Sek 378 MByte 3.17 Gbit/Sek 810 197 KByte
[ 4] 3.00-4.00 Sek 380 MByte 3.19 Gbit/Sek 855 198 KByte
[ 4] 4.00-5.00 Sek 375 MByte 3.15 Gbit/Sek 810 182 KByte
[ 4] 5.00-6.00 Sek 379 MByte 3.17 Gbit/Sek 765 228 KByte
[ 4] 6.00-7.00 Sek 376 MByte 3.15 Gbit/Sek 810 180 KByte
[ 4] 7.00-8.00 Sek 379 MByte 3.18 Gbit/Sek 765 253 KByte
[ 4] 8.00-9.00 Sek 380 MByte 3.19 Gbit/Sek 810 239 KByte
[ 4] 9.00-10.00 Sek 411 MByte 3.44 Gbit/Sek 855 184 KByte
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervall Übertragung Bandbreite Retr
[ 4] 0.00-10.00 Sek 3.78 GByte 3.25 Gbit/Sek 8100 Sender
[ 4] 0.00-10.00 Sek 3.78 GByte 3.25 Gbit/Sek Empfänger
Testmethodik
- Auf dem Testserver wird das Dateisystem mit dem ersten Testdatensatz vorbereitet, wobei bei Bedarf im Backup-Server das Repository initialisiert wird.
Der Backup-Prozess wird gestartet und die Zeit wird gemessen. - Auf dem Testserver wird die Migration der Dateien zum zweiten Testdatensatz durchgeführt. Der Backup-Prozess wird gestartet und die Zeit wird gemessen.
- Auf dem Testserver wird die Migration auf den dritten Testdatensatz durchgeführt. Der Backup-Prozess wird gestartet und die Zeit dafür wird gemessen.
- Der erhaltene dritte Testdatensatz wird als neuer erster akzeptiert; die Punkte 1-3 werden zwei weitere Male wiederholt.
- Die Daten werden in eine Zusammenfassungstabelle übertragen, und es werden Diagramme mit netdata hinzugefügt.
- Ein Bericht über die jeweilige Backup-Methode wird erstellt.
Erwartete Ergebnisse
Da alle 3 Kandidaten auf derselben Technologie (rsync) basieren, wird erwartet, dass die Ergebnisse den typischen rsync-Ergebnissen ähnlich sind und alle seine Vorteile beinhalten, nämlich:
- Die Dateien im Repository werden „wie sie sind“ gespeichert.
- Die Größe des Repositories wird nur wachsen, indem die Differenz zwischen den Backups eingeschlossen wird.
- Es wird eine vergleichsweise hohe Netzwerklast bei der Datenübertragung sowie eine geringe CPU-Belastung erwartet.
Der Testdurchlauf des normalen rsync wird als Referenz verwendet, seine Ergebnisse
sind wie folgt
Die Engpasssituation bestand auf dem Backup-Datenspeicher in Form einer HDD-basierten Festplatte, was auf den Diagrammen im Sägezahnmuster deutlich zu erkennen ist.
Die Daten wurden in 4 Minuten und 15 Sekunden kopiert.
Test von rdiff-backup
Der erste Kandidat ist rdiff-backup, ein Python-Skript, das ein Verzeichnis in ein anderes sichert. Dabei wird das aktuelle Backup "so wie es ist" gespeichert, während frühere Backups inkrementell in einem speziellen Unterverzeichnis abgelegt werden, wodurch Speicherplatz gespart wird.
Wir werden den typischen Betriebsmodus überprüfen, d.h. der Backup-Prozess wird vom Kunden eigenständig initiiert, während auf Seiten des Servers ein Prozess gestartet wird, der die Daten für das Backup entgegennimmt.
Lassen Sie uns einen Blick darauf werfen, was es unter unseren Bedingungen leisten kann..
Die Laufzeit jedes Testdurchlaufs:
Erster Start
Zweiter Durchlauf
Dritter Durchlauf
Erster Satz
16m32s
16m26s
16m19s
Zweiter Satz
2h5m
2h10m
2h8m
Dritter Satz
2h9m
2h10m
2h10m
Rdiff-backup reagiert sehr empfindlich auf große Datenänderungen und nutzt auch das Netzwerk nicht vollständig aus.
Testen von rsnapshot
Der zweite Kandidat ist rsnapshot, ein Perl-Skript, dessen Hauptanforderung für eine effektive Nutzung die Unterstützung von harten Links ist. Auf diese Weise wird Speicherplatz auf der Festplatte gespart. Dateien, die sich seit dem letzten Backup nicht geändert haben, verlinken über harte Links auf die Originaldatei.
Die Logik des Backup-Prozesses wurde ebenfalls umgekehrt: Der Server „geht“ aktiv zu seinen Clients und holt die Daten selbständig ab.
Testergebnisse
Es ergaben sich folgende
Erster Start
Zweiter Durchlauf
Dritter Durchlauf
Erster Satz
4m22s
4m19s
4m16s
Zweiter Satz
2m6s
2m10s
2m6s
Dritter Satz
1m18s
1m10s
1m10s
Es arbeitete äußerst schnell, viel schneller als rdiff-backup und sehr nah an purem rsync.
Burp-Test
Eine weitere Möglichkeit ist die Implementierung in C auf der Basis von librsync – burp, das eine Client-Server-Architektur mit Kundenautorisierung sowie eine Web-Oberfläche bietet (nicht im Basisumfang enthalten). Eine weitere interessante Eigenschaft ist die Backup-Funktion ohne Wiederherstellungsrechte für die Clients.
Lassen Sie uns anschauenLeistung.
Erster Start
Zweiter Durchlauf
Dritter Durchlauf
Erster Satz
11m21s
11m10s
10m56s
Zweiter Satz
5m37s
5m40s
5m35s
Dritter Satz
3m33s
3m24s
3m40s
Es arbeitete zwei Mal langsamer als rsnapshot, allerdings auch ausreichend schnell und definitiv schneller als rdiff-backup. Die Grafiken sind leicht gezackt – die Leistung hängt erneut von der Speicherarchitektur des Backup-Servers ab, obwohl dies nicht so ausgeprägt ist wie bei rsnapshot.
Ergebnisse
Die Größe der Repositories aller Kandidaten war ungefähr gleich, d. h. zunächst ein Wachstum auf 10 GB, dann auf 15 GB, dann auf 18 GB usw., was mit der Funktionsweise von rsync zusammenhängt. Es ist auch erwähnenswert, dass alle Kandidaten im Einzel-Thread-Modus arbeiteten (CPU-Auslastung von etwa 50 % bei einem Dual-Core-System). Alle 3 Kandidaten boten die Möglichkeit, das letzte Backup "wie es ist" wiederherzustellen, das heißt, Dateien konnten ohne Verwendung externer Programme, einschließlich derjenigen, die zur Erstellung von Repositories verwendet wurden, wiederhergestellt werden. Das ist ebenfalls ein "Erbe" von rsync.
Fazit
Je komplexer das Backup-System ist und je mehr verschiedene Möglichkeiten es bietet, desto langsamer wird es arbeiten. Für weniger anspruchsvolle Projekte eignet sich jedoch jede von ihnen, mit Ausnahme von rdiff-backup.
Ankündigung
Dieser Artikel setzt die Reihe über Backups fort.
Backup, Teil 2: Überblick und Test von rsync-basierten Backup-Tools
Backup, Teil 3: Überblick und Test von duplicity, duplicaty, 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 des Beitrags: Pavel Demkovich
Quelle: habr.com
