Această notă continuă
ciclul despre backup-uri
- Backup, partea 2: Prezentare generală și testare a soluțiilor de backup bazate pe rsync
- Backup, partea 3: Prezentare generală și testare duplicity, duplicaty, deja dup
- Backup, partea 4: Revizuirea și testarea zbackup, restic, borgbackup
- Backup, partea 5: Testarea bacula și veeam backup pentru linux.
- Backup, partea 6: Comparația uneltelor de backup
- Backup, partea 7: Concluzii
Așa cum am menționat în primul articol, există un număr destul de mare de programe de backup bazate pe rsync.
Dintre cele care se potrivesc cel mai bine cerințelor noastre, voi analiza 3: rdiff-backup, rsnapshot și burp.
Seturi de fișiere de testare
Seturile de fișiere pentru testare vor fi identice pentru toți candidații, inclusiv articolele viitoare.
Primul set: 10 GB de fișiere media și aproximativ 50 MB — codul sursă al site-ului pe php, dimensiunile fișierelor variind de la câțiva kilobytes pentru codul sursă, până la zeci de megabytes pentru fișierele media. Scopul este simularea unui site static.
Al doilea set: se obține din primul prin redenumirea subdirectorului cu fișierele media de 5 GB. Scopul este studierea comportamentului sistemului de backup la redenumirea directorului.
Al treilea set: se obține din primul prin ștergerea a 3 GB de fișiere media și adăugarea a 3 GB noi de fișiere media. Scopul este studierea comportamentului sistemului de backup la o operațiune tipică de actualizare a site-ului.
Obținerea rezultatelor
Orice backup este efectuat de minimum 3 ori și este însoțit de golirea cache-urilor sistemului de fișiere cu comenzile sync și echo 3 > /proc/sys/vm/drop_caches atât pe serverul de testare, cât și pe serverul de stocare a backup-urilor.
Pe serverul care va fi sursa backup-urilor, este instalat un software de monitorizare — netdata, cu ajutorul căruia va fi evaluată încărcarea serverului în timpul copiei, ceea ce este necesar pentru evaluarea sarcinii serverului în procesul de backup.
De asemenea, consider că serverul de stocare a backup-urilor este mai lent din punct de vedere al procesorului decât serverul principal, dar are discuri mai mari cu o viteză relativ mică de scriere aleatoare — cea mai frecventă situație în timpul backup-ului, și din cauza faptului că serverul de backup nu ar trebui să îndeplinească alte sarcini în afară de realizarea backup-ului, nu voi urmări încărcarea sa cu netdata.
De asemenea, s-au schimbat serverele pe care voi verifica diferitele sisteme pentru backup.
Acum au următoarele specificațiiProcesor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Se rulează testul cu următoarele opțiuni:
Numărul de fire: 2
Inițializarea generatorului de numere aleatorii din timpul curent
Limită numere prime: 20000
Inițializarea firelor de muncă...
Firele au fost pornite!
Viteza CPU:
evenimente pe secundă: 1081.62
Statistici generale:
timpul total: 30.0013s
numărul total de evenimente: 32453
Latența (ms):
min: 1.48
medie: 1.85
max: 9.84
percentilă 95: 2.07
sumă: 59973.40
Echitatea firelor:
evenimente (medie/abateri standard): 16226.5000/57.50
timp de execuție (medie/abateri standard): 29.9867/0.00
Memorie RAM, citire…
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)
Se rulează testul cu următoarele opțiuni:
Numărul de fire: 4
Inițializarea generatorului de numere aleatorii din timpul curent
Se rulează testul de viteză a memoriei cu următoarele opțiuni:
dimensiune bloc: 1KiB
dimensiune totală: 102400MiB
operație: citire
domeniu: global
Inițializarea firelor de muncă...
Firele au fost pornite!
Total operații: 104857600 (5837637.63 pe secundă)
102400.00 MiB transferate (5700.82 MiB/sec)
Statistici generale:
timpul total: 17.9540s
numărul total de evenimente: 104857600
Latența (ms):
min: 0.00
medie: 0.00
max: 66.08
percentilă 95: 0.00
sumă: 18544.64
Echitatea firelor:
evenimente (medie/abateri standard): 26214400.0000/0.00
timp de execuție (medie/abateri standard): 4.6362/0.12
… și scriere
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)
Se rulează testul cu următoarele opțiuni:
Numărul de fire: 4
Inițializarea generatorului de numere aleatorii din timpul curent
Se rulează testul de viteză a memoriei cu următoarele opțiuni:
dimensiune bloc: 1KiB
dimensiune totală: 102400MiB
operație: scriere
domeniu: global
Inițializarea firelor de muncă...
Firele au fost pornite!
Total operații: 91414596 (3046752.56 pe secundă)
89272.07 MiB transferate (2975.34 MiB/sec)
Statistici generale:
timpul total: 30.0019s
numărul total de evenimente: 91414596
Latența (ms):
min: 0.00
medie: 0.00
max: 1022.90
percentilă 95: 0.00
sumă: 66430.91
Echitatea firelor:
evenimente (medie/abateri standard): 22853649.0000/945488.53
timp de execuție (medie/abateri standard): 16.6077/1.76
Disk pe serverul sursă de date
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (folosind system LuaJIT 2.0.4)
Se rulează testul cu următoarele opțiuni:
Numărul de threads: 4
Inițializând generatorul de numere aleatoare din timpul curent
Extra file open flags: (none)
128 fișiere, 8MiB fiecare
1GiB dimensiune totală fișier
Dimensiunea blocului 4KiB
Numărul de cereri IO: 0
Raport citire/scriere pentru testul combinat de IO aleator: 1.50
FSYNC periodic activat, apelând fsync() la fiecare 100 de cereri.
Apelând fsync() la sfârșitul testului, activat.
Folosind modul de I/O sincron
Executând testul aleator r/w
Inițializând threads-urile de lucru...
Threads started!
Operațiuni cu fișiere:
citiri/s: 4587.95
scrieri/s: 3058.66
fsyncs/s: 9795.73
Prinput:
citire, MiB/s: 17.92
scris, MiB/s: 11.95
Statistici generale:
timp total: 60.0241s
numărul total de evenimente: 1046492
Latenta (ms):
min: 0.00
medie: 0.23
max: 14.45
95th percentile: 0.94
sumă: 238629.34
Echitatea thread-urilor:
evenimente (medie/stddev): 261623.0000/1849.14
timp de execuție (medie/stddev): 59.6573/0.00
Disc pe serverul de stocare a copiilor de rezervă
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (folosind system LuaJIT 2.0.4)
Se rulează testul cu următoarele opțiuni:
Numărul de threads: 4
Inițializând generatorul de numere aleatoare din timpul curent
Extra file open flags: (none)
128 fișiere, 8MiB fiecare
1GiB dimensiune totală fișier
Dimensiunea blocului 4KiB
Numărul de cereri IO: 0
Raport citire/scriere pentru testul combinat de IO aleator: 1.50
FSYNC periodic activat, apelând fsync() la fiecare 100 de cereri.
Apelând fsync() la sfârșitul testului, activat.
Folosind modul de I/O sincron
Executând testul aleator r/w
Inițializând threads-urile de lucru...
Threads started!
Operațiuni cu fișiere:
citiri/s: 11.37
scrieri/s: 7.58
fsyncs/s: 29.99
Prinput:
citire, MiB/s: 0.04
scris, MiB/s: 0.03
Statistici generale:
timp total: 73.8868s
numărul total de evenimente: 3104
Latenta (ms):
min: 0.00
medie: 78.57
max: 3840.90
95th percentile: 297.92
sumă: 243886.02
Echitatea thread-urilor:
evenimente (medie/stddev): 776.0000/133.26
timp de execuție (medie/stddev): 60.9715/1.59
Viteza rețelei între servere
iperf3 -c backup
Conectându-se la gazda backup, portul 5201
[ 4] local x.x.x.x port 59402 conectat la 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
Metodologia de testare
- Pe serverul de testare, sistemul de fișiere este pregătit cu primul set de teste, iar pe serverul de stocare a copiilor de siguranță, repositoarele sunt inițializate dacă este necesar.
Se inițiază procesul de copiere de rezervă și se măsoară timpul acestuia. - Pe serverul de testare se migrează fișierele către al doilea set de teste. Se inițiază procesul de copiere de rezervă și se măsoară timpul acestuia.
- Pe serverul de testare se migrează către al treilea set de teste. Se inițiază procesul de copiere de rezervă și se măsoară timpul acestuia.
- Al treilea set de teste obținut devine noul prim set; punctele 1-3 se repetă de încă 2 ori.
- Datele sunt introduse în tabelul rezumativ, se adaugă grafice cu netdata.
- Se întocmește un raport pentru metoda individuală de copiere de rezervă.
Rezultatele așteptate
Deoarece toți cei 3 candidați se bazează pe aceeași tehnologie (rsync), se așteaptă ca rezultatele să fie apropiate de rsync obișnuit, incluzând toate avantajele sale, și anume:
- Fișierele din repositoar vor fi păstrate "așa cum sunt".
- Dimensiunea repositoarului va crește doar inclusiv diferența dintre copii de siguranță.
- Va exista o încărcare comparativ mare pe rețea la transferul de date, precum și o mică încărcare pe procesor.
Testul standard al rsync obișnuit va fi aplicat ca etalon, iar rezultatele sale
sunt următoarele
Punctul critic a fost pe serverul de stocare a copiilor de siguranță, reprezentat printr-un disc bazat pe HDD, ceea ce se poate observa clar pe grafice ca un zigzag.
Datele au fost copiate în 4 minute și 15 secunde.
Testarea rdiff-backup
Primul candidat este rdiff-backup, un script în Python care efectuează rezervarea unui director într-un altul. Astfel, copia de rezervă curentă este stocată „așa cum este”, iar copiile de rezervă realizate anterior sunt păstrate într-un subdirector special în mod incremental, economisind astfel spațiu.
Vom verifica modul de operare standard, adică inițierea procesului de rezervare este efectuată de client, iar pe server este lansat un proces care primește datele pentru rezervare.
Să vedem, la ce este capabil în condițiile noastre.
Timpul de execuție pentru fiecare test:
Prima lansare
A doua lansare
A treia lansare
Primul set
16m32s
16m26s
16m19s
Al doilea set
2h5m
2h10m
2h8m
Al treilea set
2h9m
2h10m
2h10m
Rdiff-backup reacționează destul de dur la orice modificare mare a datelor, de asemenea, nu utilizează complet rețeaua.
Testarea rsnapshot
Al doilea candidat este rsnapshot, un script în Perl, a cărui cerință principală pentru funcționare eficientă este suportul pentru link-uri hard. Astfel, se economisește spațiu pe disc. În plus, fișierele care nu s-au modificat de la ultima copie de rezervă vor face referire la fișierul original prin intermediul link-urilor hard.
De asemenea, logica procesului de rezervare este inversată: serverul se deplasează activ printre clienții săi și preia datele.
Rezultatele testării
au rezultat următoarele
Prima lansare
A doua lansare
A treia lansare
Primul set
4m22s
4m19s
4m16s
Al doilea set
2m6s
2m10s
2m6s
Al treilea set
1m18s
A funcționat destul de rapid, mult mai repede decât rdiff-backup și foarte aproape de rsync curat.
A funcționat destul de rapid, mult mai repede decât rdiff-backup și foarte aproape de rsync curat.
Testarea burp
O altă variantă este implementarea în C deasupra librsync – burp, care are o arhitectură client-server, inclusiv autentificarea clienților, precum și un web interface (nu este inclus în pachetul de bază). O altă caracteristică interesantă este rezervarea fără drept de recuperare pentru clienți.
Să ne uităm la
11m21sperformanța.
Prima lansare
A doua lansare
A treia lansare
Primul set
11m10s
10m56s
5m37s
Al doilea set
3m33s
5m40s
5m35s
Al treilea set
3m24s
3m40s
A funcționat de 2 ori mai lent decât rsnapshot, dar totuși destul de repede, și cu siguranță mai repede decât rdiff-backup. Graficele sunt ușor zimțate - performanța din nou este limitată de subsistemul de disc al serverului de rezervare, deși acest lucru nu este atât de evident ca în cazul rsnapshot.
A funcționat de două ori mai lent decât rsnapshot, dar totuși suficient de repede și cu siguranță mai rapid decât rdiff-backup. Graficele sunt ușor ondulate — performanța se bazează din nou pe subsistemul de discuri al serverului de backup, deși acest lucru nu este atât de pronunțat ca la rsnapshot.
Rezultate
Dimensiunea repositoarelor pentru toți candidații a fost aproximativ aceeași, adică, inițial a crescut până la 10 GB, apoi până la 15 GB, apoi până la 18 GB etc., ceea ce este legat de specificul funcționării rsync. De asemenea, merită menționată unicitatea tuturor candidaților (încărcarea pe procesor era de aproximativ 50% pe o mașină cu două nuclee). Toți cei 3 candidați oferă posibilitatea de a restaura ultima copie de rezervă „așa cum este”, adică se puteau restaura fișiere fără a utiliza programe externe, inclusiv cele utilizate pentru crearea repositoarelor. Aceasta este, de asemenea, o „moștenire” a rsync.
Conclusions
Cu cât sistemul de backup este mai complex și cu atât are mai multe funcționalități, cu atât va funcționa mai lent, dar pentru proiecte nu foarte exigente, oricare dintre ele va fi potrivită, cu excepția, poate, a rdiff-backup.
Anunț
Această notă continuă ciclul despre backup-uri
Backup, partea 2: Revizuirea și testarea instrumentelor de backup bazate pe rsync.
Backup, partea 3: Prezentare generală și testare duplicity, duplicaty, deja dup
Backup, partea 4: Revizuirea și testarea zbackup, restic, borgbackup
Backup, partea 5: Testarea bacula și veeam backup pentru linux.
Backup, partea 6: Comparația uneltelor de backup
Backup, partea 7: Concluzii
Autorul publicației: Pavel Demkovici
Sursa: habr.com
