Dieser Hinweis wird fortgesetzt
Zyklus über Backup
- Backup Teil 2: Überprüfung und Test von Rsync-basierten Backup-Tools
- Backup Teil 3: Überprüfung und Test von Duplizität, Duplizität, Déjà-Dup
- Backup Teil 4: Überprüfen und Testen von zbackup, restic, borgbackup
- Backup Teil 5: Testen von Bacula- und Veeam-Backups für Linux
- Backup Teil 6: Vergleich von Backup-Tools
- Backup Teil 7: Schlussfolgerungen
Wie wir bereits im ersten Artikel geschrieben haben, gibt es eine sehr große Anzahl von Backup-Programmen, die auf rsync basieren.
Von denen, die am besten zu unseren Bedingungen passen, werde ich drei in Betracht ziehen: rdiff-backup, rsnapshot und burp.
Dateisätze testen
Die Testdateisätze werden für alle Kandidaten, einschließlich zukünftiger Artikel, gleich sein.
Erstes Set: 10 GB Mediendateien und etwa 50 MB – der Quellcode der Website in PHP, Dateigrößen von mehreren Kilobyte für den Quellcode bis zu mehreren zehn Megabyte für Mediendateien. Ziel ist es, eine statische Site zu imitieren.
Zweiter Satz: Wird vom ersten erhalten, wenn ein Unterverzeichnis mit 5 GB Mediendateien umbenannt wird. Ziel ist es, das Verhalten des Backup-Systems beim Umbenennen eines Verzeichnisses zu untersuchen.
Dritter Satz: Wird vom ersten erhalten, indem 3 GB Mediendateien gelöscht und neue 3 GB Mediendateien hinzugefügt werden. Ziel ist es, das Verhalten des Backup-Systems während eines typischen Site-Update-Vorgangs zu untersuchen.
Ergebnisse erzielen
Jede Sicherung wird mindestens dreimal durchgeführt und geht mit dem Zurücksetzen der Dateisystem-Caches mit den Befehlen einher sync и echo 3 > /proc/sys/vm/drop_caches sowohl auf der Seite des Testservers als auch auf der Seite des Backup-Speicherservers.
Auf dem Server, der die Quelle der Sicherungen sein soll, ist eine Überwachungssoftware installiert – netdata, mit deren Hilfe die Auslastung des Servers während des Kopiervorgangs abgeschätzt wird. Dies ist notwendig, um die Auslastung des Servers während des Sicherungsvorgangs einzuschätzen.
Ich glaube auch, dass der Backup-Speicherserver in Bezug auf den Prozessor langsamer ist als der Hauptserver, aber über größere Festplatten mit einer relativ niedrigen zufälligen Schreibgeschwindigkeit verfügt – die häufigste Situation bei Backups und aufgrund der Tatsache, dass der Backup-Server dies nicht tun sollte Wenn ich es richtig mache, verfolge ich keine anderen Aufgaben außer der Sicherung, deren Auslastung mithilfe von NetData erfolgt.
Ich habe auch die Server geändert, auf denen ich verschiedene Systeme auf Backup prüfen werde.
Jetzt haben sie die folgenden EigenschaftenProzessor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 2
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1081.62
General statistics:
total time: 30.0013s
total number of events: 32453
Latency (ms):
min: 1.48
avg: 1.85
max: 9.84
95th percentile: 2.07
sum: 59973.40
Threads fairness:
events (avg/stddev): 16226.5000/57.50
execution time (avg/stddev): 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 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: read
scope: global
Initializing worker threads...
Threads started!
Total operations: 104857600 (5837637.63 per second)
102400.00 MiB transferred (5700.82 MiB/sec)
General statistics:
total time: 17.9540s
total number of events: 104857600
Latency (ms):
min: 0.00
avg: 0.00
max: 66.08
95th percentile: 0.00
sum: 18544.64
Threads fairness:
events (avg/stddev): 26214400.0000/0.00
execution time (avg/stddev): 4.6362/0.12
...und Aufnahme
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 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads...
Threads started!
Total operations: 91414596 (3046752.56 per second)
89272.07 MiB transferred (2975.34 MiB/sec)
General statistics:
total time: 30.0019s
total number of events: 91414596
Latency (ms):
min: 0.00
avg: 0.00
max: 1022.90
95th percentile: 0.00
sum: 66430.91
Threads fairness:
events (avg/stddev): 22853649.0000/945488.53
execution time (avg/stddev): 16.6077/1.76
Datenträger auf dem Datenquellenserver
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...
Threads started!
File operations:
reads/s: 4587.95
writes/s: 3058.66
fsyncs/s: 9795.73
Throughput:
read, MiB/s: 17.92
written, MiB/s: 11.95
General statistics:
total time: 60.0241s
total number of events: 1046492
Latency (ms):
min: 0.00
avg: 0.23
max: 14.45
95th percentile: 0.94
sum: 238629.34
Threads fairness:
events (avg/stddev): 261623.0000/1849.14
execution time (avg/stddev): 59.6573/0.00
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 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...
Threads started!
File operations:
reads/s: 11.37
writes/s: 7.58
fsyncs/s: 29.99
Throughput:
read, MiB/s: 0.04
written, MiB/s: 0.03
General statistics:
total time: 73.8868s
total number of events: 3104
Latency (ms):
min: 0.00
avg: 78.57
max: 3840.90
95th percentile: 297.92
sum: 243886.02
Threads fairness:
events (avg/stddev): 776.0000/133.26
execution time (avg/stddev): 60.9715/1.59
Netzwerkgeschwindigkeit zwischen Servern
iperf3 -c backup
Connecting to host backup, port 5201
[ 4] local x.x.x.x port 59402 connected to y.y.y.y port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes
[ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes
[ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes
[ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes
[ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes
[ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes
[ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes
[ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes
[ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes
[ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 sender
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec receiver
Testmethodik
- Auf dem Testserver wird ein Dateisystem mit dem ersten Testsatz vorbereitet und auf dem Backup-Speicherserver wird bei Bedarf das Repository initialisiert.
Der Backup-Prozess wird gestartet und seine Zeit gemessen. - Auf dem Testserver werden Dateien in den zweiten Testsatz migriert. Der Backup-Prozess wird gestartet und seine Zeit gemessen.
- Auf dem Testserver erfolgt die Migration bis zum dritten Testsatz. Der Backup-Prozess wird gestartet und seine Zeit gemessen.
- Der resultierende dritte Testsatz wird als neuer erster akzeptiert; Die Schritte 1-3 werden noch 2 Mal wiederholt.
- Die Daten werden in eine Pivot-Tabelle eingegeben und Diagramme mit Nettodaten hinzugefügt.
- Für die einzelne Sicherungsmethode wird ein Bericht generiert.
Erwartete Ergebnisse
Da alle drei Kandidaten auf der gleichen Technologie (rsync) basieren, ist zu erwarten, dass die Ergebnisse dem regulären rsync nahekommen, einschließlich aller seiner Vorteile, nämlich:
- Dateien im Repository werden „wie sie sind“ gespeichert.
- Die Repository-Größe wächst nur einschließlich der Differenz zwischen Backups.
- Bei der Datenübertragung kommt es zu einer relativ hohen Belastung des Netzwerks und zu einer geringen Belastung des Prozessors.
Als Referenz und Ergebnisse wird ein Testlauf von regulärem rsync verwendet
diese sind
Der Flaschenhals befand sich auf dem Backup-Datenspeicherserver in Form einer HDD-basierten Festplatte, was in den Sägezahndiagrammen recht deutlich sichtbar ist.
Die Daten wurden in 4 Minuten und 15 Sekunden kopiert.
Testen von rdiff-backup
Der erste Kandidat ist rdiff-backup, ein Python-Skript, das ein Verzeichnis in einem anderen sichert. In diesem Fall wird die aktuelle Sicherungskopie „wie sie ist“ gespeichert und zuvor erstellte Sicherungskopien werden inkrementell in einem speziellen Unterverzeichnis gespeichert und sparen so Platz.
Wir prüfen die typische Betriebsart, d.h. Der Start des Backup-Prozesses wird vom Client selbst initiiert, und auf der Serverseite wird zur Sicherung ein Prozess gestartet, der Daten empfängt.
Werfen wir einen Blick darauf, Wozu ist er unter unseren Bedingungen fähig?.
Laufzeit jedes Testlaufs:
Первый запуск
Zweiter Lauf
Dritter Start
Erstes Set
16m32s
16m26s
16m19s
Zweiter Satz
2h5m
2h10m
2h8m
Dritter Satz
2h9m
2h10m
2h10m
Rdiff-Backup reagiert sehr schmerzhaft auf große Datenänderungen und nutzt das Netzwerk nicht vollständig aus.
rsnapshot-Testen
Der zweite Kandidat, rsnapshot, ist ein Perl-Skript, dessen Hauptvoraussetzung für einen effektiven Betrieb die Unterstützung von Hardlinks ist. Dies spart Speicherplatz. In diesem Fall werden Dateien, die sich seit der letzten Sicherung nicht geändert haben, über Hardlinks mit der Originaldatei verknüpft.
Auch die Logik des Backup-Prozesses wird umgekehrt: Der Server „wandert“ aktiv zwischen seinen Clients und nimmt Daten entgegen.
Testergebnisse
Folgendes stellte sich heraus
Первый запуск
Zweiter Lauf
Dritter Start
Erstes Set
4m22s
4m19s
4m16s
Zweiter Satz
2m6s
2m10s
2m6s
Dritter Satz
1m18s
1m10s
1m10s
Es funktionierte sehr, sehr schnell, viel schneller als rdiff-backup und kam dem reinen Rsync sehr nahe.
Rülpstest
Eine weitere Option ist eine C-Implementierung auf librsync – burp, die über eine Client-Server-Architektur inklusive Client-Autorisierung sowie ein Webinterface verfügt (nicht im Basispaket enthalten). Ein weiteres interessantes Feature sind clientseitige Non-Recovery-Backups.
Schauen wir uns anпроизводительность.
Первый запуск
Zweiter Lauf
Dritter Start
Erstes Set
11m21s
11m10s
10m56s
Zweiter Satz
5m37s
5m40s
5m35s
Dritter Satz
3m33s
3m24s
3m40s
Es funktionierte zweimal langsamer als rsnapshot, aber immer noch ziemlich schnell und sicherlich schneller als rdiff-backup. Die Diagramme sind etwas sägezahnförmig – die Leistung hängt wiederum vom Festplattensubsystem des Backup-Speicherservers ab, obwohl dies nicht so ausgeprägt ist wie bei rsnapshot.
Ergebnisse
Die Größe der Repositories war bei allen Kandidaten ungefähr gleich, d. h. zuerst auf 10 GB, dann auf 15 GB, dann auf 18 GB usw., was auf die Besonderheit von rsync zurückzuführen ist. Erwähnenswert ist auch, dass alle Kandidaten Single-Threaded sind (die Prozessorauslastung beträgt etwa 50 % auf einem Dual-Core-Rechner). Alle drei Kandidaten boten die Möglichkeit, die letzte Sicherung „wie sie ist“ wiederherzustellen, d. Dies ist auch das „Erbe der Vorfahren“ von rsync.
Befund
Je komplexer das Backup-System und je mehr unterschiedliche Fähigkeiten es hat, desto langsamer wird es arbeiten, aber für nicht sehr anspruchsvolle Projekte wird jedes davon geeignet sein, außer vielleicht rdiff-backup.
Ankündigung
Dieser Hinweis setzt den Zyklus zum Thema Backup fort
Backup Teil 2: Überprüfen und Testen von Rsync-basierten Backup-Tools
Backup Teil 3: Überprüfung und Test von Duplizität, Duplizität, Déjà-Dup
Backup Teil 4: Überprüfen und Testen von zbackup, restic, borgbackup
Backup Teil 5: Testen von Bacula- und Veeam-Backups für Linux
Backup Teil 6: Vergleich von Backup-Tools
Backup Teil 7: Schlussfolgerungen
Autoren: Pavel Demkovich
Source: habr.com
