În această notă sunt discutate instrumentele de backup care efectuează backup prin crearea de arhive pe un server de rezervă.
Dintre acele instrumente care îndeplinesc cerințele, se numără duplicity (care are o interfață plăcută sub forma deja dup) și duplicati.
Un alt instrument de backup remarcabil este dar, dar având în vedere că acesta dispune de o listă foarte extinsă de opțiuni, metodologia de testare acoperă cu greu 10% din ceea ce poate realiza. Așadar, nu-l testăm în cadrul acestui ciclu.
Rezultatele așteptate
Deoarece ambele soluții generează arhive, ca referință putem folosi tar-ul obișnuit.
În plus, evaluăm cât de bine se optimizează stocarea datelor pe serverul de stocare prin crearea de backup-uri care conțin doar diferențele între copia completă și starea curentă a fișierelor, sau între arhivele anterioare și cele curente (incrementale, decrementale etc.).
Comportamentul la crearea backup-urilor:
- Numărul relativ mic de fișiere pe serverul de backup (comparabil cu numărul de backup-uri sau dimensiunea datelor în GB), dar dimensiunea acestora este destul de mare (câteva zeci sau sute de megabytes).
- Dimensiunea depozitului va include doar modificările — duplicatele nu vor fi stocate, astfel că dimensiunea depozitului va fi mai mică decât în cazul software-ului bazat pe rsync.
- Se așteaptă o mare încărcare pe procesor atunci când se folosește compresia și/sau criptarea, precum și, probabil, o încărcare destul de mare pe rețea și subsistemul de disc, dacă procesul de arhivare și/sau criptare va funcționa pe serverul de backup.
Ca valoare de referință, vom rula următoarea comandă:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Rezultatele obținute sunt următoarele:
Timpul de execuție a fost 3m12s. Este evident că viteza a fost limitată de subsistemul de disc al serverului de backup, similar cu exemplul cu . Doar puțin mai rapid, deoarece scrierea se face într-un singur fișier.
De asemenea, pentru a evalua compresia, vom rula aceeași variantă, dar vom activa compresia pe partea serverului de backup:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Rezultatele sunt următoarele:
Timpul de execuție a fost 10m11s. Cel mai probabil, problema este compressor-ul pe un singur fir de pe partea de primire.
Aceeași comandă, dar cu transferul compresiei pe server cu datele originale pentru a verifica ipoteza că punctul slab este compresorul de un singur fir.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"A ieșit așa:
Timpul de execuție a fost de 9m37s. Se vede clar încărcarea unui nucleu de către compresor, deoarece viteza de transmitere prin rețea și încărcarea subsistemului de disc sursă sunt asemănătoare.
Pentru a evalua criptarea, se pot folosi openssl sau gpg, conectând o comandă suplimentară openssl sau gpg în pipe. Ca orientare, va fi o comandă de acest tip:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Rezultatele au fost următoarele:
Timpul de execuție a fost de 10m30s, deoarece au fost lansate 2 procese pe partea de primire – din nou, punctul slab este compresorul de un singur fir, plus unele costuri suplimentare pentru criptare.
UPD: La cererea lui bliznezz, adaug teste cu pigz. Dacă folosim doar compresorul – a fost obținut în 6m30s, dacă adăugăm și criptarea – aproximativ 7m. Prăbușirea din graficul de mai jos – cache-ul de disc neșters:
Testarea duplicity
Duplicity – software pe Python pentru backup prin crearea de arhive criptate în format tar.
Pentru arhivele incrementale se folosește librsync, prin urmare, se poate anticipa un comportament descris în .
Copiile de siguranță pot fi criptate și semnate cu ajutorul gnupg, ceea ce este important atunci când folosiți diferiți furnizori pentru stocarea copiilor de siguranță (s3, backblaze, gdrive etc.)
Să vedem ce rezultate vor fi:
Iată rezultatele obținute la execuția fără criptare
spoiler
Timpul de execuție pentru fiecare test:
Execuție 1
Execuție 2
Execuție 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Iată rezultatele cu criptarea gnupg activată, cu dimensiunea cheii de 2048 de biți:
Timpul de lucru cu aceleași date, cu criptare:
Execuție 1
Execuție 2
Execuție 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
S-a specificat dimensiunea blocului – 512 megabytes, ceea ce se observă clar pe grafice; încărcarea procesorului s-a menținut practic la nivelul de 50%, deci programul utilizează nu mai mult de un nucleu de procesor.
De asemenea, se observă destul de bine principiul de funcționare al programului: s-a luat un fragment de date, s-a comprimat, s-a trimis pe serverul de stocare a copiilor de siguranță care poate fi destul de lent.
O altă caracteristică – timpul de lucru previzibil al programului, care depinde doar de dimensiunea datelor modificate.
Activarea criptării nu a crescut semnificativ timpul de execuție al programului, dar a crescut încărcarea CPU-ului cu aproximativ 10%, ceea ce poate fi un bonus destul de plăcut.
Din păcate, acest program nu a reușit să detecteze corect situația de redenumire a directorului, iar dimensiunea rezultată a reposito irului a fost egală cu dimensiunea modificărilor (adică toți cei 18GB), dar capacitatea de a utiliza un server nesigur pentru backup acoperă fără îndoială acest comportament.
Testare duplicati
Această aplicație este scrisă în C# și rulează folosind un set de biblioteci de la Mono. Există o versiune GUI, precum și una cli.
Lista aproximativă a funcțiilor principale este apropiată de duplicity, inclusiv diferiți furnizori pentru stocarea backup-urilor, însă, spre deosebire de duplicity, majoritatea funcțiilor sunt disponibile fără instrumente externe. Dacă este un avantaj sau un dezavantaj depinde de context, dar pentru începători, cel mai probabil, este mai simplu să aibă lista tuturor funcțiilor disponibile dintr-o dată, decât să instaleze pachete pentru python, ca în cazul duplicity.
Un alt mic detaliu - programul scrie activ o bază de date locală sqlite din numele utilizatorului care pornește backup-ul, așa că trebuie să acordați o atenție suplimentară specificării corecte a bazei necesare la fiecare pornire a procesului utilizând cli. Atunci când lucrați prin GUI sau WEBGUI, detaliile vor fi ascunse utilizatorului.
Să vedem ce rezultate poate oferi această soluție:
Dacă dezactivezi criptarea (deși WEBGUI nu recomandă acest lucru), rezultatele sunt următoarele:
Timpul de lucru:
Execuție 1
Execuție 2
Execuție 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Cu criptarea activată, folosind aes, rezultatele sunt următoarele:
Timpul de lucru:
Execuție 1
Execuție 2
Execuție 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Iar dacă folosești programul extern gnupg, iată rezultatele:
Execuție 1
Execuție 2
Execuție 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
După cum se vede, programul poate rula în mai multe fire de execuție, dar nu devine o soluție mai performantă, iar comparând executarea criptării - lansarea programului extern
s-a dovedit a fi mai rapidă decât utilizarea bibliotecii din setul Mono. Este posibil ca acest lucru să se datoreze faptului că programul extern este mai bine optimizat.
Un aspect plăcut a fost și faptul că dimensiunea depozitului ocupă exact atât cât au fost datele modificate, adică duplicati a detectat redenumirea directorului și a gestionat corect această situație. Acest lucru poate fi observat în timpul celei de-a doua teste.
În general, impresiile sunt destul de pozitive despre program, inclusiv prietenia suficientă față de începători.
Rezultate
Ambele soluții au funcționat destul de lent, dar, în general, comparativ cu tar-ul obișnuit, există progrese, cel puțin în cazul duplicati. Prețul acestui progres este, de asemenea, clar — o sarcină semnificativă asupra
procesorului. În general, nu sunt abateri speciale în prognozarea rezultatelor.
Conclusions
Dacă nu există o grabă, iar procesorul are resurse suficiente — oricare dintre soluțiile discutate este potrivită; cu siguranță s-a efectuat o muncă destul de mare, care nu merită repetată prin scrierea de scripturi de învăluire peste tar. Existența criptării este o caracteristică foarte necesară, dacă serverul pentru stocarea copiilor de rezervă nu poate fi pe deplin de încredere.
Comparând cu soluțiile bazate pe — performanța poate fi de câteva ori mai slabă, cu toate că, în forma sa pură, tar a funcționat mai repede decât rsync cu 20-30%.
Există economii la dimensiunea depozitului, dar doar la duplicati.
Anunț
Backup, partea 3: Prezentare generală și testare a duplicity, duplicati, 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 Demkovich
Sursa: habr.com
