Această notă discută instrumentele de backup care efectuează copii de rezervă prin crearea de arhive pe un server de rezervă.
Printre cele care îndeplinesc cerințele se numără duplicity (care are o interfață drăguță sub formă de deja dup) și duplicati.
Un alt instrument de backup foarte remarcabil este dar, dar din moment ce are o listă foarte extinsă de opțiuni - metodologia de testare acoperă abia 10% din ceea ce este capabil - nu îl testăm ca parte a ciclului actual.
Rezultate așteptate
Deoarece ambii candidați creează arhive într-un fel sau altul, gudronul obișnuit poate fi folosit ca ghid.
În plus, vom evalua cât de bine este optimizată stocarea datelor pe serverul de stocare prin crearea de copii de rezervă care să conțină doar diferența dintre o copie completă și starea curentă a fișierelor, sau între arhivele anterioare și actuale (incrementale, decrementale etc.) .
Comportament la crearea copiilor de rezervă:
- Un număr relativ mic de fișiere pe serverul de stocare de rezervă (comparabil cu numărul de copii de rezervă sau cu dimensiunea datelor în GB), dar dimensiunea lor este destul de mare (de la zeci până la sute de megaocteți).
- Dimensiunea depozitului va include doar modificări - nu vor fi stocate duplicate, astfel încât dimensiunea depozitului va fi mai mică decât în cazul software-ului bazat pe rsync.
- Așteptați-vă la o încărcare mare a procesorului atunci când utilizați compresia și/sau criptarea și probabil o sarcină destul de mare a rețelei și a discului dacă procesul de arhivare și/sau criptare rulează pe un server de stocare de rezervă.
Să rulăm următoarea comandă ca valoare de referință:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Rezultatele executiei au fost urmatoarele:
Timp de execuție 3m12s. Se poate observa că viteza este limitată de subsistemul de disc al serverului de stocare de rezervă, ca în exemplul cu . Doar puțin mai repede, pentru că... înregistrarea merge într-un singur fișier.
De asemenea, pentru a evalua compresia, să rulăm aceeași opțiune, dar să activăm compresia pe partea serverului de rezervă:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Rezultatele sunt:
Timp de execuție 10m11s. Cel mai probabil blocajul este compresorul cu un singur flux de la capătul de recepție.
Aceeași comandă, dar cu compresie transferată pe server cu datele originale pentru a testa ipoteza că blocajul este un compresor cu 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. Sarcina pe un miez de către compresor este clar vizibilă, deoarece Viteza de transfer al rețelei și încărcarea pe subsistemul discului sursă sunt similare.
Pentru a evalua criptarea, puteți utiliza openssl sau gpg conectând o comandă suplimentară openssl sau gpg în conductă. Pentru referință, va exista o comandă ca aceasta:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Rezultatele au ieșit astfel:
Timpul de execuție s-a dovedit a fi de 10m30s, deoarece 2 procese rulau pe partea de recepție - blocajul este din nou un compresor cu un singur fir, plus o mică suprasarcină de criptare.
UPD: La cererea bliznezz adaug teste cu pigz. Daca folosesti doar compresorul ar dura 6m30s, daca adaugi si criptare ar fi cam 7m. Scăderea din graficul de jos este o memorie cache a discului neevașată:
Testare duplicat
Duplicity este un software python pentru backup prin crearea de arhive criptate în format tar.
Pentru arhivele incrementale, se folosește librsync, așa că vă puteți aștepta la comportamentul descris în .
Backup-urile pot fi criptate și semnate folosind gnupg, ceea ce este important atunci când folosiți diferiți furnizori pentru stocarea backup-urilor (s3, backblaze, gdrive etc.)
Să vedem care sunt rezultatele:
Acestea sunt rezultatele pe care le-am obținut când rulăm fără criptare
spoiler
Timpul de rulare al fiecărei rulări de testare:
Lansare 1
Lansare 2
Lansare 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Și iată rezultatele când criptarea gnupg este activată, cu o dimensiune a cheii de 2048 de biți:
Timp de funcționare pe aceleași date, cu criptare:
Lansare 1
Lansare 2
Lansare 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Dimensiunea blocului a fost indicată - 512 megaocteți, ceea ce este clar vizibil în grafice; Sarcina procesorului a rămas de fapt la 50%, ceea ce înseamnă că programul nu utilizează mai mult de un nucleu de procesor.
Principiul funcționării programului este, de asemenea, destul de clar vizibil: au luat o bucată de date, au comprimat-o și au trimis-o la un server de stocare de rezervă, care poate fi destul de lent.
O altă caracteristică este durata de rulare previzibilă a programului, care depinde doar de dimensiunea datelor modificate.
Activarea criptării nu a crescut semnificativ timpul de rulare al programului, dar a crescut încărcarea procesorului cu aproximativ 10%, ceea ce poate fi un bonus destul de frumos.
Din păcate, acest program nu a reușit să detecteze corect situația cu redenumirea directorului, iar dimensiunea depozitului rezultată s-a dovedit a fi egală cu dimensiunea modificărilor (adică, toate cele 18 GB), dar capacitatea de a utiliza un server neîncrezat pentru backup în mod clar acoperă acest comportament.
Testare duplicat
Acest software este scris în C# și rulează folosind un set de biblioteci de la Mono. Există o versiune GUI, precum și o versiune CLI.
Lista aproximativă a principalelor caracteristici este similară cu duplicitatea, inclusiv diverși furnizori de stocare de rezervă, cu toate acestea, spre deosebire de duplicitate, majoritatea funcțiilor sunt disponibile fără instrumente terțe. Dacă acesta este un plus sau un minus depinde de cazul specific, dar pentru începători, cel mai probabil este mai ușor să aibă o listă cu toate caracteristicile în fața lor deodată, mai degrabă decât să fie nevoie să instaleze pachete suplimentare pentru python, așa cum este cazul cu duplicitatea.
O altă nuanță mică - programul scrie în mod activ o bază de date sqlite locală în numele utilizatorului care pornește backup-ul, așa că trebuie să vă asigurați suplimentar că baza de date necesară este specificată corect de fiecare dată când procesul este pornit folosind cli. Când lucrați prin GUI sau WEBGUI, detaliile vor fi ascunse utilizatorului.
Să vedem ce indicatori poate produce această soluție:
Dacă dezactivați criptarea (și WEBGUI nu recomandă să faceți acest lucru), rezultatele sunt următoarele:
Orar:
Lansare 1
Lansare 2
Lansare 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Cu criptarea activată, folosind aes, arată astfel:
Orar:
Lansare 1
Lansare 2
Lansare 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Și dacă utilizați programul extern gnupg, apar următoarele rezultate:
Lansare 1
Lansare 2
Lansare 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
După cum puteți vedea, programul poate funcționa în mai multe fire, dar acest lucru nu îl face o soluție mai productivă, iar dacă comparați munca de criptare, lansează un program extern.
s-a dovedit a fi mai rapid decât utilizarea bibliotecii din setul Mono. Acest lucru se poate datora faptului că programul extern este mai optimizat.
Un punct plăcut a fost, de asemenea, faptul că dimensiunea depozitului ia exact la fel de mult ca datele reale modificate, de exemplu. duplicati a detectat o redenumire a directorului și a gestionat corect această situație. Acest lucru poate fi văzut la rularea celui de-al doilea test.
În general, impresii destul de pozitive ale programului, inclusiv a fi destul de prietenos cu începătorii.
Constatări
Ambii candidați au lucrat destul de încet, dar în general, în comparație cu gudronul obișnuit, există progrese, cel puțin cu duplicati. Prețul unui astfel de progres este, de asemenea, clar - o povară vizibilă
procesor. În general, nu există abateri speciale în prezicerea rezultatelor.
Constatări
Dacă nu ai nevoie să te grăbești nicăieri și, de asemenea, ai un procesor de rezervă, oricare dintre soluțiile luate în considerare va face, în orice caz, s-a făcut destul de multă muncă care nu ar trebui să fie repetată prin scrierea de scripturi wrapper deasupra tarului . Prezența criptării este o proprietate foarte necesară dacă serverul pentru stocarea copiilor de rezervă nu poate fi pe deplin de încredere.
În comparație cu soluții bazate - performanța poate fi de câteva ori mai proastă, în ciuda faptului că, în forma sa pură, gudronul a funcționat cu 20-30% mai rapid decât rsync.
Există economii la dimensiunea depozitului, dar numai cu duplicati.
Anunţ
Backup Partea 3: Revizuirea și testarea duplicității, duplicatiilor, deja dup
Backup Partea 4: Zbackup, restic, revizuire și testare borgbackup
Backup, partea 5: Testarea bacula și veeam backup pentru Linux
Backup Partea 6: Comparația instrumentelor de backup
Backup Partea 7: Concluzii
Postat de: Pavel Demkovici
Sursa: www.habr.com