Den här anteckningen fortsätter
cykeln om säkerhetskopiering
- Säkerhetskopiering, del 2: Översikt och testning av rsync-baserade säkerhetskopieringsverktyg
- Säkerhetskopiering, del 3: Översikt och test av duplicity, duplicaty, deja dup
- Backup, del 4: Översikt och test av zbackup, restic, borgbackup
- Backup, del 5: Test av bacula och veeam backup för linux
- Backup, del 6: Jämförelse av backupverktyg
- Backup, del 7: Slutsatser
Som vi redan nämnt i den första artikeln finns det ett stort antal säkerhetskopieringsprogram som är baserade på rsync.
Av de som passar våra behov bäst kommer jag att titta på 3: rdiff-backup, rsnapshot och burp.
Testfilgrupper
Testfilgrupperna kommer att vara desamma för alla kandidater, inklusive framtida artiklar.
Den första gruppen: 10 GB mediefiler och cirka 50 MB — källkoden till en webbplats i php, filstorlekar från några kilobyte för källkoden till tiotals megabyte för mediefiler. Målet är att simulera en statisk webbplats.
Den andra gruppen: får vi från den första genom att byta namn på underkatalogen med mediefiler som är 5 GB stora. Målet är att studera beteendet hos säkerhetskopieringssystemet vid namnbyte av katalog.
Den tredje gruppen: får vi från den första genom att ta bort 3 GB mediefiler och lägga till nya 3 GB mediefiler. Målet är att studera beteendet hos säkerhetskopieringssystemet vid en typisk uppdateringsoperation av webbplatsen.
Mottagande av resultat
Varje säkerhetskopiering görs minst 3 gånger och åtföljs av tömning av filsystemets cache med kommandona sync och echo 3 > /proc/sys/vm/drop_caches både på testservern och servern för säkerhetskopiering.
På servern som kommer att vara källa för säkerhetskopior är övervakningsprogrammet installerat — netdata, med vilket serverbelastningen under kopieringen kommer att utvärderas, det behövs för att bedöma serverbelastningen vid säkerhetskopieringsprocessen.
Jag anser också att servern för säkerhetskopiering är långsammare i processorn än huvudservern men har mer lagringsutrymme med relativt låg hastighet för slumpmässig skrivning — den vanligaste situationen vid säkerhetskopiering, och eftersom säkerhetskopieringsservern i grunden inte bör utföra andra uppgifter än säkerhetskopiering, kommer jag inte att övervaka dess belastning med hjälp av netdata.
Jag har också ändrat servrarna på vilka jag kommer att testa olika system för säkerhetskopiering.
De har nu följande specifikationerProcessor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Kör testet med följande alternativ:
Antal trådar: 2
Initierar slumptalsgenerator från nuvarande tid
Primtal gräns: 20000
Initierar arbetstrådar...
Trådar startade!
CPU-hastighet:
händelser per sekund: 1081.62
Generell statistik:
total tid: 30.0013s
totalt antal händelser: 32453
Latens (ms):
min: 1.48
genomsnitt: 1.85
max: 9.84
95:e percentilen: 2.07
summa: 59973.40
Rättvis fördelning av trådar:
händelser (genomsnitt/stdavvikelse): 16226.5000/57.50
exekveringstid (genomsnitt/stdavvikelse): 29.9867/0.00
RAM, läsning…
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)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från nuvarande tid
Kör minneshastighets test med följande alternativ:
blockstorlek: 1KiB
total storlek: 102400MiB
operation: läs
omfattning: global
Initierar arbetstrådar...
Trådar startade!
Totalt antal operationer: 104857600 (5837637.63 per sekund)
102400.00 MiB överförda (5700.82 MiB/sek)
Generell statistik:
total tid: 17.9540s
totalt antal händelser: 104857600
Latens (ms):
min: 0.00
genomsnitt: 0.00
max: 66.08
95:e percentilen: 0.00
summa: 18544.64
Rättvis fördelning av trådar:
händelser (genomsnitt/stdavvikelse): 26214400.0000/0.00
exekveringstid (genomsnitt/stdavvikelse): 4.6362/0.12
… och skrivning
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)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från nuvarande tid
Kör minneshastighets test med följande alternativ:
blockstorlek: 1KiB
total storlek: 102400MiB
operation: skriv
omfattning: global
Initierar arbetstrådar...
Trådar startade!
Totalt antal operationer: 91414596 (3046752.56 per sekund)
89272.07 MiB överförda (2975.34 MiB/sek)
Generell statistik:
total tid: 30.0019s
totalt antal händelser: 91414596
Latens (ms):
min: 0.00
genomsnitt: 0.00
max: 1022.90
95:e percentilen: 0.00
summa: 66430.91
Rättvis fördelning av trådar:
händelser (genomsnitt/stdavvikelse): 22853649.0000/945488.53
exekveringstid (genomsnitt/stdavvikelse): 16.6077/1.76
Disk på servern med datakällan
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (använder system LuaJIT 2.0.4)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från aktuell tid
Extra filöppningsflaggor: (inga)
128 filer, 8MiB var
1GiB total filstorlek
Blockstorlek 4KiB
Antal IO-begärningar: 0
Läs/Skriv-förhållande för kombinerad slumpmässig IO-test: 1.50
Periodisk FSYNC aktiverad, anropar fsync() var 100 begärningar.
Anropar fsync() i slutet av testet, Aktiverad.
Använder synkron IO-läge
Gör slumpmässigt r/w-test
Initierar arbetstrådar...
Trådar startade!
Filoperationer:
läsningar/s: 4587.95
skrivningar/s: 3058.66
fsyncs/s: 9795.73
Genomströmning:
läst, MiB/s: 17.92
skriven, MiB/s: 11.95
Allmän statistik:
total tid: 60.0241s
totalt antal händelser: 1046492
Latens (ms):
min: 0.00
genomsnitt: 0.23
max: 14.45
95:e percentilen: 0.94
summa: 238629.34
Trådars rättvisa:
händelser (genomsnitt/stdavvikelse): 261623.0000/1849.14
exekveringstid (genomsnitt/stdavvikelse): 59.6573/0.00
Disk på servern för säkerhetskopiering
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (använder system LuaJIT 2.0.4)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från aktuell tid
Extra filöppningsflaggor: (inga)
128 filer, 8MiB var
1GiB total filstorlek
Blockstorlek 4KiB
Antal IO-begärningar: 0
Läs/Skriv-förhållande för kombinerad slumpmässig IO-test: 1.50
Periodisk FSYNC aktiverad, anropar fsync() var 100 begärningar.
Anropar fsync() i slutet av testet, Aktiverad.
Använder synkron IO-läge
Gör slumpmässigt r/w-test
Initierar arbetstrådar...
Trådar startade!
Filoperationer:
läsningar/s: 11.37
skrivningar/s: 7.58
fsyncs/s: 29.99
Genomströmning:
läst, MiB/s: 0.04
skriven, MiB/s: 0.03
Allmän statistik:
total tid: 73.8868s
totalt antal händelser: 3104
Latens (ms):
min: 0.00
genomsnitt: 78.57
max: 3840.90
95:e percentilen: 297.92
summa: 243886.02
Trådars rättvisa:
händelser (genomsnitt/stdavvikelse): 776.0000/133.26
exekveringstid (genomsnitt/stdavvikelse): 60.9715/1.59
Nätverkshastighet mellan servrar
iperf3 -c backup
Ansluter till värd backup, port 5201
[ 4] lokal x.x.x.x port 59402 ansluten till y.y.y.y port 5201
[ ID] Intervall Överföring Bandbredd 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 Överföring Bandbredd Retr
[ 4] 0.00-10.00 sek 3.78 GBytes 3.25 Gbits/sec 8100 avsändare
[ 4] 0.00-10.00 sek 3.78 GBytes 3.25 Gbits/sec mottagare
Testmetodik
- På testservern förbereds filsystemet med den första testsatsen, på backupservern initieras repositoriet vid behov.
Backup-processen startas och dess tid mäts. - På testservern migreras filer till den andra testsatsen. Backup-processen startas och dess tid mäts.
- På testservern migreras filer till den tredje testsatsen. Backup-processen startas och dess tid mäts.
- Den erhållna tredje testsatsen accepteras som den nya första; punkterna 1-3 upprepas ytterligare 2 gånger.
- Data skrivs in i en sammanställningstabell, diagram läggs till med netdata.
- En rapport upprättas för den enskilda backup-metoden.
Förväntade resultat
Eftersom alla 3 kandidater är baserade på samma teknologi (rsync) förväntas resultaten vara nära de vanliga rsync-resultaten, inklusive alla dess fördelar, nämligen:
- Filer i repositoriet kommer att lagras "som de är".
- Storleken på repositoriet kommer endast att växa genom att inkludera skillnaden mellan backuperna.
- Det kommer att vara en relativt hög belastning på nätverket vid överföring av data, samt en låg belastning på processorn.
Testkörningen av vanliga rsync kommer att användas som referens, dess resultat
är följande
Flaskhalsen var på backupservern i form av en HDD-baserad disk, vilket tydligt framgår på diagrammen i form av en såg.
Data kopierades på 4 minuter och 15 sekunder.
Tester av rdiff-backup
Den första kandidaten är rdiff-backup, ett skript i python som gör säkerhetskopior av en katalog till en annan. Den aktuella säkerhetskopian lagras "som den är", medan tidigare säkerhetskopior lagras inkrementellt i en speciell underkatalog, vilket sparar utrymme.
Vi kommer att kontrollera det typiska arbetsläget, det vill säga att starta säkerhetskopieringsprocessen initiativt av klienten, medan en process på servern startar för att ta emot data för säkerhetskopiering.
Låt oss ta en titt på vad den kan göra under våra förhållanden.
Körtiden för varje testkörning:
Första körning
Andra körning
Tredje körning
Den första gruppen
16m32s
16m26s
16m19s
Den andra gruppen
2h5m
2h10m
2h8m
Den tredje gruppen
2h9m
2h10m
2h10m
Rdiff-backup reagerar ganska smärtsamt på stora datändringar och utnyttjar även nätverket otillräckligt.
Test av rsnapshot
Den andra kandidaten är rsnapshot, ett skript i perl vars huvudsakliga krav för effektiv drift är stöd för hårda länkar. Detta sparar utrymme på disken. Oförändrade filer sedan den senaste säkerhetskopian kommer att länka till den ursprungliga filen med hjälp av hårda länkar.
Logiken för säkerhetskopieringsprocessen är också inverterad: servern går aktivt runt till sina klienter och hämtar data.
Testresultat
Vi fick följande
Första körning
Andra körning
Tredje körning
Den första gruppen
4m22s
4m19s
4m16s
Den andra gruppen
2m6s
2m10s
2m6s
Den tredje gruppen
1m18s
1m10s
1m10s
Arbetade väldigt snabbt, mycket snabbare än rdiff-backup och mycket nära ren rsync.
Test av burp
Ett annat alternativ är implementationen på C ovanpå librsync — burp, som har en klient-server-arkitektur inklusive klientautentisering, samt en web-gränssnitt (ingår inte i grundpaketet). En annan intressant funktion är säkerhetskopiering utan återställningsrättigheter för klienterna.
Låt oss titta påprestanda.
Första körning
Andra körning
Tredje körning
Den första gruppen
11m21s
11m10s
10m56s
Den andra gruppen
5m37s
5m40s
5m35s
Den tredje gruppen
3m33s
3m24s
3m40s
Arbetade två gånger långsammare än rsnapshot, men fortfarande tillräckligt snabbt och definitivt snabbare än rdiff-backup. Graferna är lite sågtandade — prestandan begränsas återigen av diskunderlaget på backupservern, även om detta inte är så uttalat som hos rsnapshot.
Resultat
Storleken på arkiven för alla kandidater var ungefär densamma, dvs. först en ökning till 10 GB, sedan en ökning till 15 GB, sedan en ökning till 18 GB osv., vilket beror på funktionerna i rsync. Det är också värt att notera att alla kandidater var entrådade (CPU-användning på cirka 50 % vid en tvåkärnig maskin). Alla tre kandidater erbjöd möjlighet att återställa den senaste säkerhetskopian "som den är", det vill säga man kunde återställa filer utan att använda några externa program, inklusive de som användes för att skapa arkiven. Detta är också ett "arv" från rsync.
Slutsatser
Ju mer komplex backupsystemet är och ju fler olika funktioner det har, desto långsammare kommer det att fungera, men för mindre krävande projekt passar vilket som helst av dem, förutom kanske rdiff-backup.
Tillkännagivande
Denna anteckning fortsätter cykeln om säkerhetskopiering
Backup, del 2: Översikt och test av rsync-baserade backupverktyg
Säkerhetskopiering, del 3: Översikt och test av duplicity, duplicaty, deja dup
Backup, del 4: Översikt och test av zbackup, restic, borgbackup
Backup, del 5: Test av bacula och veeam backup för linux
Backup, del 6: Jämförelse av backupverktyg
Backup, del 7: Slutsatser
Publiceringsförfattare: Pavel Demkovich
Källa: habr.com
