Ohar honek jarraitzen du
babeskopiari buruzko zikloa
- Backup 2. zatia: rsync-en oinarritutako Backup Tresnen berrikuspena eta proba
- Backup 3. zatia: bikoiztasuna, bikoiztasuna, deja dup berrikustea eta probatzea
- Backup 4. zatia: zbackup, restic, borgbackup berrikustea eta probatzea
- Babeskopia 5. zatia: bacula eta veeam babeskopia probatzen linuxerako
- 6. babeskopia: babeskopia tresnak alderatzea
- Backup 7. zatia: ondorioak
Lehen artikuluan idatzi genuen bezala, rsync-en oinarritutako babeskopia-programa asko daude.
Gure baldintzetara hobekien egokitzen direnetatik 3 hartuko ditut kontuan: rdiff-backup, rsnapshot eta burp.
Probatu fitxategi multzoak
Proba-fitxategien multzoak berdinak izango dira hautagai guztientzat, etorkizuneko artikuluak barne.
Lehenengo multzoa: 10 GB multimedia-fitxategiak, eta 50 MB gutxi gorabehera - gunearen iturburu-kodea PHPn, fitxategien tamainak hainbat kilobytetik iturburu-kodearentzat, hamarnaka megabyte bitarteko fitxategietarako. Helburua gune estatiko bat imitatzea da.
Bigarren multzoa: 5 GB-ko multimedia-fitxategiak dituen azpidirektorio bati izena aldatzean lehenengotik lortzen da. Direktorio bati izena aldatzean babeskopia sistemaren portaera aztertzea da helburua.
Hirugarren multzoa: lehenengotik lortutako multimedia-fitxategiak 3GB ezabatuz eta multimedia-fitxategi berriak 3GB gehituz. Helburua gunearen eguneratze-eragiketa arrunt batean babeskopien sistemaren portaera aztertzea da.
Emaitzak lortzea
Edozein babeskopia gutxienez 3 aldiz egiten da eta fitxategi-sistemaren cacheak komandoekin berrezartzen ditu. sync и echo 3 > /proc/sys/vm/drop_caches bai proba-zerbitzariaren aldean, bai babeskopien biltegiratze-zerbitzariaren aldean.
Segurtasun-kopien iturria izango den zerbitzarian, monitorizazio softwarea instalatzen da - netdata, eta horren laguntzaz zerbitzariaren karga ebaluatuko da kopiatzerakoan, hau beharrezkoa da zerbitzariaren karga babeskopia prozesuan ebaluatzeko.
Era berean, uste dut babeskopien biltegiratze-zerbitzaria prozesadoreari dagokionez zerbitzari nagusia baino motelagoa dela, baina ausazko idazketa-abiadura nahiko baxua duten disko zabalagoak ditu - babeskopietan egoera ohikoena da, eta babeskopia-zerbitzariak ez duelako behar. behar bezala egin Ez dut beste zereginen jarraipena egingo babeskopia izan ezik, bere karga netdata erabiliz.
Era berean, hainbat sistemaren babeskopiak egiaztatuko ditudan zerbitzariak ere aldatu ditut.
Orain honako ezaugarri hauek dituzteprozesadorea
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, irakurketa...
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
...eta grabaketa
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
Diskoa datu-iturburuko zerbitzarian
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
Diskoa babeskopien biltegiratze zerbitzarian
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
Zerbitzarien arteko sarearen abiadura
iperf3 -c backup
Connecting to host backup, port 5201
[ 4] local x.x.x.x port 59402 connected to y.y.y.y 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
Proba metodologia
- Proba-zerbitzarian, lehen proba-multzoa duen fitxategi-sistema bat prestatzen da eta babeskopien biltegiratze-zerbitzarian, beharrezkoa bada, biltegia abiarazten da.
Backup-prozesua abiarazten da eta bere denbora neurtzen da. - Proba zerbitzarian, fitxategiak bigarren proba multzora migratzen dira. Backup-prozesua abiarazten da eta bere denbora neurtzen da.
- Proba zerbitzarian, migrazioa hirugarren proba multzora arte egiten da. Backup-prozesua abiarazten da eta bere denbora neurtzen da.
- Ondorioz, hirugarren proba multzoa lehen berri gisa onartzen da; 1-3 urratsak beste 2 aldiz errepikatzen dira.
- Datuak taula dinamiko batean sartzen dira, eta netdata duten grafikoak gehitzen dira.
- Banakako babeskopia metodorako txosten bat sortzen da.
Espero ziren emaitzak
3 hautagaiak teknologia berean (rsync) oinarritzen direnez, emaitzak rsync arruntetik hurbil egotea espero da, bere abantaila guztiak barne, hots:
- Biltegiko fitxategiak "dagoen moduan" gordeko dira.
- Biltegiaren tamaina soilik haziko da babeskopien arteko aldea barne.
- Sarean karga handi samarra egongo da datuak transferitzean, baita prozesadorean karga txiki bat ere.
Erreferentzia gisa rsync arruntaren proba proba bat erabiliko da, bere emaitzak
hauek dira
Botil-lepoa babeskopiko datuen biltegiratze zerbitzarian zegoen HDDn oinarritutako disko baten moduan, zerra-hortz grafikoetan nahiko argi ikusten dena.
Datuak 4 minutu eta 15 segundotan kopiatu ziren.
rdiff-backup probatzen
Lehen hautagaia rdiff-backup da, direktorio baten babeskopiak beste batean egiten dituen python script bat. Kasu honetan, uneko segurtasun kopia "bezala" gordetzen da, eta lehenago egindako segurtasun kopiak pixkanaka azpidirektorio berezi batean gordetzen dira, eta horrela tokia aurrezten da.
Eragiketa modu tipikoa egiaztatuko dugu, hau da. Babeskopia-prozesuaren abiarazte bezeroak berak abiarazten du, eta zerbitzariaren aldetik babeskopia egiteko, datuak jasotzen dituen prozesu bat abiarazten da.
Ikus dezagun begirada bat, zertarako gai da gure baldintzetan?.
Proba bakoitzaren iraupena:
Lehenengo hasiera
Bigarren jaurtiketa
Hirugarren jaurtiketa
Lehenengo multzoa
16m32s
16m26s
16m19s
Bigarren multzoa
2h5m
2h10m
2h8m
Hirugarren multzoa
2h9m
2h10m
2h10m
Rdiff-backup-ek oso minez erreakzionatzen du datuen edozein aldaketa handiren aurrean, eta, gainera, ez du sarea guztiz erabiltzen.
rsnapshot proba
Bigarren hautagaia, rsnapshot, Perl script bat da eta funtzionamendu eraginkorra izateko baldintza nagusia esteka gogorren laguntza da. Honek diskoko espazioa aurrezten du. Kasu honetan, aurreko babeskopia egin zenetik aldatu ez diren fitxategiak jatorrizko fitxategira esteka gogorren bidez lotuko dira.
Backup-prozesuaren logika ere alderantzikatu egiten da: zerbitzaria aktiboki "ibiltzen da" bere bezeroen artean eta datuak hartzen ditu.
Proben emaitzak
honakoa atera zen
Lehenengo hasiera
Bigarren jaurtiketa
Hirugarren jaurtiketa
Lehenengo multzoa
4m22s
4m19s
4m16s
Bigarren multzoa
2m6s
2m10s
2m6s
Hirugarren multzoa
1m18s
1m10s
1m10s
Oso-oso azkar funtzionatu zuen, rdiff-backup baino askoz azkarrago eta rsync hutsetik oso gertu.
Burp proba
Beste aukera bat C inplementazioa da librsync - burp-en gainean, bezero-zerbitzari-arkitektura bat duena, bezeroaren baimena barne, baita web interfaze bat ere (oinarrizko paketean sartzen ez dena). Beste ezaugarri interesgarri bat bezeroaren aldetik berreskuratu gabeko babeskopiak dira.
Ikus dezagunproduktibitatea.
Lehenengo hasiera
Bigarren jaurtiketa
Hirugarren jaurtiketa
Lehenengo multzoa
11m21s
11m10s
10m56s
Bigarren multzoa
5m37s
5m40s
5m35s
Hirugarren multzoa
3m33s
3m24s
3m40s
Rsnapshot baino 2 aldiz motelago funtzionatu zuen, baina nahiko azkar, eta zalantzarik gabe rdiff-backup baino azkarrago. Grafikoak zerra-hortz samarrak dira - errendimendua berriro babeskopien biltegiratze zerbitzariaren disko azpisistemaren araberakoa da, nahiz eta hau ez den rsnapshot-ekin bezain nabarmena.
Findings
Hautagai guztien biltegien tamaina gutxi gorabehera berdina zen, hau da, lehenengo 10 GB-ra hazten zen, gero 15 GB-ra hazten zen, gero 18 GB-ra hazten zen, etab., rsync-en berezitasunari esker. Aipatzekoa da, halaber, hautagai guztiak hari bakarrekoak direla (prozesadorearen karga %50 ingurukoa da nukleo bikoitzeko makina batean). 3 hautagaiek azken babeskopia "dagoen moduan" leheneratzeko aukera eman zuten, hau da, hirugarrenen programarik erabili gabe fitxategiak berreskuratu ahal izan ziren, biltegiak sortzeko erabiltzen direnak barne. Hau ere rsync-en "arbasoen ondarea" da.
Findings
Backup-sistema zenbat eta konplexuagoa izan eta zenbat eta gaitasun ezberdin gehiago izan, orduan eta motelagoa izango da funtzionatuko, baina oso zorrotzak ez diren proiektuetarako horietako edozein izango da egokia, agian rdiff-backup izan ezik.
Anuntzio
Ohar honek babeskopiari buruzko zikloa jarraitzen du
Backup 2. zatia: rsync-en oinarritutako babeskopia tresnak berrikustea eta probatzea
Backup 3. zatia: bikoiztasuna, bikoiztasuna, deja dup berrikustea eta probatzea
Backup 4. zatia: zbackup, restic, borgbackup berrikustea eta probatzea
Babeskopia 5. zatia: bacula eta veeam babeskopia probatzen linuxerako
6. babeskopia: babeskopia tresnak alderatzea
Backup 7. zatia: ondorioak
Argitalpenaren egilea: Pavel Demkovich
Iturria: www.habr.com
