Mit diesem Artikel wird
der Zyklus über Datensicherung fortgesetzt
- Datensicherung, Teil 2: Überblick und Tests von rsync-basierten Datensicherungstools
- Datensicherung, Teil 3: Überblick und Tests von duplicity, duplicaty, 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
Wie bereits im ersten Artikel erwähnt, gibt es eine sehr große Anzahl von Datensicherungsprogrammen, die auf rsync basieren.
Von denjenigen, die am besten zu unseren Anforderungen passen, werde ich 3 betrachten: rdiff-backup, rsnapshot und burp.
Testdateisätze
Die Testdateisätze werden für alle Kandidaten gleich sein, einschließlich zukünftiger Artikel.
Erster Satz: 10 GB Mediendateien und etwa 50 MB — Quellcode der Website in PHP, die Dateigrößen reichen von mehreren Kilobyte für den Quellcode bis zu mehreren Dutzend Megabyte für Mediendateien. Ziel — Simulation einer statischen Website.
Zweiter Satz: entsteht aus dem ersten durch Umbenennung des Unterverzeichnisses mit Mediendateien von 5 GB. Ziel — Untersuchung des Verhaltens des Datensicherungssystems bei der Umbenennung eines Verzeichnisses.
Dritter Satz: entsteht aus dem ersten, indem 3 GB Mediendateien entfernt und 3 GB neue Mediendateien hinzugefügt werden. Ziel — Untersuchung des Verhaltens des Datensicherungssystems bei typischen Aktualisierungen der Website.
Ergebnisse erhalten
Jede Datensicherung wird mindestens 3 Mal durchgeführt und begleitet von Cache-Löschbefehlen für das Dateisystem sync und echo 3 > /proc/sys/vm/drop_caches sowohl auf der Seite des Testservers als auch des Backup-Servers.
Auf dem Server, der die Sicherungen erstellt, ist eine Überwachungssoftware — netdata — installiert, mit der die Serverauslastung während des Kopierens bewertet wird. Dies ist notwendig, um die Serverlast während des Datensicherungsvorgangs zu beurteilen.
Ich gehe auch davon aus, dass der Backup-Server eine schwächere CPU als der Hauptserver hat, aber über größere Festplatten mit relativ niedrigerer zufälliger Schreibgeschwindigkeit verfügt — dies ist die häufigste Situation bei der Datensicherung. Da der Backup-Server idealerweise keine anderen Aufgaben außer der Datensicherung ausführen sollte, werde ich seine Last mit netdata nicht überwachen.
Auch meine Server haben sich geändert, auf denen ich verschiedene Systeme zur Datensicherung überprüfen werde.
Derzeit haben sie folgende EigenschaftenProzessor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (verwendet system LuaJIT 2.0.4)
Durchführung des Tests mit folgenden Optionen:
Anzahl der Threads: 2
Zufallszahlengenerator wird von der aktuellen Zeit initialisiert
Grenze für Primzahlen: 20000
Initialisierung der Arbeiter-Threads...
Threads gestartet!
CPU-Geschwindigkeit:
Ereignisse pro Sekunde: 1081.62
Allgemeine Statistiken:
Gesamtzeit: 30.0013s
Gesamtanzahl 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 (avg/stddev): 16226.5000/57.50
Ausführungszeit (avg/stddev): 29.9867/0.00
Arbeitsspeicher, 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 (verwendet system LuaJIT 2.0.4)
Durchführung des Tests mit folgenden Optionen:
Anzahl der Threads: 4
Zufallszahlengenerator wird von der aktuellen Zeit initialisiert
Durchführung des Speichertests mit folgenden Optionen:
Blockgröße: 1KiB
Gesamtgröß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:
Gesamtzeit: 17.9540s
Gesamtanzahl der Ereignisse: 104857600
Latenz (ms):
min: 0.00
avg: 0.00
max: 66.08
95. Perzentile: 0.00
Summe: 18544.64
Fairness der Threads:
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)
Durchführung des Tests mit folgenden Optionen:
Anzahl der Threads: 4
Zufallszahlengenerator wird von der aktuellen Zeit initialisiert
Durchführung des Speichertests mit folgenden Optionen:
Blockgröße: 1KiB
Gesamtgröße: 102400MiB
Operation: schreiben
Umfang: global
Initialisierung der Arbeiter-Threads...
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. Perzentile: 0.00
Summe: 66430.91
Fairness der Threads:
Ereignisse (avg/stddev): 22853649.0000/945488.53
Ausführungszeit (avg/stddev): 16.6077/1.76
Festplatte auf dem Quellserver
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio ausführen
sysbench 1.0.17 (unter Verwendung von system LuaJIT 2.0.4)
Test wird mit folgenden Optionen ausgeführt:
Anzahl der Threads: 4
Zufallszahlen-Generator wird von der aktuellen Zeit initialisiert
Zusätzliche Datei-Öffnungsflags: (keine)
128 Dateien, jeweils 8MiB
1GiB Gesamtdateigröße
Blockgröße 4KiB
Anzahl der IO-Anforderungen: 0
Read/Write-Verhältnis für kombinierte zufällige IO-Test: 1.50
Periodisches FSYNC aktiviert, fsync() wird alle 100 Anforderungen aufgerufen.
fsync() am Ende des Tests aufrufen, aktiviert.
Verwendung des synchronen I/O-Modus
Zufälligen r/w-Test durchführen
Arbeiter-Threads werden initialisiert...
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:
Gesamtzeit: 60.0241s
Gesamtanzahl der Ereignisse: 1046492
Latenz (ms):
min: 0.00
avg: 0.23
max: 14.45
95. Perzentil: 0.94
sum: 238629.34
Fairness der Threads:
Ereignisse (avg/stddev): 261623.0000/1849.14
Ausführungszeit (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 ausführen
sysbench 1.0.17 (unter Verwendung von system LuaJIT 2.0.4)
Test wird mit folgenden Optionen ausgeführt:
Anzahl der Threads: 4
Zufallszahlen-Generator wird von der aktuellen Zeit initialisiert
Zusätzliche Datei-Öffnungsflags: (keine)
128 Dateien, jeweils 8MiB
1GiB Gesamtdateigröße
Blockgröße 4KiB
Anzahl der IO-Anforderungen: 0
Read/Write-Verhältnis für kombinierte zufällige IO-Test: 1.50
Periodisches FSYNC aktiviert, fsync() wird alle 100 Anforderungen aufgerufen.
fsync() am Ende des Tests aufrufen, aktiviert.
Verwendung des synchronen I/O-Modus
Zufälligen r/w-Test durchführen
Arbeiter-Threads werden initialisiert...
Threads gestartet!
Dateioperationen:
reads/s: 11.37
writes/s: 7.58
fsyncs/s: 29.99
Durchsatz:
read, 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
sum: 243886.02
Fairness der Threads:
Ereignisse (avg/stddev): 776.0000/133.26
Ausführungszeit (avg/stddev): 60.9715/1.59
Netzwerkgeschwindigkeit zwischen den Servern
iperf3 -c backup
Verbindung zum Host backup, Port 5201
[ 4] Lokale 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 MBytes 3.52 Gbits/sec 810 182 KBytes
[ 4] 1.00-2.00 Sek 393 MBytes 3.30 Gbits/sec 810 228 KBytes
[ 4] 2.00-3.00 Sek 378 MBytes 3.17 Gbits/sec 810 197 KBytes
[ 4] 3.00-4.00 Sek 380 MBytes 3.19 Gbits/sec 855 198 KBytes
[ 4] 4.00-5.00 Sek 375 MBytes 3.15 Gbits/sec 810 182 KBytes
[ 4] 5.00-6.00 Sek 379 MBytes 3.17 Gbits/sec 765 228 KBytes
[ 4] 6.00-7.00 Sek 376 MBytes 3.15 Gbits/sec 810 180 KBytes
[ 4] 7.00-8.00 Sek 379 MBytes 3.18 Gbits/sec 765 253 KBytes
[ 4] 8.00-9.00 Sek 380 MBytes 3.19 Gbits/sec 810 239 KBytes
[ 4] 9.00-10.00 Sek 411 MBytes 3.44 Gbits/sec 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervall Übertragung Bandbreite Retr
[ 4] 0.00-10.00 Sek 3.78 GBytes 3.25 Gbits/sec 8100 Sender
[ 4] 0.00-10.00 Sek 3.78 GBytes 3.25 Gbits/sec Empfänger
Testmethodik
- Auf dem Testserver wird das Dateisystem mit dem ersten Testsatz vorbereitet, und auf dem Backup-Server wird bei Bedarf das Repository initialisiert.
Der Backup-Prozess wird gestartet und dessen Zeit gemessen. - Auf dem Testserver werden die Dateien bis zum zweiten Testsatz migriert. Der Backup-Prozess wird gestartet und dessen Zeit gemessen.
- Auf dem Testserver erfolgt die Migration bis zum dritten Testsatz. Der Backup-Prozess wird gestartet und dessen Zeit gemessen.
- Der erhaltene dritte Testsatz wird als neuer erster akzeptiert; Punkte 1-3 werden zweimal wiederholt.
- Die Daten werden in eine Übersichtstabelle eingetragen, und es werden Grafiken mit netdata hinzugefügt.
- Ein Bericht zu einer bestimmten Backup-Methode wird erstellt.
Erwartete Ergebnisse
Da alle 3 Kandidaten auf derselben Technologie (rsync) basieren, wird erwartet, dass die Ergebnisse den gewöhnlichen rsync ähnlich sind, einschließlich all seiner Vorteile, nämlich:
- Dateien im Repository werden 'wie sie sind' gespeichert.
- Die Größe des Repositories wird nur durch die Unterschiede zwischen den Backups wachsen.
- Es wird eine vergleichsweise hohe Netzwerklast bei der Datenübertragung geben, sowie eine geringe Prozessorlast.
Der Testlauf des gewöhnlichen rsync wird als Referenz dienen, dessen Ergebnisse
sind wie folgt
Der Engpass befand sich auf dem Backup-Server in Form einer HDD-basierten Festplatte, was auf den Grafiken deutlich als Zickzack 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 Backup eines Verzeichnisses in ein anderes erstellt. Dabei wird das aktuelle Backup "so wie es ist" gespeichert, und frühere Backups werden inkrementell in einem speziellen Unterverzeichnis abgelegt, wodurch Platz gespart wird.
Wir werden den typischen Betriebsmodus überprüfen, d.h. der Backup-Prozess wird vom Client selbst initiiert, und auf der Serverseite wird ein Prozess gestartet, der die Daten annimmt.
Lassen Sie uns einen Blick darauf werfen, was es unter unseren Bedingungen leisten kann..
Die Laufzeit jeder Testausführung:
Erster Start
Zweiter Lauf
Dritter Lauf
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.
Test von rsnapshot
Der zweite Kandidat ist rsnapshot, ein Perl-Skript, dessen Hauptanforderung für eine effektive Arbeit die Unterstützung von harten Links ist. Dadurch wird Platz auf der Festplatte gespart. Dateien, die sich seit dem letzten Backup nicht geändert haben, verweisen über harte Links auf die Originaldatei.
Außerdem wurde die Logik des Backup-Prozesses umgekehrt: Der Server „geht“ aktiv zu seinen Clients und holt sich die Daten.
Testergebnisse
Es ergaben sich folgende
Erster Start
Zweiter Lauf
Dritter Lauf
Erster Satz
4m22s
4m19s
4m16s
Zweiter Satz
2m6s
2m10s
2m6s
Dritter Satz
1m18s
1m10s
1m10s
Er arbeitete sehr schnell, viel schneller als rdiff-backup und sehr nah am reinen rsync.
Test von burp
Eine weitere Option ist die Implementierung in C über librsync - burp, das eine Client-Server-Architektur mit Client-Authentifizierung sowie einem Web-Interface (nicht in der Grundausstattung enthalten) hat. Eine weitere interessante Eigenschaft ist das Backup ohne Wiederherstellungsrecht für die Clients.
Lassen Sie uns einen Blick aufdie Leistung.
Erster Start
Zweiter Lauf
Dritter Lauf
Erster Satz
11m21s
11m10s
10m56s
Zweiter Satz
5m37s
5m40s
5m35s
Dritter Satz
3m33s
3m24s
3m40s
Es arbeitete doppelt so langsam wie rsnapshot, jedoch auch schnell und definitiv schneller als rdiff-backup. Die Grafiken sind etwas gezackt – die Leistung wird ebenfalls durch das Speichersystem des Backup-Servers begrenzt, 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 Anstieg auf 10 GB, dann auf 15 GB, dann auf 18 GB usw., was mit der Arbeitsweise von rsync zusammenhängt. Es ist auch zu beachten, dass alle Kandidaten eine Einstrangigkeit aufwiesen (CPU-Auslastung etwa 50 % bei einem Dual-Core-Rechner). Alle drei Kandidaten boten die Möglichkeit, das letzte Backup "wie es ist" wiederherzustellen, das heißt, man konnte Dateien ohne Verwendung jeglicher Drittanbieter-Software wiederherstellen, einschließlich derjenigen, die zur Erstellung der Repositories verwendet wurden. Dies ist ebenfalls das "Erbe" von rsync.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Je komplexer das Backup-System ist und je mehr Möglichkeiten es hat, desto langsamer wird es arbeiten, aber für nicht allzu anspruchsvolle Projekte eignet sich jede von ihnen, außer möglicherweise rdiff-backup.
Ankündigung
Diese Notiz setzt die Reihe über das Backup fort.
Sicherung, Teil 2: Überblick und Test von rsync-basierten Sicherungswerkzeugen
Datensicherung, Teil 3: Überblick und Tests von duplicity, duplicaty, 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: Pawel Demkowitsch
Quelle: habr.com
