Denne note fortsætter
cirklen om sikkerhedskopiering
- Sikkerhedskopiering, del 2: Oversigt og test af rsync-baserede sikkerhedskopieringsværktøjer
- Sikkerhedskopiering, del 3: Oversigt og test af duplicity, duplicaty, deja dup
- Sikkerhedskopiering, del 4: Oversigt og test af zbackup, restic, borgbackup
- Sikkerhedskopiering, del 5: Test af bacula og veeam backup for linux
- Sikkerhedskopiering, del 6: Sammenligning af sikkerhedskopieringsværktøjer
- Backup, del 7: Konklusioner
Som vi allerede har nævnt i den første artikel, findes der et væld af sikkerhedskopieringsprogrammer, der er baseret på rsync.
Af de, der passer bedst til vores behov, vil jeg se på 3: rdiff-backup, rsnapshot og burp.
Testdatasæt
Datasættene til testningen vil være de samme for alle kandidater, inklusive fremtidige artikler.
Det første sæt: 10 GB mediefiler og cirka 50 MB - kildekoden til et website i php, filstørrelser fra et par kilobyte for kildekoden til titusinder af megabyte for mediefilerne. Målet er at simulere et website med statisk indhold.
Det andet sæt: opstår fra det første ved at omdøbe en undermappe med mediefiler, der er 5 GB store. Målet er at undersøge systemets adfærd under omdøbning af mapper.
Det tredje sæt: opstår fra det første ved at fjerne 3 GB mediefiler og tilføje nye 3 GB mediefiler. Målet er at undersøge systemets adfærd under en typisk opdateringsoperation af websitet.
Indhentning af resultater
Enhver sikkerhedskopiering udføres mindst 3 gange og ledsages af nulstilling af filsystemets cache med kommandoerne synk og echo 3 > /proc/sys/vm/drop_caches både på testserveren og backupserveren.
På serveren, der vil være kilden til sikkerhedskopierne, er der installeret overvågningssoftware - netdata, med hvilken belastningen på serveren under kopieringen vil blive vurderet, dette er nødvendigt for at vurdere belastningen fra sikkerhedskopieringsprocessen.
Jeg mener også, at backupserveren har en langsommere processor end hovedserveren, men disponerer over mere rummelige diske med relativt lav hastighed for tilfældige skrivninger - den mest almindelige situation under sikkerhedskopiering, og da backupserveren i teorien ikke bør udføre andre opgaver end sikkerhedskopiering, vil jeg ikke overvåge dens belastning med netdata.
Jeg har også ændret de servere, som jeg vil teste forskellige sikkerhedskopieringssystemer på.
De har nu følgende specifikationerProcessor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu kør
sysbench 1.0.17 (ved hjælp af system LuaJIT 2.0.4)
Kører testen med følgende indstillinger:
Antal tråde: 2
Initialiserer tilfældig talgenerator fra den nuværende tid
Primtal grænse: 20000
Initialiserer arbejdertråde...
Tråde startet!
CPU hastighed:
begivenheder pr. sekund: 1081.62
Generelle statistikker:
total tid: 30.0013s
samlet antal begivenheder: 32453
Latens (ms):
min: 1.48
gennemsnit: 1.85
max: 9.84
95. percentil: 2.07
sum: 59973.40
Trådenes retfærdighed:
begivenheder (gennemsnit/stdafvigelse): 16226.5000/57.50
udførelsestid (gennemsnit/stdafvigelse): 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 kør
sysbench 1.0.17 (ved hjælp af system LuaJIT 2.0.4)
Kører testen med følgende indstillinger:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra den nuværende tid
Kører hukommelseshastighedstest med følgende indstillinger:
blokstørrelse: 1KiB
total størrelse: 102400MiB
operation: læsning
omfang: global
Initialiserer arbejdertråde...
Tråde startet!
Samlede operationer: 104857600 (5837637.63 pr. sekund)
102400.00 MiB overført (5700.82 MiB/sek)
Generelle statistikker:
total tid: 17.9540s
samlet antal begivenheder: 104857600
Latens (ms):
min: 0.00
gennemsnit: 0.00
max: 66.08
95. percentil: 0.00
sum: 18544.64
Trådenes retfærdighed:
begivenheder (gennemsnit/stdafvigelse): 26214400.0000/0.00
udførelsestid (gennemsnit/stdafvigelse): 4.6362/0.12
… og skrivning
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory kør
sysbench 1.0.17 (ved hjælp af system LuaJIT 2.0.4)
Kører testen med følgende indstillinger:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra den nuværende tid
Kører hukommelseshastighedstest med følgende indstillinger:
blokstørrelse: 1KiB
total størrelse: 102400MiB
operation: skrivning
omfang: global
Initialiserer arbejdertråde...
Tråde startet!
Samlede operationer: 91414596 (3046752.56 pr. sekund)
89272.07 MiB overført (2975.34 MiB/sek)
Generelle statistikker:
total tid: 30.0019s
samlet antal begivenheder: 91414596
Latens (ms):
min: 0.00
gennemsnit: 0.00
max: 1022.90
95. percentil: 0.00
sum: 66430.91
Trådenes retfærdighed:
begivenheder (gennemsnit/stdafvigelse): 22853649.0000/945488.53
udførelsestid (gennemsnit/stdafvigelse): 16.6077/1.76
Disk på datakilde-serveren
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)
Kører testen med følgende indstillinger:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra nuværende tid
Ekstra filåbningsflager: (ingen)
128 filer, 8MiB hver
1GiB samlet filstørrelse
Blokstørrelse 4KiB
Antal IO-anmodninger: 0
Read/Write-forhold for kombineret tilfældig IO-test: 1.50
Periodisk FSYNC aktiveret, kalder fsync() hver 100 anmodninger.
Kalder fsync() ved slutningen af testen, aktiveret.
Bruger synkront I/O-mode
Udfører tilfældig r/w-test
Initialiserer arbejdstråde...
Tråde startet!
Filoperationer:
læsninger/s: 4587.95
skrivninger/s: 3058.66
fsyncs/s: 9795.73
Gennemløb:
læst, MiB/s: 17.92
skrevet, MiB/s: 11.95
Generelle statistikker:
samlet tid: 60.0241s
samlet antal hændelser: 1046492
Forsinkelse (ms):
min: 0.00
gennemsnit: 0.23
maks: 14.45
95. percentil: 0.94
sum: 238629.34
Trådretfærdighed:
hændelser (gennemsnit/stdafvik): 261623.0000/1849.14
udførelsestid (gennemsnit/stdafvik): 59.6573/0.00
Disk på backup-serveren
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)
Kører testen med følgende indstillinger:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra nuværende tid
Ekstra filåbningsflager: (ingen)
128 filer, 8MiB hver
1GiB samlet filstørrelse
Blokstørrelse 4KiB
Antal IO-anmodninger: 0
Read/Write-forhold for kombineret tilfældig IO-test: 1.50
Periodisk FSYNC aktiveret, kalder fsync() hver 100 anmodninger.
Kalder fsync() ved slutningen af testen, aktiveret.
Bruger synkront I/O-mode
Udfører tilfældig r/w-test
Initialiserer arbejdstråde...
Tråde startet!
Filoperationer:
læsninger/s: 11.37
skrivninger/s: 7.58
fsyncs/s: 29.99
Gennemløb:
læst, MiB/s: 0.04
skrevet, MiB/s: 0.03
Generelle statistikker:
samlet tid: 73.8868s
samlet antal hændelser: 3104
Forsinkelse (ms):
min: 0.00
gennemsnit: 78.57
maks: 3840.90
95. percentil: 297.92
sum: 243886.02
Trådretfærdighed:
hændelser (gennemsnit/stdafvik): 776.0000/133.26
udførelsestid (gennemsnit/stdafvik): 60.9715/1.59
Netværkshastighed mellem servere
iperf3 -c backup
Forbinder til værten backup, port 5201
[ 4] lokal x.x.x.x port 59402 forbundet til y.y.y.y port 5201
[ ID] Interval Overførsel Båndbredde Retr Cwnd
[ 4] 0.00-1.00 sek 419 MBytes 3.52 Gbits/sek 810 182 KBytes
[ 4] 1.00-2.00 sek 393 MBytes 3.30 Gbits/sek 810 228 KBytes
[ 4] 2.00-3.00 sek 378 MBytes 3.17 Gbits/sek 810 197 KBytes
[ 4] 3.00-4.00 sek 380 MBytes 3.19 Gbits/sek 855 198 KBytes
[ 4] 4.00-5.00 sek 375 MBytes 3.15 Gbits/sek 810 182 KBytes
[ 4] 5.00-6.00 sek 379 MBytes 3.17 Gbits/sek 765 228 KBytes
[ 4] 6.00-7.00 sek 376 MBytes 3.15 Gbits/sek 810 180 KBytes
[ 4] 7.00-8.00 sek 379 MBytes 3.18 Gbits/sek 765 253 KBytes
[ 4] 8.00-9.00 sek 380 MBytes 3.19 Gbits/sek 810 239 KBytes
[ 4] 9.00-10.00 sek 411 MBytes 3.44 Gbits/sek 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Overførsel Båndbredde Retr
[ 4] 0.00-10.00 sek 3.78 GBytes 3.25 Gbits/sek 8100 sender
[ 4] 0.00-10.00 sek 3.78 GBytes 3.25 Gbits/sek modtager
Testmetode
- Filsystemet bliver forberedt på testserveren med det første testsæt, og på backupsserveren initieres lageret ved behov.
Backupprocessen startes, og tiden måles. - Filer migreres på testserveren til det andet testsæt. Backupprocessen startes, og tiden måles.
- Filer migreres på testserveren til det tredje testsæt. Backupprocessen startes, og tiden måles.
- Det opnåede tredje testsæt accepteres som det nye første; punkterne 1-3 gentages to gange til.
- Data indtastes i en opsummeringstabel, og diagrammer tilføjes med netdata.
- En rapport om den specifikke backupmetode udarbejdes.
Forventede resultater
Da alle 3 kandidater er baseret på den samme teknologi (rsync), forventes det, at resultaterne vil være tæt på almindelig rsync, inklusive alle dens fordele, nemlig:
- Filerne i lageret vil blive opbevaret "som de er".
- Størrelsen på lageret vil kun vokse ved at inkludere forskellen mellem backuperne.
- Der vil være en relativt stor belastning på netværket ved overførsel af data samt en lille belastning på CPU'en.
Testkørslen af almindelig rsync vil blive anvendt som reference, dens resultater
er som følger
Flaskehalsen var på backupserveren i form af en HDD-baseret disk, hvilket klart fremgår i grafikkerne.
Data blev kopieret på 4 minutter og 15 sekunder.
Test af rdiff-backup
Den første kandidat er rdiff-backup, et Python-script, der udfører backup af én mappe til en anden. Den aktuelle backup gemmes "som den er", mens tidligere lavede backups opbevares inkrementelt i en særlig undermappe, hvilket sparer plads.
Vi vil tjekke den typiske arbejdsmetode, dvs. at backup-processen startes af klienten selv, og på serverens side startes der en proces til backup, der accepterer data.
Lad os tage et kig på, hvad det kan i vores forhold.
Tid for hver teststart:
Første opstart
Anden opstart
Tredje opstart
Det første sæt
16m32s
16m26s
16m19s
Det andet sæt
2h5m
2h10m
2h8m
Det tredje sæt
2h9m
2h10m
2h10m
Rdiff-backup reagerer ret smertefuldt på enhver stor ændring af data og udnytter heller ikke netværket fuldt ud.
Test af rsnapshot
Den anden kandidat er rsnapshot, et Perl-script, hvis hovedkrav for effektiv drift er støtte til hårde links. Dette sparer diskplads. Uændrede filer siden den seneste backup vil henvise til den originale fil vha. af hårde links.
Og logikken i backup-processen er også inverteret: Serveren opsøger aktivt sine klienter og henter data.
Ydeevnetest
der blev følgende resultater
Første opstart
Anden opstart
Tredje opstart
Det første sæt
4m22s
4m19s
4m16s
Det andet sæt
2m6s
2m10s
2m6s
Det tredje sæt
1m18s
1m10s
1m10s
Det fungerede meget hurtigt, meget hurtigere end rdiff-backup og tættere på ren rsync.
Test af burp
En anden mulighed er implementationen i C oven på librsync - burp, som har en klient-server-arkitektur inklusive klientautorisering og en webgrænseflade (ikke inkluderet i den grundlæggende pakke). En interessant funktion er backup uden gendannelsesret for klienter.
Lad os tage et kig påydelse.
Første opstart
Anden opstart
Tredje opstart
Det første sæt
11m21s
11m10s
10m56s
Det andet sæt
5m37s
5m40s
5m35s
Det tredje sæt
3m33s
3m24s
3m40s
Det arbejdede to gange langsommere end rsnapshot, men stadig hurtigt, og helt sikkert hurtigere end rdiff-backup. Graferne er lidt hakkede - ydelsen støder igen op ad disksystemet på backup-serveren, men det er ikke så udtalt som hos rsnapshot.
Resultater
Størrelsen på arkiverne for alle kandidater var omtrent den samme, dvs. først voksede de til 10 GB, derefter til 15 GB, så til 18 GB osv., hvilket skyldes, hvordan rsync arbejder. Det er også værd at bemærke, at alle kandidater var entrådede (CPU-belastning omkring 50% på en dual-core maskine). Alle 3 kandidater tilbød muligheden for at gendanne den seneste backup «som den er», hvilket vil sige, at filer kunne gendannes uden brug af nogen tredjeparter programmer, inklusiv dem der blev brugt til at oprette arkiverne. Dette er også et «arv» fra rsync.
Konklusioner
Jo mere kompleks systemet til backup er, og jo flere forskellige funktioner det har, jo langsommere vil det fungere, men til ikke meget krævende projekter vil enhver af dem være passende, undtagen måske rdiff-backup.
Annonce
Denne note fortsætter cyklussen om backup
Backup, del 2: Oversigt og test af rsync-baserede backupløsninger.
Sikkerhedskopiering, del 3: Oversigt og test af duplicity, duplicaty, deja dup
Sikkerhedskopiering, del 4: Oversigt og test af zbackup, restic, borgbackup
Sikkerhedskopiering, del 5: Test af bacula og veeam backup for linux
Sikkerhedskopiering, del 6: Sammenligning af sikkerhedskopieringsværktøjer
Backup, del 7: Konklusioner
Forfatteren af publikationen: Pavel Demkovich
Kilde: habr.com
