Reduïu les còpies de seguretat en un 99.5% amb hashget

hashget - És gratuït i de codi obert deduplicador és una utilitat similar a un arxivador que us permet reduir significativament la mida de les còpies de seguretat, així com organitzar esquemes de còpies de seguretat incrementals i diferencials i molt més.

Aquest és un article general per descriure les característiques. L'ús real de hashget (bastant senzill) es descriu a README projecte i documentació wiki.

Comparació

D'acord amb la llei del gènere, començaré immediatament amb la intriga, comparant els resultats:

Mostra de dades
mida desempaquetat
.tar.gz
hashget.tar.gz

WordPress-5.1.1
43 Mb
11 Mb (26%)
155 Kb ( 0.3% )

Nucli de Linux 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% )

Antecedents sobre què hauria de ser una còpia de seguretat ideal i eficaç

Cada vegada que feia una còpia de seguretat d'una màquina virtual acabada de crear, em pertorbava la sensació que estava fent alguna cosa malament. Per què rebo una còpia de seguretat important del sistema, on la meva inestimable i imperible creativitat és un index.html d'una línia amb el text "Hola món"?

Per què hi ha un /usr/sbin/mysqld de 16 MB a la meva còpia de seguretat? És realment possible que en aquest món tingui l'honor de guardar aquest important arxiu, i si fracassem, es perdrà per a la humanitat? Molt probablement no. S'emmagatzema en servidors Debian altament fiables (la fiabilitat i el temps d'activitat dels quals no es poden comparar amb el que puc proporcionar), així com en còpies de seguretat (milions d'ells) d'altres administradors. Realment necessitem crear més de 10 de còpies 000 d'aquest important fitxer per millorar la fiabilitat?

En general hashget i resol aquest problema. Quan està empaquetat, crea una còpia de seguretat molt petita. Quan es desempaqueta: un sistema completament desempaquetat, similar al que seria si tar -c / tar -x. (En altres paraules, aquest és un embalatge sense pèrdues)

Com funciona hashget

hashget té els conceptes de Package i HashPackage, amb la seva ajuda realitza la deduplicació.

paquet (bossa de plàstic). Un fitxer (normalment un arxiu .deb o .tar.gz) que es pot descarregar d'Internet de manera segura i del qual es poden obtenir un o més fitxers.

HashPackage — un petit fitxer JSON que representa un paquet, inclòs l'URL del paquet i les sumes hash (sha256) dels fitxers d'aquest. Per exemple, per a un paquet mariadb-server-core de 5 megabytes, la mida del paquet hash només és de 6 kilobytes. Unes mil vegades menys.

Deduplicació — crear un arxiu sense fitxers duplicats (si el deduplicador sap on es pot descarregar el paquet original, redueix els duplicats de l'arxiu).

Embalatge

En empaquetar, s'escanegen tots els fitxers del directori que s'està empaquetant, es calculen les seves sumes hash i, si la suma es troba en un dels HashPackages coneguts, es desaran les metadades sobre el fitxer (nom, hash, drets d'accés, etc.). en un fitxer especial .hashget-restore.json, que també s'inclourà a l'arxiu.

En el cas més senzill, l'envàs en si no sembla més complicat que un quitrà:

hashget -zf /tmp/mybackup.tar.gz --pack /path/to/data

Desembalatge

El desembalatge es fa en dues etapes. Primer el desembalatge habitual de quitrà:

tar -xf mybackup.tar.gz -C /path/to/data

després restaurar des de la xarxa:

hashget -u /path/to/data

Quan es restaura, hashget llegeix el fitxer .hashget-restore.json, descarrega els paquets necessaris, els desempaqueta i extreu els fitxers necessaris, instal·lant-los als camins necessaris, amb el propietari/grup/permisos necessaris.

Coses més difícils

El que s'ha descrit anteriorment ja és suficient per a aquells que "ho volen com quitrà, però per empaquetar el meu Debian en 4 megabytes". Vegem coses més complexes més endavant.

Indexació

Si hashget no tingués cap HashPackage, simplement no podria desduplicar res.

També podeu crear un HashPackage manualment (simplement: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), però hi ha una manera més còmoda.

Per obtenir el paquet hash necessari, hi ha una etapa indexació (s'executa automàticament amb l'ordre --pack) I heurístics. En indexar, hashget "alimenta" cada fitxer trobat a totes les heurístiques disponibles que hi estiguin interessades. L'heurística pot indexar qualsevol paquet per crear un HashPackage.

Per exemple, l'heurística de Debian estima el fitxer /var/lib/dpkg/status i detecta els paquets debian instal·lats i, si no estan indexats (no hi ha HashPackage creat per a ells), els baixa i els indexa. El resultat és un efecte molt agradable: hashget sempre desduplicarà els sistemes operatius Debian de manera efectiva, fins i tot si tenen els paquets més recents.

Fitxers de pistes

Si la vostra xarxa utilitza alguns dels vostres paquets propietaris o un paquet públic que no s'inclou a les heurístiques de hashget, podeu afegir-hi un simple fitxer de suggeriments hashget-hint.json com aquest:

{
    "project": "wordpress.org",
    "url": "https://ru.wordpress.org/wordpress-5.1.1-ru_RU.zip"
}

A continuació, cada vegada que es creï un arxiu, el paquet s'indexarà (si no s'ha fet anteriorment) i els fitxers del paquet es desduplicaran de l'arxiu. No cal programar, tot es pot fer des de vim i guardar en cada còpia de seguretat. Tingueu en compte que gràcies a l'enfocament de la suma hash, si alguns fitxers del paquet es canvien localment (per exemple, es canvia un fitxer de configuració), els fitxers modificats es desaran a l'arxiu "tal com estan" i no es truncaran.

Si alguns dels vostres propis paquets s'actualitzen periòdicament, però els canvis no són molt grans, només podeu indicar les versions principals. Per exemple, a la versió 1.0 van fer una pista que apuntava a mypackage-1.0.tar.gz, i es desduplicarà completament, després van llançar la versió 1.1, que és lleugerament diferent, però la pista no es va actualitzar. Està bé. Només es desduplican els fitxers que coincideixen (es poden restaurar a) amb la versió 1.0.

L'heurística que processa el fitxer de suggeriments és un bon exemple per entendre el mecanisme intern de com funcionen les heurístiques. Només processa fitxers hashget-hint.json (o .hashget-hint.json amb un punt) i ignora tots els altres. A partir d'aquest fitxer, determina quin URL del paquet s'ha d'indexar i hashget l'indexa (si encara no ho ha fet)

HashServer

Seria força laboriós realitzar una indexació completa en crear còpies de seguretat. Per fer-ho, heu de descarregar cada paquet, desempaquetar-lo i indexar-lo. Per tant, hashget utilitza un esquema amb HashServer. Quan es detecta un paquet Debian instal·lat, si no es troba al HashPackage local, primer s'intenta descarregar el HashPackage des del servidor hash. I només si això no funciona, el mateix hashget descarrega i fa hash el paquet (i el puja a hashserver, de manera que hashserver el proporcioni en el futur).

HashServer és un element opcional de l'esquema, no crític, només serveix per accelerar i reduir la càrrega dels repositoris. Fàcilment desactivat (opcional --hashserver sense paràmetres). A més, pots fàcilment fes el teu propi servidor hash.

Còpies de seguretat incrementals i diferencials, obsolescència planificada

hashget fa que sigui molt fàcil fer un diagrama còpies de seguretat incrementals i diferencials. Per què no indexem la nostra pròpia còpia de seguretat (amb tots els nostres fitxers únics)? Un equip --submit i ja estàs! La propera còpia de seguretat que crea hashget no inclourà fitxers d'aquest arxiu.

Però aquest no és un enfocament molt bo, perquè pot resultar que en restaurar haurem de treure totes les còpies de seguretat hashget de tot l'historial (si cadascuna conté almenys un fitxer únic). Hi ha un mecanisme per a això obsolescència planificada de les còpies de seguretat. Quan indexeu, podeu especificar la data de caducitat de HashPackage --expires 2019-06-01, i després d'aquesta data (a partir de les 00:00), no s'utilitzarà. L'arxiu en si no es pot suprimir després d'aquesta data (tot i que hashget pot mostrar còmodament els URL de totes les còpies de seguretat que estan o estaran podrides en aquest moment o en qualsevol data).

Per exemple, si el dia 1 fem una còpia de seguretat completa i l'indexem amb una vida útil fins a finals de mes, obtindrem un esquema de còpia de seguretat diferencial.

Si indexem noves còpies de seguretat de la mateixa manera, hi haurà un esquema de còpies de seguretat incrementals.

A diferència dels esquemes tradicionals, hashget us permet utilitzar diverses fonts subjacents. La còpia de seguretat es reduirà tant reduint fitxers de còpies de seguretat anteriors (si n'hi ha) com per fitxers públics (el que es pot descarregar).

Si per alguna raó no confiem en la fiabilitat dels recursos de Debian (https://snapshot.debian.org/) o utilitza una altra distribució, simplement podem fer una còpia de seguretat completa una vegada amb tots els paquets i després confiar-hi (desactivant les heurístiques). Ara, si tots els servidors de les nostres distribucions resulten que no estan disponibles per a nosaltres (a Internet de records o durant una apocalipsi zombi), però les nostres còpies de seguretat estan en ordre, podem recuperar-nos de qualsevol còpia de seguretat breu de diferencia que només es basa en les nostres còpies de seguretat anteriors. .

Hashget només es basa en fonts de recuperació de confiança a la SEVA discreció. S'utilitzaran els que considereu fiables.

FilePool i Glacier

Mecanisme Filepool permet no contactar constantment amb servidors externs per descarregar paquets, sinó utilitzar paquets d'un directori local o servidor corporatiu, per exemple:

$ hashget -u . --pool /tmp/pool

o

$ hashget -u . --pool http://myhashdb.example.com/

Per fer un grup en un directori local, només cal que creeu un directori i hi llenceu fitxers, el mateix hashget trobarà el que necessita utilitzant els hash. Per fer que el grup sigui accessible mitjançant HTTP, heu de crear enllaços simbòlics d'una manera especial; això es fa amb una ordre (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). HTTP FilePool en si són fitxers estàtics, de manera que qualsevol servidor web senzill pot servir-lo, la càrrega al servidor és gairebé zero.

Gràcies a FilePool, podeu utilitzar no només els recursos http(s) com a recursos bàsics, sinó també per exemple, Glacera d'Amazones.

Després de carregar la còpia de seguretat a la glacera, obtenim el seu ID de càrrega i l'utilitzem com a URL. Per exemple:

hashget --submit Glacier_Upload_ID --file /tmp/my-glacier-backup.tar.gz --project glacier --hashserver --expires 2019-09-01

Ara les còpies de seguretat noves (diferencials) es basaran en aquesta còpia de seguretat i seran més breus. Després de desempaquetar el diffbackup, podem veure en quins recursos es basa:

hashget --info /tmp/unpacked/ list

i només utilitzeu un script d'intèrpret d'ordres per descarregar tots aquests fitxers de Glacier al grup i executeu la recuperació habitual: hashget -u /tmp/unpacked —pool /tmp/pool

Val la pena el joc l'espelma?

En el cas més senzill, simplement pagareu menys per les còpies de seguretat (si les deseu en algun lloc del núvol per diners). Potser molt, molt menys.

Però això no és l'únic. La quantitat es converteix en qualitat. Podeu utilitzar-lo per obtenir una actualització d'alta qualitat del vostre esquema de còpia de seguretat. Per exemple, com que les nostres còpies de seguretat són ara més curtes, no podem fer còpies de seguretat mensuals, sinó diàries. Guardeu-los no durant sis mesos, com abans, sinó durant 5 anys. Abans, l'emmagatzeves en un emmagatzematge "fred" lent però barat (Glacier), ara el pots emmagatzemar en un emmagatzematge calent, des d'on sempre pots descarregar-te ràpidament una còpia de seguretat i restaurar-la en minuts, no en un dia.

Podeu augmentar la fiabilitat de l'emmagatzematge de còpia de seguretat. Si actualment les emmagatzemem en una instal·lació d'emmagatzematge, reduint el volum de còpies de seguretat, podrem emmagatzemar-les en 2 o 3 instal·lacions d'emmagatzematge i sobreviure sense dolor si una d'elles es fa malbé.

Com provar i començar a utilitzar?

Aneu a la pàgina de gitlab https://gitlab.com/yaroslaff/hashget, instal·leu amb una ordre (pip3 install hashget[plugins]) i només llegiu i executeu l'inici ràpid. Crec que trigarà 10-15 minuts a fer totes les coses senzilles. A continuació, podeu provar de comprimir les vostres màquines virtuals, crear fitxers de pistes si cal per fer la compressió més forta, jugar amb grups, una base de dades hash local i un servidor hash si esteu interessats, i l'endemà veure quina és la mida de la còpia de seguretat incremental. estarà per sobre del d'ahir.

Font: www.habr.com

Afegeix comentari