— este un utilitar gratuit și open-source de deduplicare — un utilitar similar unui arhivator, care permite reducerea semnificativă a dimensiunii backup-urilor, precum și organizarea schemelor de backup incremental și diferențial și nu numai.
Aceasta este o articol de prezentare care descrie capabilitățile. Utilizarea hashget (destul de simplă) este descrisă în al proiectului și .
Comparare
Ca pe orice subiect, voi începe cu o intrigă — compararea rezultatelor:
Exemplu de date
dimensiunea desfășurată
.tar.gz
hashget .tar.gz
WordPress-5.1.1
43 Mb
11 Mb (26%)
155 Kb ( 0.3% )
Linux kernel 5.0.4
934 Mb
161 Mb (20%)
4.7 Mb ( 0.5% )
Debian 9 (LAMP) LXC VM
724 Mb
165 Mb (23%)
4.1 Mb ( 0.5% )
Povestea de fundal despre cum ar trebui să fie un backup ideal și eficient
De fiecare dată când realizam un backup al unei mașini virtuale proaspăt create, mă urmărea sentimentul că fac ceva greșit. De ce obțin un backup greu de sistem, unde creația mea neprețuită este un simplu index.html cu textul „Hello world”?
De ce în backup-ul meu există un /usr/sbin/mysqld de 16 megabaiți? Este cu adevărat responsabilitatea mea să salvez acest fișier important, iar dacă nu reușesc — el va fi pierdut pentru umanitate? Probabil că nu. Este stocat pe servere Debian de înaltă fiabilitate (fiabilitatea și continuitatea cărora nu se compară cu ceea ce pot oferi eu), și, de asemenea, în copiile de rezervă (în milioane) ale altor administratori. Este realmente necesar să creăm pentru sporirea fiabilității încă 10.000.000 + 1 copie a acestui fișier important?
În general, acesta rezolvă această problemă. La arhivare — creează un backup foarte mic. La desfășurare — un sistem complet desfășurat, similar celui care ar fi la tar -c / tar -x. (Cu alte cuvinte, este o arhivare fără pierderi)
Cum funcționează hashget
În hashget există conceptele de Package și HashPackage, cu ajutorul cărora acesta realizează deduplicarea.
Package (pachet). Un fișier (de obicei un arhiv .deb sau .tar.gz) care poate fi descărcat în siguranță din rețea, și din care se pot obține unul sau mai multe fișiere.
HashPackage — un fișier JSON mic care reprezintă Package, incluzând URL-ul pachetului și sumele hash (sha256) ale fișierelor din acesta. De exemplu, pentru pachetul mariadb-server-core cu o dimensiune de 5 megabaiți, dimensiunea hashpackage este doar 6 kilobytes. Aproape de o mie de ori mai mic.
Deduplicarea — crearea unui arhiv fără fișiere duplicate (dacă deduplicatorul știe de unde poate fi descărcat originalul pachet, reduce duplicatele din arhivă).
Arhivarea
Când se împachetează, toate fișierele din directorul de ambalare sunt examinate, iar sumerele lor hash sunt calculate. Dacă o sumă este găsită într-unul dintre HashPackage cunoscute, metadatele despre fișier (nume, hash, permisiuni etc.) sunt salvate într-un fișier special .hashget-restore.json, care va fi de asemenea inclus în arhivă.
Împachetarea propriu-zisă, în cel mai simplu caz, nu este mai complicată decât tarul:
hashget -zf /tmp/mybackup.tar.gz --pack /path/to/dataDesfășurare
Dezpackul se face în două etape. Mai întâi, dezpakare obișnuită tar:
tar -xf mybackup.tar.gz -C /path/to/dataapoi, restaurarea din rețea:
hashget -u /path/to/dataLa restaurare, hashget citeste fișierul .hashget-restore.json, descarcă pachetele necesare, le dezambalează și extrage fișierele dorite, instalându-le pe căile corecte, cu proprietarii/grupurile/permisiunile necesare.
Lucruri mai complexe
Ceea ce am descris mai sus este destept suficient pentru cei care "vrea ca tarul, dar să-mi ambaleze Debianul în 4 megabytes." Mai departe, vom explora lucruri mai complexe.
Indexare
Dacă hashget nu ar fi avut niciun HashPackage, el pur și simplu nu ar fi putut deduplicara nimic.
Puteți crea un HashPackage și manual (simplu: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), dar există o cale mai convenabilă.
Pentru a obține hashpackagele dorite, există o etapă de indexare (care se efectuează automat la comanda --pack) și heuristici. La indexare, hashget "alimentează" fiecare fișier găsit tuturor heuristicilor disponibile de care este interesat. Heuristicile pot apoi să indexeze un anumit Pachet pentru a crea HashPackage.
De exemplu, heuristica Debian îi place fișierul /var/lib/dpkg/status și descoperă pachetele Debian instalate, iar dacă acestea nu sunt indexate (HashPackage nu a fost creat pentru ele), le descarcă și le indexează. Rezultatul este un efect foarte plăcut — hashget va deduplica întotdeauna eficient sistemele Debian, chiar dacă au cele mai noi pachete.
Fișiere hint (sugestii)
Dacă în rețeaua dumneavoastră folosiți un pachet proprietar sau un pachet public care nu este inclus în heuristicile hashget, puteți adăuga un simplu fișier hint hashget-hint.json după modelul:
{
"project": "wordpress.org",
"url": "https://ro.wordpress.org/wordpress-5.1.1-ro_RO.zip"
}Apoi, de fiecare dată când se creează un arhivă, pachetul va fi indexat (dacă nu a fost indexat anterior), iar fișierele pachetului vor fi deduplicate din arhivă. Nu este nevoie de programare, totul se poate face din vim și se poate economisi la fiecare backup. Observați că, datorită abordării prin checksum-uri, dacă unele fișiere din pachet sunt modificate local (de exemplu, un fișier de configurare modificat) — atunci fișierele modificate vor fi păstrate în arhivă „așa cum sunt” fără a fi reduse.
Dacă un pachet propriu este actualizat periodic, dar modificările nu sunt foarte mari, se poate face un indiciu numai pentru versiunile principale. De exemplu, în versiunea 1.0 a fost realizat un indiciu referitor la mypackage-1.0.tar.gz, și aceasta va fi complet deduplicată, apoi a fost lansată versiunea 1.1, care diferă puțin, iar indiciul nu a fost actualizat. Nici o problemă. Se deduplica doar fișierele care corespund (care pot fi restaurate) cu versiunea 1.0.
Heuristica care procesează fișierul hint — un bun exemplu pentru înțelegerea mecanismului intern de funcționare al heuristicilor. Acesta procesează doar fișierele hashget-hint.json (sau .hashget-hint.json cu punct) și ignoră toate celelalte. În baza acestui fișier, acesta determină ce URL al pachetului trebuie indexat, iar hashget îl indexează (dacă nu a fost făcut anterior).
HashServer
Ar fi destul de laborios să se efectueze complet indexarea în timpul creării backup-urilor. Pentru aceasta, trebuie să se descarce fiecare pachet, să fie dezarhivat, să fie indexat. De aceea, hashget utilizează o schemă cu . La descoperirea unui pachet Debian instalat, dacă acesta nu se găsește în HashPackage-urile locale, se încearcă mai întâi să se descarce simplu HashPackage de la serverul de hash. Și doar dacă acest lucru nu reușește — hashget descarcă și hash-ează pachetul (și îl încarcă pe hashserver, pentru ca ulterior hashserver să-l ofere).
HashServer — nu este un element obligatoriu al schemei, nu este critic, servește exclusiv pentru accelerarea și reducerea încărcăturii pe repozitorii. Se poate dezactiva cu ușurință (opțiunea --hashserver fără parametrii). În plus, este ușor să .
Backup-urile incrementale și diferențiale, expirarea programată
permit foarte simplu realizarea unei scheme De ce să nu indexăm backup-ul nostru (cu toate fișierele noastre unice)? O singură comandă --submit Și totul este gata! Următorul backup pe care îl va crea hashget nu va include fișierele din acest arhivă.
Dar acesta nu este un mod foarte bun, deoarece s-ar putea să ne confruntăm cu situația în care, la restaurare, va trebui să manipulăm toate backup-urile hashget din întreaga istorie (dacă în fiecare va fi cel puțin un fișier unic). Pentru aceasta există un mecanism . La indexare, se poate specifica o dată de expirare pentru HashPackage --expires 2019-06-01, și după această dată (de la 00:00), nu va mai fi utilizat. Arhiva în sine poate fi păstrată după această dată (deși hashget poate afișa convenabil URL-urile tuturor backup-urilor care ne-au expirat sau vor expira în acel moment sau la orice dată).
De exemplu, dacă pe data de 1 facem un backup complet și îl indexăm cu o durată de viață până la sfârșitul lunii — vom obține un plan de backup diferențial.
Dacă vom indexa și noile backup-uri în același mod — va fi un plan de backup incremental.
Spre deosebire de schemele tradiționale, hashget permite utilizarea mai multor surse de bază. Backup-ul va fi redus atât datorită scurtării fișierelor din backup-urile anterioare (dacă există), cât și datorită fișierelor publice (cele care pot fi descărcate).
Dacă dintr-un anumit motiv nu avem încredere în fiabilitatea resurselor debian () sau folosim o altă distribuție, putem face o singură dată un backup complet cu toate pachetele și ulterior ne putem baza pe acesta (). Acum, dacă toate serverele distribuțiilor noastre devin inaccesibile (în internetul souvenir sau în cazul unui apocalips zombie), dar backup-urile noastre sunt în ordine — ne putem restaura din orice scurt backup diferențial, bazându-ne doar pe backup-urile noastre anterioare.
Hashget se bazează doar pe surse de recuperare fiabile la DISCREȚIA DUMNEAVOASTRĂ. Ce considerați că este fiabil — aceea va fi utilizată.
FilePool și Glacier
Mecanismul permite să nu apelăm constant la serverele externe pentru descărcarea pachetelor, ci să utilizăm pachete dintr-un director local sau de pe un server corporativ, de exemplu:
$ hashget -u . --pool /tmp/poolsau
$ hashget -u . --pool http://myhashdb.example.com/Pentru a crea un pool în directorul local, este suficient să creați un director și să adăugați fișiere, hashget va găsi ceea ce are nevoie pe baza hash-urilor. Pentru a face pool-ul disponibil prin HTTP, trebuie să creați linkuri simbolice într-un mod special, acest lucru se face cu o singură comandă (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). HTTP FilePool-ul constă în fișiere statice, astfel încât poate fi gestionat de orice server web simplu, iar sarcina pe server este aproape zero.
Datorită FilePool-ului, resursele de bază pot fi utilizate nu doar de resurse http(s), ci și, , Amazon Glacier.
După ce am încărcat backup-ul pe Glacier, obținem ID-ul de încărcare și îl folosim ca URL. De exemplu:
hashget --submit Glacier_Upload_ID --file /tmp/my-glacier-backup.tar.gz --project glacier --hashserver --expires 2019-09-01Acum, noile backup-uri (diferentiale) se vor baza pe acest backup și vor fi mai scurte. După decompresia backup-ului diferențial, putem verifica pe ce resurse se bazează:
hashget --info /tmp/unpacked/ listși pur și simplu cu un script shell să descărcăm din Glacier toate aceste fișiere în pool și să lansăm restaurarea obișnuită: hashget -u /tmp/unpacked --pool /tmp/pool
Merită efortul?
În cel mai simplu caz, veți plăti pur și simplu mai puțin pentru backup-uri (dacă le stocați undeva în cloud contra cost). S-ar putea să plătiți mult-mult mai puțin.
Dar acesta nu este singurul beneficiu. Cantitatea se transformă în calitate. Puteți folosi asta pentru a obține o actualizare de calitate a schemei de backup-uri. De exemplu, având în vedere că backup-urile noastre sunt acum mai scurte, putem face backup-uri zilnice, nu lunare. Să le păstrăm nu șase luni, ca înainte, ci cinci ani. În trecut, le-am păstrat în depozite „reci” lente dar ieftine (Glacier), acum puteți păstra în depozite „calde”, de unde putem descărca rapid un backup și să ne restaurăm în câteva minute, nu în o zi.
Puteți crește fiabilitatea stocării backup-urilor. Dacă în prezent le stocăm într-un singur depozit, prin reducerea volumului backup-urilor, vom putea stoca în 2-3 depozite și să supraviețuim fără probleme în cazul în care unul dintre ele se deteriorează.
Cum să încercați și să începeți să folosiți?
Accesăm pagina de GitLab, , instalăm cu o singură comandă (pip3 install hashget[plugins]) și pur și simplu citim și urmăm ghidul rapid. Cred că tot ce este simplu de făcut — va dura aproximativ 10-15 minute. Apoi, putem încerca să comprimăm mașinile virtuale, să facem, dacă este necesar, fișiere de hint-uri pentru o comprimare și mai bună, să experimentăm cu pool-urile, baza locală de hash-uri și serverul de hash-uri, dacă ne va interesa, iar a doua zi să vedem care va fi dimensiunea backup-ului incremental pe lângă cel de ieri.
Sursa: habr.com
