Acest articol va lua în considerare software-ul de backup care, împărțind fluxul de date în componente separate (bucăți), formează un depozit.
Componentele depozitului pot fi comprimate și criptate în continuare și, cel mai important - în timpul proceselor de backup repetate - pot fi reutilizate.
O copie de rezervă într-un astfel de depozit este un lanț numit de componente conectate între ele, de exemplu, pe baza diferitelor funcții hash.
Există mai multe soluții similare, mă voi concentra pe 3: zbackup, borgbackup și restic.
Rezultate așteptate
Deoarece toți solicitanții necesită crearea unui depozit într-un fel sau altul, unul dintre cei mai importanți factori va fi estimarea dimensiunii depozitului. În mod ideal, dimensiunea sa nu ar trebui să depășească 13 GB, conform metodologiei acceptate, sau chiar mai puțin - sub rezerva unei bune optimizări.
De asemenea, este foarte de dorit să puteți crea copii de rezervă ale fișierelor direct, fără a utiliza arhivare precum tar, precum și să lucrați cu ssh/sftp fără instrumente suplimentare precum rsync și sshfs.
Comportament la crearea copiilor de rezervă:
- Dimensiunea depozitului va fi egală cu dimensiunea modificărilor sau mai mică.
- Este de așteptat o încărcare mare a procesorului atunci când se utilizează compresia și/sau criptarea și este probabil o încărcare destul de mare a rețelei și a discului dacă procesul de arhivare și/sau criptare rulează pe un server de stocare de rezervă.
- Dacă depozitul este deteriorat, este probabil o eroare întârziată atât la crearea unor copii de rezervă noi, cât și la încercarea de a restaura. Este necesar să se planifice măsuri suplimentare pentru a asigura integritatea depozitului sau să se utilizeze instrumente încorporate pentru verificarea integrității acestuia.
Lucrarea cu gudron este luată ca valoare de referință, așa cum sa arătat în unul dintre articolele anterioare.
Testarea zbackup
Mecanismul general al zbackup este că programul găsește în fluxul de date de intrare zone care conțin aceleași date, apoi opțional le comprimă și le criptează, salvând fiecare zonă o singură dată.
Deduplicarea folosește o funcție hash inel pe 64 de biți cu o fereastră glisantă pentru a verifica potrivirile octet cu octet cu blocurile de date existente (similar cu modul în care rsync o implementează).
Lzma și lzo cu mai multe fire sunt utilizate pentru compresie, iar aes pentru criptare. Cele mai recente versiuni au capacitatea de a șterge datele vechi din depozit în viitor.
Programul este scris în C++ cu dependențe minime. Autorul a fost aparent inspirat de modul unix, așa că programul acceptă date pe stdin atunci când creează copii de rezervă, producând un flux de date similar pe stdout la restaurare. Astfel, zbackup poate fi folosit ca un „bloc de bază” foarte bun atunci când scrieți propriile soluții de backup. De exemplu, autorul articolului a folosit acest program ca instrument principal de rezervă pentru mașinile de acasă din aproximativ 2014.
Fluxul de date va fi un gudron obișnuit, dacă nu se specifică altfel.
Să vedem care sunt rezultatele:
Lucrarea a fost verificată în 2 opțiuni:
- se creează un depozit și se lansează zbackup pe server cu datele sursă, apoi conținutul depozitului este transferat pe serverul de stocare de rezervă.
- un depozit este creat pe serverul de stocare de rezervă, zbackup este lansat prin ssh pe serverul de stocare de rezervă și datele sunt trimise către acesta prin pipe.
Rezultatele primei opțiuni au fost următoarele: 43m11s - la utilizarea unui depozit necriptat și a compresorului lzma, 19m13s - la înlocuirea compresorului cu lzo.
Încărcarea pe server cu datele originale a fost după cum urmează (este afișat un exemplu cu lzma; cu lzo a fost aproximativ aceeași imagine, dar cota de rsync a fost de aproximativ un sfert din timp):
Este clar că un astfel de proces de backup este potrivit doar pentru modificări relativ rare și mici. De asemenea, este foarte recomandabil să limitați zbackup la 1 fir, altfel va exista o încărcare foarte mare a procesorului, deoarece Programul este foarte bun la lucrul în mai multe fire. Sarcina de pe disc a fost mică, ceea ce, în general, nu ar fi vizibil cu un subsistem de disc modern bazat pe ssd. De asemenea, puteți vedea clar începutul procesului de sincronizare a datelor din depozit la un server la distanță; viteza de funcționare este comparabilă cu rsync-ul obișnuit și depinde de performanța subsistemului de disc al serverului de stocare de rezervă. Dezavantajul acestei abordări este stocarea unui depozit local și, ca urmare, duplicarea datelor.
Mai interesantă și aplicabilă în practică este a doua opțiune, rulând zbackup direct pe serverul de stocare de rezervă.
Mai întâi, vom testa funcționarea fără a folosi criptarea cu compresorul lzma:
Timpul de rulare al fiecărei rulări de testare:
Lansare 1
Lansare 2
Lansare 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Dacă activați criptarea folosind aes, rezultatele sunt destul de apropiate:
Timp de funcționare pe aceleași date, cu criptare:
Lansare 1
Lansare 2
Lansare 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Dacă criptarea este combinată cu compresia folosind lzo, arată astfel:
Orar:
Lansare 1
Lansare 2
Lansare 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Dimensiunea depozitului rezultat a fost relativ aceeași la 13 GB. Aceasta înseamnă că deduplicarea funcționează corect. De asemenea, pe datele deja comprimate, folosirea lzo dă un efect notabil; în ceea ce privește timpul total de funcționare, zbackup se apropie de duplicity/duplicati, dar rămâne în urma celor bazate pe librsync de 2-5 ori.
Avantajele sunt evidente - economisirea de spațiu pe disc pe serverul de stocare de rezervă. În ceea ce privește instrumentele de verificare a depozitelor, autorul zbackup nu le furnizează; se recomandă utilizarea unei matrice de discuri tolerante la erori sau a unui furnizor de cloud.
Per total, o impresie foarte bună, în ciuda faptului că proiectul a rămas nemișcat de aproximativ 3 ani (ultima cerere de caracteristici a fost acum aproximativ un an, dar fără răspuns).
Testarea borgbackup
Borgbackup este o furcă de mansardă, un alt sistem similar cu zbackup. Scris în python, are o listă de capabilități similare cu zbackup, dar în plus poate:
- Montați copii de rezervă prin siguranță
- Verificați conținutul depozitului
- Lucrați în modul client-server
- Utilizați diverse compresoare pentru date, precum și determinarea euristică a tipului de fișier atunci când îl comprimați.
- 2 opțiuni de criptare, aes și blake
- Instrument încorporat pt
verificări de performanță
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Rezultatele au fost următoarele:
CZ-BIG 96.51 MB/s (10 100.00 MB fișiere zero: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB fișiere zero: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB fișiere zero: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB fișiere zero: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB fișiere aleatorii: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB fișiere aleatorii: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB fișiere aleatorii: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB fișiere aleatorii: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB fișiere zero: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB fișiere zero: 13.13 s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB fișiere zero: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB fișiere zero: 2.58 s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB fișiere aleatorii: 26.45 s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB fișiere aleatorii: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB fișiere aleatorii: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB fișiere aleatorii: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB fișiere zero: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB fișiere zero: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB fișiere zero: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB fișiere zero: 2.97 s)
CR-SMALL 6.85 MB/s (10000 10.00 kB fișiere aleatorii: 14.60 s)
RR-MIC 31.27 MB/s (10000 10.00 kB fișiere aleatorii: 3.20 s)
UR-SMALL 12.28 MB/s (10000 10.00 kB fișiere aleatorii: 8.14 s)
DR-SMALL 18.78 MB/s (10000 10.00 kB fișiere aleatorii: 5.32 s)
La testare, euristica de compresie va fi utilizată pentru a determina tipul de fișier (compresie automată), iar rezultatele vor fi următoarele:
Mai întâi, să verificăm cum funcționează fără criptare:
Orar:
Lansare 1
Lansare 2
Lansare 3
4m6s
4m10s
4m5s
Anii 56
Anii 58
Anii 54
1m26s
1m34s
1m30s
Dacă activați autorizarea depozitului (modul autentificat), rezultatele vor fi apropiate:
Orar:
Lansare 1
Lansare 2
Lansare 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Când criptarea aes a fost activată, rezultatele nu s-au deteriorat prea mult:
Lansare 1
Lansare 2
Lansare 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Și dacă schimbați aes cu blake, situația se va îmbunătăți complet:
Orar:
Lansare 1
Lansare 2
Lansare 3
4m33s
4m43s
4m40s
Anii 59
1m0s
1m0s
1m38s
1m43s
1m40s
Ca și în cazul zbackup, dimensiunea depozitului a fost de 13 GB și chiar puțin mai puțin, ceea ce este de așteptat în general. Am fost foarte mulțumit de timpul de rulare; este comparabil cu soluțiile bazate pe librsync, oferind capabilități mult mai largi. De asemenea, am fost mulțumit de capacitatea de a seta diferiți parametri prin variabilele de mediu, ceea ce oferă un avantaj foarte serios atunci când utilizați borgbackup în modul automat. De asemenea, am fost mulțumit de încărcarea în timpul copiei de rezervă: judecând după încărcarea procesorului, borgbackup funcționează într-un singur thread.
Nu au existat dezavantaje deosebite la utilizarea acestuia.
testare restică
În ciuda faptului că restic este o soluție destul de nouă (primii 2 candidați erau cunoscuți încă din 2013 și mai vechi), are caracteristici destul de bune. Scris în Go.
În comparație cu zbackup, oferă în plus:
- Verificarea integrității depozitului (inclusiv verificarea părților).
- O listă uriașă de protocoale și furnizori acceptați pentru stocarea backup-urilor, precum și suport pentru rclone - rsync pentru soluții cloud.
- Comparând 2 copii de rezervă între ele.
- Montarea depozitului prin siguranța.
În general, lista de caracteristici este destul de apropiată de borgbackup, în unele locuri mai mult, în altele mai puțin. Una dintre caracteristici este că nu există nicio modalitate de a dezactiva criptarea și, prin urmare, copiile de rezervă vor fi întotdeauna criptate. Să vedem în practică ce poate fi stors din acest software:
Rezultatele au fost următoarele:
Orar:
Lansare 1
Lansare 2
Lansare 3
5m25s
5m50s
5m38s
Anii 35
Anii 38
Anii 36
1m54s
2m2s
1m58s
Rezultatele de performanță sunt, de asemenea, comparabile cu soluțiile bazate pe rsync și, în general, foarte apropiate de borgbackup, dar sarcina procesorului este mai mare (executarea mai multor fire) și cu dinte de ferăstrău.
Cel mai probabil, programul este limitat de performanța subsistemului de disc pe serverul de stocare a datelor, așa cum a fost deja cazul cu rsync. Dimensiunea depozitului a fost de 13 GB, la fel ca zbackup sau borgbackup, nu au existat dezavantaje evidente la utilizarea acestei soluții.
Constatări
De fapt, toți candidații au obținut rezultate similare, dar la prețuri diferite. Borgbackup a funcționat cel mai bine, restic a fost puțin mai lent, probabil că zbackup nu merită să începeți să îl utilizați,
iar dacă este deja utilizat, încercați să îl schimbați în borgbackup sau restic.
Constatări
Cea mai promițătoare soluție pare a fi liniștită, pentru că... el este cel care are cel mai bun raport dintre capacități și viteza de operare, dar să nu ne grăbim să ajungem la concluzii generale deocamdată.
Borgbackup nu este practic mai rău, dar zbackup este probabil mai bine înlocuit. Adevărat, zbackup poate fi folosit în continuare pentru a se asigura că regula 3-2-1 funcționează. De exemplu, pe lângă facilitățile de backup bazate pe (lib)rsync.
Anunţ
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