Dit artikel gaat verder
met de reeks over back-ups
- Back-up, deel 2: Overzicht en testen van rsync-gebaseerde back-upoplossingen
- Back-up, deel 3: Overzicht en testen van duplicity, duplicaty, deja dup
- Back-up, deel 4: Overzicht en testen van zbackup, restic, borgbackup
- Back-up, deel 5: Testen van bacula en veeam backup voor linux
- Back-up, deel 6: Vergelijking van back-upoplossingen
- Back-up, deel 7: Conclusies
Zoals we in het eerste artikel hebben geschreven, zijn er veel back-upprogramma's op basis van rsync.
Van degenen die het meest geschikt zijn voor onze behoeften, zal ik 3 bespreken: rdiff-backup, rsnapshot en burp.
Testbestanden
De testbestanden zullen identiek zijn voor alle kandidaten, inclusief toekomstige artikelen.
Eerste set: 10 GB aan mediabestanden en ongeveer 50 MB ā de broncode van de website in php, met bestandsgroottes van enkele kilobytes voor de broncode tot tientallen megabytes voor mediabestanden. Het doel is het simuleren van een statische website.
Tweede set: komt voort uit de eerste door de submap met mediabestanden van 5 GB te hernoemen. Het doel is om het gedrag van het back-upsysteem bij het hernoemen van de map te bestuderen.
Derde set: komt voort uit de eerste door 3 GB aan mediabestanden te verwijderen en 3 GB nieuwe mediabestanden toe te voegen. Het doel is om het gedrag van het back-upsysteem bij een typische website-update te onderzoeken.
Verkrijgen van resultaten
Elke back-up wordt minimaal 3 keer uitgevoerd en gaat gepaard met het legen van de cache van het bestandssysteem met de commando's sync en echo 3 > /proc/sys/vm/drop_caches zowel aan de kant van de testserver als de server voor het opslaan van back-ups.
Op de server die de backups zal creĆ«ren, is monitoringsoftware geĆÆnstalleerd ā netdata, waarmee de belasting van de server tijdens het kopiĆ«ren kan worden beoordeeld. Dit is nodig om de belasting van de server door het back-upproces te evalueren.
Ik denk ook dat de server voor het opslaan van back-ups trager is qua processor dan de hoofdserver, maar grotere schijven heeft met relatief lage willekeurige schrijfsnelheden ā de meest voorkomende situatie bij back-ups. Omdat de back-upserver eigenlijk geen andere taken dan back-ups zou moeten uitvoeren, zal ik zijn belasting met netdata niet volgen.
Ook zijn de servers waarop ik verschillende back-upsystemen zal testen veranderd.
Hun huidige specificaties zijnProcessor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
De test wordt uitgevoerd met de volgende opties:
Aantal threads: 2
Initialiseren van de willekeurige getallengenerator met de huidige tijd
Limiet voor priemgetallen: 20000
Initialiseren van werkthreads...
Threads gestart!
CPU-snelheid:
gebeurtenissen per seconde: 1081.62
Algemene statistieken:
totale tijd: 30.0013s
totaal aantal gebeurtenissen: 32453
Latency (ms):
min: 1.48
avg: 1.85
max: 9.84
95e percentiel: 2.07
som: 59973.40
Eerlijkheid van threads:
gebeurtenissen (avg/stddev): 16226.5000/57.50
uitvoeringstijd (avg/stddev): 29.9867/0.00
Geheugen, lezenā¦
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)
De test wordt uitgevoerd met de volgende opties:
Aantal threads: 4
Initialiseren van de willekeurige getallengenerator met de huidige tijd
Uitvoeren van de geheugensnelheidstest met de volgende opties:
blokgrootte: 1KiB
totale grootte: 102400MiB
operatie: lezen
reikwijdte: globaal
Initialiseren van werkthreads...
Threads gestart!
Totaal aantal bewerkingen: 104857600 (5837637.63 per seconde)
102400.00 MiB overgedragen (5700.82 MiB/sec)
Algemene statistieken:
totale tijd: 17.9540s
totaal aantal gebeurtenissen: 104857600
Latency (ms):
min: 0.00
avg: 0.00
max: 66.08
95e percentiel: 0.00
som: 18544.64
Eerlijkheid van threads:
gebeurtenissen (avg/stddev): 26214400.0000/0.00
uitvoeringstijd (avg/stddev): 4.6362/0.12
ā¦ en schrijven
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)
De test wordt uitgevoerd met de volgende opties:
Aantal threads: 4
Initialiseren van de willekeurige getallengenerator met de huidige tijd
Uitvoeren van de geheugensnelheidstest met de volgende opties:
blokgrootte: 1KiB
totale grootte: 102400MiB
operatie: schrijven
reikwijdte: globaal
Initialiseren van werkthreads...
Threads gestart!
Totaal aantal bewerkingen: 91414596 (3046752.56 per seconde)
89272.07 MiB overgedragen (2975.34 MiB/sec)
Algemene statistieken:
totale tijd: 30.0019s
totaal aantal gebeurtenissen: 91414596
Latency (ms):
min: 0.00
avg: 0.00
max: 1022.90
95e percentiel: 0.00
som: 66430.91
Eerlijkheid van threads:
gebeurtenissen (avg/stddev): 22853649.0000/945488.53
uitvoeringstijd (avg/stddev): 16.6077/1.76
Schijf op de gegevensbronserver
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)
Test wordt uitgevoerd met de volgende opties:
Aantal threads: 4
Initialiseren van de random number generator op basis van de huidige tijd
Extra bestandsopeningsvlaggen: (geen)
128 bestanden, 8MiB elk
1GiB totale bestandsgrootte
Blokgrootte 4KiB
Aantal IO-verzoeken: 0
Lees-/schrijfratio voor gecombineerde random IO-test: 1.50
Periodieke FSYNC ingeschakeld, aanroep van fsync() elke 100 verzoeken.
Aanroep van fsync() aan het einde van de test, ingeschakeld.
Gebruik van synchrone I/O-modus
Uitvoeren van random r/w-test
Worker threads initialiseren...
Threads gestart!
Bestandsbewerkingen:
leest/s: 4587.95
schrijft/s: 3058.66
fsyncs/s: 9795.73
Doorvoercapaciteit:
lezen, MiB/s: 17.92
geschreven, MiB/s: 11.95
Algemene statistieken:
totale tijd: 60.0241s
totaal aantal evenementen: 1046492
Latency (ms):
min: 0.00
avg: 0.23
max: 14.45
95e percentiel: 0.94
som: 238629.34
Thread-gelijkheid:
evenementen (gem./stddev): 261623.0000/1849.14
uitvoeringstijd (gem./stddev): 59.6573/0.00
Schijf op de backup-server
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)
Test wordt uitgevoerd met de volgende opties:
Aantal threads: 4
Initialiseren van de random number generator op basis van de huidige tijd
Extra bestandsopeningsvlaggen: (geen)
128 bestanden, 8MiB elk
1GiB totale bestandsgrootte
Blokgrootte 4KiB
Aantal IO-verzoeken: 0
Lees-/schrijfratio voor gecombineerde random IO-test: 1.50
Periodieke FSYNC ingeschakeld, aanroep van fsync() elke 100 verzoeken.
Aanroep van fsync() aan het einde van de test, ingeschakeld.
Gebruik van synchrone I/O-modus
Uitvoeren van random r/w-test
Worker threads initialiseren...
Threads gestart!
Bestandsbewerkingen:
leest/s: 11.37
schrijft/s: 7.58
fsyncs/s: 29.99
Doorvoercapaciteit:
lezen, MiB/s: 0.04
geschreven, MiB/s: 0.03
Algemene statistieken:
totale tijd: 73.8868s
totaal aantal evenementen: 3104
Latency (ms):
min: 0.00
avg: 78.57
max: 3840.90
95e percentiel: 297.92
som: 243886.02
Thread-gelijkheid:
evenementen (gem./stddev): 776.0000/133.26
uitvoeringstijd (gem./stddev): 60.9715/1.59
Netwerksnelheid tussen servers
iperf3 -c backup
Verbinden met host backup, poort 5201
[ 4] lokaal x.x.x.x poort 59402 verbonden met y.y.y.y poort 5201
[ ID] Interval Overdracht Bandbreedte 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 Overdracht Bandbreedte Retr
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 zender
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec ontvanger
Testmethodologie
- Op de testserver wordt het bestandssysteem voorbereid met de eerste testset, en op de back-upserver wordt, indien nodig, het repository geĆÆnitialiseerd.
Het back-upproces wordt gestart en de tijd wordt gemeten. - Op de testserver worden bestanden gemigreerd naar de tweede testset. Het back-upproces wordt gestart en de tijd wordt gemeten.
- Op de testserver wordt gemigreerd naar de derde testset. Het back-upproces wordt gestart en de tijd wordt gemeten.
- De verkregen derde testset wordt de nieuwe eerste; punten 1-3 worden nog 2 keer herhaald.
- Gegevens worden ingevoerd in een samenvattende tabel, grafieken worden toegevoegd met netdata.
- Er wordt een rapport opgesteld over de afzonderlijke back-upmethode.
Verwachte resultaten
Aangezien alle 3 kandidaten op dezelfde technologie zijn gebaseerd (rsync), wordt verwacht dat de resultaten dicht bij de gewone rsync liggen, inclusief al zijn voordelen, namelijk:
- Bestanden in het repository worden 'zoals ze zijn' opgeslagen.
- De grootte van het repository zal alleen groeien door het opnemen van de verschillen tussen de back-ups.
- Er zal relatief grote belasting op het netwerk zijn bij het verzenden van gegevens, evenals een kleine belasting op de processor.
De testuitvoering van de gewone rsync zal als referentie worden gebruikt, zijn resultaten
zijn als volgt
De bottleneck was op de back-upserver in de vorm van een HDD-gebaseerde schijf, wat duidelijk zichtbaar is in de grafieken in de vorm van een zaag.
Gegevens zijn gekopieerd in 4 minuten en 15 seconden.
rdiff-backup testen
De eerste kandidaat is rdiff-backup, een script in Python dat een back-up van de ene directory naar de andere maakt. Hierbij wordt de huidige back-up "zoals deze is" opgeslagen, terwijl eerdere back-ups incrementeel in een speciale subdirectory worden opgeslagen, waardoor ruimte wordt bespaard.
We zullen de typische werking controleren, dat wil zeggen, het starten van het back-upproces wordt door de client zelf geĆÆnitieerd, en aan de serverzijde wordt een proces gestart dat de gegevens ontvangt.
Laten we eens kijken, wat het kan doen in onze omstandigheden.
De uitvoeringstijd van elke testuitvoering:
Eerste start
Tweede start
Derde start
Eerste set
16m32s
16m26s
16m19s
Tweede set
2h5m
2h10m
2h8m
Derde set
2h9m
2h10m
2h10m
Rdiff-backup reageert zeer scherp op elke grote wijziging in gegevens en benut het netwerk niet volledig.
Testen van rsnapshot
De tweede kandidaat is rsnapshot, een script in Perl, waarvan de belangrijkste vereiste voor een effectieve werking de ondersteuning van harde links is. Hierdoor wordt ruimte op de schijf bespaard. Bestanden die sinds de vorige back-up niet zijn gewijzigd, verwijzen naar het originele bestand met behulp van harde links.
Daarnaast is de logica van het back-upproces omgekeerd: de server gaat actief naar zijn clients toe en haalt gegevens op.
Testresultaten
het volgende resulteerde
Eerste start
Tweede start
Derde start
Eerste set
4m22s
4m19s
4m16s
Tweede set
2m6s
2m10s
2m6s
Derde set
1m18s
1m10s
1m10s
Het werkte vrij snel, veel sneller dan rdiff-backup en zeer dichtbij een schone rsync.
Testen van burp
Een andere variant is de implementatie in C bovenop librsync - burp, dat een client-serverarchitectuur heeft inclusief clientautorisatie, evenals de aanwezigheid van een webinterface (niet inbegrepen in de basislevering). Een andere interessante eigenschap is back-up zonder herstelrecht voor clients.
Laten we eens kijken naarde prestaties.
Eerste start
Tweede start
Derde start
Eerste set
11m21s
11m10s
10m56s
Tweede set
5m37s
5m40s
5m35s
Derde set
3m33s
3m24s
3m40s
Het werkte twee keer zo langzaam als rsnapshot, maar toch vrij snel, en zeker sneller dan rdiff-backup. De grafieken zijn een beetje zaagtandachtig - de prestaties stoten opnieuw tegen het opslagdisc-systeem van de back-upserver, hoewel dit niet zo sterk is als bij rsnapshot.
Resultaten
De grootte van de repositories bij alle kandidaten was ongeveer hetzelfde, namelijk eerst groei tot 10 GB, daarna groei tot 15 GB, vervolgens groei tot 18 GB, enzovoort, wat verband houdt met de aard van het werken met rsync. Het is ook vermeldenswaard dat alle kandidaten enkelvoudig werkend zijn (de belasting voor de CPU is ongeveer 50% op een dual-core machine). Alle 3 kandidaten boden de mogelijkheid om de laatste back-up 'zoals het is' te herstellen, wat betekent dat bestanden konden worden hersteld zonder het gebruik van enige externe programma's, inclusief die welke zijn gebruikt voor het maken van de repositories. Dit is ook een 'familiaal erfgoed' van rsync.
Conclusies
Hoe ingewikkelder het back-upsysteem en hoe meer mogelijkheden het heeft, hoe langzamer het zal werken, maar voor niet al te veeleisende projecten is elke optie geschikt, behalve misschien rdiff-backup.
Aankondiging
Deze nota vervolgt de cyclus over back-ups
Back-up, deel 2: Overzicht en testen van rsync-gebaseerde back-upoplossingen
Back-up, deel 3: Overzicht en testen van duplicity, duplicaty, deja dup
Back-up, deel 4: Overzicht en testen van zbackup, restic, borgbackup
Back-up, deel 5: Testen van bacula en veeam backup voor linux
Back-up, deel 6: Vergelijking van back-upoplossingen
Back-up, deel 7: Conclusies
Auteur van de publicatie: Pavel Demkovich
Bron: habr.com
