Dieser Artikel wird fortgesetzt
Sicherungszyklus- Backup, Teil 1: Warum benötigen Sie ein Backup, einen Überblick über Methoden und Technologien?
- Backup, Teil 2: Übersicht und Testen des rsync-basierten Backup-Tools
- Backup, Teil 3: Übersicht und Testen der Duplizität, Duplikate
- Backup, Teil 4: Übersicht und Testen von zbackup, restic, borgbackup
- Backup, Teil 5: Testen von Bacula und Veeam Backup für Linux
- Backup, Teil 6: Vergleichen der Backup-Tools
- Backup Teil 7: Schlussfolgerungen
Wie wir bereits im ersten Artikel geschrieben haben, gibt es eine sehr große Anzahl von Sicherungsprogrammen, die auf rsync basieren.
Von denen, die für unsere Bedingungen am besten geeignet sind, werde ich 3 betrachten: rdiff-backup, rsnapshot und rülpsen.
Dateisätze testen
Die Testdateisätze sind für alle Kandidaten gleich, einschließlich zukünftiger Artikel.Der erste Satz : 10 GB Mediendateien und etwa 50 MB - der Quellcode für die Site in PHP, Dateigrößen von einigen Kilobyte für den Quellcode bis zu zehn Megabyte für Mediendateien. Ziel ist es, eine Site mit Statik zu simulieren.
Der zweite Satz : Wird vom ersten beim Umbenennen eines Unterverzeichnisses mit 5-GB-Mediendateien erhalten. Ziel ist es, das Verhalten des Sicherungssystems beim Umbenennen eines Verzeichnisses zu untersuchen.
Dritter Satz : Erhalten Sie vom ersten
Satz, indem Sie 3 GB Mediendateien löschen und neue 3 GB Mediendateien hinzufügen. Ziel ist es, das Verhalten des Sicherungssystems während eines typischen Site-Update-Vorgangs zu untersuchen.
Ergebnisse erhalten
Jede Sicherung wird mindestens dreimal durchgeführt und von einem Zurücksetzen der Dateisystem-Caches mit den
echo 3 > /proc/sys/vm/drop_caches sync und
echo 3 > /proc/sys/vm/drop_caches sowohl auf dem
echo 3 > /proc/sys/vm/drop_caches auf dem Sicherungsspeicherserver begleitet.
Auf dem Server, der die Quelle der Sicherungen sein wird, ist eine Überwachungssoftware installiert - netdata, mit der die Auslastung des Servers während der Sicherung geschätzt wird. Dies ist erforderlich, um die Auslastung des Servers durch den Sicherungsprozess zu bewerten.
Ich denke auch, dass der Backup-Speicherserver langsamer als der Hauptserver ist, aber über größere Festplatten mit einer relativ geringen zufälligen Schreibgeschwindigkeit verfügt - die häufigste Situation beim Sichern und aufgrund der Tatsache, dass der Backup-Server nichts Gutes tun sollte Ich werde keine andere Last als die Sicherung überwachen, ich werde die Last nicht mit netdata überwachen.
Außerdem haben sich meine Server geändert, auf denen ich verschiedene Systeme auf Sicherung überprüfen werde.
Jetzt haben sie die folgenden EigenschaftenCPU 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
Festplatte 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 Sicherungsspeicherserver 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 xxxx port 59402 connected to yyyy 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
Testmethode
- Auf dem Testserver wird ein Dateisystem mit dem ersten Testsatz vorbereitet und das Repository bei Bedarf auf dem Sicherungsspeicherserver initialisiert.
Der Sicherungsprozess beginnt und seine Zeit wird gemessen. - Dateien werden in die zweite Testsuite auf dem Testserver migriert. Der Sicherungsprozess beginnt und seine Zeit wird gemessen.
- Der Testserver wird auf die dritte Testsuite migriert. Der Sicherungsprozess beginnt und seine Zeit wird gemessen.
- Der resultierende dritte Testsatz wird vom neuen ersten akzeptiert; Die Punkte 1-3 werden noch zweimal wiederholt.
- Daten werden in die Pivot-Tabelle eingegeben, Diagramme mit Netzdaten werden hinzugefügt.
- Ein Bericht wird mit einer separaten Sicherungsmethode erstellt.
Erwartete Ergebnisse
Da alle drei Kandidaten auf derselben Technologie (rsync) basieren, wird erwartet, dass die Ergebnisse nahe an der üblichen rsync liegen, einschließlich aller ihrer Vorteile, nämlich:
- Dateien im Repository werden "wie sie sind" gespeichert.
- Die Größe des Repositorys wächst nur einschließlich des Unterschieds zwischen Sicherungen.
- Das Netzwerk wird beim Übertragen von Daten relativ stark belastet, und der Prozessor wird nur geringfügig belastet.
Der Testlauf eines regulären Rsync wird als Referenz für seine Ergebnisse verwendet
das sind
Der Engpass lag auf dem Backup-Speicherserver in Form einer HDD-basierten Festplatte, die in Form einer Säge in den Grafiken 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. Gleichzeitig wird die aktuelle Sicherungskopie "wie sie ist" gespeichert, und die zuvor erstellten Sicherungen werden schrittweise in einem speziellen Unterverzeichnis gespeichert, wodurch Speicherplatz gespart wird.
Wir werden den typischen Betriebsmodus überprüfen, d.h. Der Start des Sicherungsprozesses wird vom Client selbst initiiert, und auf der Serverseite wird der Prozess, der Daten empfängt, zur Sicherung gestartet.
Mal sehen
Was kann er unter unseren Bedingungen?.
Die Laufzeit jedes Testlaufs:
Rdiff-backup reagiert sehr schmerzhaft auf große Datenänderungen und nutzt das Netzwerk auch nicht vollständig aus.
Rsnapshot testen
Der zweite Kandidat, rsnapshot, ist ein Perl-Skript, dessen Hauptanforderung für eine effektive Arbeit die Unterstützung von Hardlinks ist. Dies spart Speicherplatz. Gleichzeitig werden Dateien, die sich seit der vorherigen Sicherung nicht geändert haben, über feste Links auf die Originaldatei verwiesen.
Die Logik des Sicherungsprozesses ist ebenfalls umgekehrt: Der Server „läuft“ aktiv auf seinen Clients selbst und nimmt Daten auf.
Testergebnisse
Es funktionierte sehr, sehr schnell, viel schneller als rdiff-backup und sehr nahe an reinem rsync.
Rülpsen testen
Eine weitere Option ist die C-Implementierung über librsync - burp mit einer Client-Server-Architektur einschließlich Client-Autorisierung sowie einer Webschnittstelle (nicht im Basispaket enthalten). Ein weiteres interessantes Feature ist das Backup ohne das Recht auf Wiederherstellung von Clients.
Schauen wir uns das an
Leistung.
Es funktionierte 2 mal langsamer als rsnapshot, aber auch ziemlich schnell und sicherlich schneller rdiff-backup. Die Grafiken sind ein bisschen sägezahnförmig - die Leistung liegt wieder auf dem Festplattensubsystem des Backup-Speicherservers, obwohl dies nicht so ausgeprägt ist wie bei rsnapshot.
Ergebnisse
Die Größe der Repositories für alle Kandidaten war ungefähr gleich, dh zuerst Wachstum bis zu 10 GB, dann Wachstum bis zu 15 GB, dann Wachstum bis zu 18 GB usw., was mit der Besonderheit von rsync verbunden ist. Es ist auch erwähnenswert, dass alle Kandidaten Single-Threaded sind (die CPU-Auslastung beträgt bei einem Dual-Core-Computer etwa 50%). Alle drei Kandidaten boten die Möglichkeit, die letzte Sicherung "wie sie ist" wiederherzustellen, dh es war möglich, Dateien ohne Verwendung von Programmen von Drittanbietern wiederherzustellen, einschließlich solcher, die zum Erstellen von Repositorys verwendet wurden. Dies ist auch das „generische Erbe“ von rsync.
Schlussfolgerungen
Je komplexer das Backup-System und je vielfältiger die Funktionen sind, desto langsamer funktioniert es. Bei nicht sehr anspruchsvollen Projekten kann jedoch eines von ihnen ausgeführt werden, außer möglicherweise rdiff-backup.
Ankündigung
Dieser Hinweis setzt den Sicherungszyklus fort.
Backup, Teil 1: Warum benötigen Sie ein Backup, einen Überblick über Methoden und Technologien?Backup, Teil 2: Übersicht und Testen von rsync-basierten Backup-ToolsBackup, Teil 3: Übersicht und Testen der Duplizität, DuplikateBackup, Teil 4: Übersicht und Testen von zbackup, restic, borgbackupBackup, Teil 5: Testen von Bacula und Veeam Backup für LinuxBackup: Teil von Lesern angefordert: AMANDA Review, UrBackup, BackupPCBackup, Teil 6: Vergleichen der Backup-ToolsBackup Teil 7: SchlussfolgerungenGepostet von Finnix