hashget er et gratis, open-source dedupliker — et verktøy lignende til en arkiverer som betydelig reduserer størrelsen på sikkerhetskopier, samt organiserer inkrementelle og differensielle sikkerhetskopier, og mer.

Dette er en introduksjonsartikkel for å beskrive funksjonene. Bruken av hashget (som er ganske enkel) er beskrevet i README prosjektet og wiki-dokumentasjonen.

Sammenligning

Som en del av sjangeren, begynner jeg med spenningen — sammenligning av resultatene:

Data sample
utpakket størrelse
.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% )

Bakgrunnen for hva en ideell og effektiv sikkerhetskopi skal være

Hver gang jeg laget en sikkerhetskopi av en nyopprettet virtuell maskin, gnagde det i meg følelsen av at jeg gjorde noe feil. Hvorfor får jeg en tung sikkerhetskopi av systemet, der mitt uvurderlige, uforanderlige kreative verk — en en-linjes index.html med teksten «Hello world»?

Hvorfor er det en 16 megabyte /usr/sbin/mysqld i min sikkerhetskopi? Er det virkelig min ære i denne verden å oppbevare denne viktige filen, og hvis jeg ikke klarer det — vil den gå tapt for menneskeheten? Sannsynligvis ikke. Den er lagret på høyt pålitelige Debian-servere (pålitelige og stabile på en måte som ikke kan sammenlignes med hva jeg kan tilby), samt i sikkerhetskopier (millioner av dem) fra andre administratorer. Må vi virkelig lage en sikkerhetskopi nummer 10 000 000 + 1 av denne viktige filen for å øke påliteligheten?

I utgangspunktet hashget løser dette problemet. Ved pakking — lager det en veldig liten sikkerhetskopi. Ved utpakking — en fullstendig utpakket system, som ligner på det som ville vært ved tar -c / tar -x. (Med andre ord, dette er tapfri pakking)

Hvordan fungerer hashget

I hashget finnes det begreper Package og HashPackage, med hjelp av disse utfører det deduplisering.

Pakke (pakken). En fil (som regel en .deb- eller .tar.gz-arkiv), som man kan laste ned pålitelig fra nettet, og fra hvilken man kan få en eller flere filer.

HashPackage — en liten JSON-fil som representerer Package og inneholder blant annet URL-en til pakken og hash-summer (sha256) av filene i den. For eksempel, for pakken mariadb-server-core med en størrelse på 5 megabyte, er størrelsen på hashpackage bare 6 kilobyte. Omtrent tusen ganger mindre.

Deduplication — oppretting av et arkiv uten dupliserte filer (hvis deduplisereren vet hvor den originale pakken kan lastes ned, reduserer den dupliserte filer i arkivet).

Pakking

Når du pakker, gjennomgås alle filer i det pakkede kataloget, deres hash-summer beregnes, og dersom summen finnes i en av de kjente HashPackage, lagres metadata om filen (navn, hash, tilgangsrettigheter osv.) i en spesiell fil .hashget-restore.json, som også vil bli inkludert i arkivet.

Selve pakkinga ser i enkleste tilfelle ikke vanskeligere ut enn tar:

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

Pakking

Utpakking skjer i to trinn. Først vanlig tar-utpakking:

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

deretter gjenoppretting fra nettverket:

hashget -u /path/to/data

Ved gjenoppretting leser hashget filen .hashget-restore.json, laster ned nødvendige pakker, pakker dem ut, og henter de nødvendige filene, og plasserer dem på de riktige banene, med riktige eier/grupper/rettigheter.

Mer komplekse ting

Det som er beskrevet ovenfor er allerede tilstrekkelig for de som ønsker «som tar, men pakket Debian min i 4 megabyte». La oss se på mer komplekse ting.

Indeksering

Hvis hashget ikke hadde hatt noen HashPackage, ville det ikke vært i stand til å deduplisere noe.

Du kan også opprette HashPackage manuelt (bare: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), men det finnes en enklere måte.

For å få de nødvendige hashpackene, er det et trinn indeksering (det utføres automatisk ved kommandoen --pack) og heuristikker. Ved indeksering «foresterer» hashget hver funnet fil til alle tilgjengelige heuristikker som den er interessert i. Heuristikkene kan deretter indeksere et Package for å lage en HashPackage.

For eksempel liker den debianske heuristikken filen /var/lib/dpkg/status og oppdager installerte debian-pakker, og hvis de ikke er indeksert (ingen HashPackage er laget for dem), laster den ned og indekserer dem. Det gir en veldig behagelig effekt — hashget vil alltid effektivt deduplisere debianske OS-er, selv om de har de nyeste pakkene.

Hint-filer

Hvis det i nettverket ditt brukes en eller annen proprietær pakke eller offentlig pakke som ikke er inkludert i hashget sine heuristikker, kan du enkelt legge til en hint-fil hashget-hint.json etter mønster:

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

Videre, hver gang et arkiv opprettes, vil pakken bli indeksert (hvis den ikke allerede er indeksert), og pakkefilene vil bli deduplisert fra arkivet. Ingen programmering kreves, alt kan gjøres fra vim, og du kan spare tid i hver backup. Merk at takket være tilnærmingen med checksummer, hvis noen filer i pakken endres lokalt (for eksempel hvis konfigurasjonsfilen endres) — vil de endrede filene bli bevart i arkivet "som de er" og ikke bli forkortet.

Hvis en av dine egne pakker oppdateres med jevne mellomrom, men endringene ikke er så store, kan du lage hint bare for hovedversjonene. For eksempel, i versjon 1.0 ga vi et hint med henvisning til mypackage-1.0.tar.gz, og den vil bli fullstendig deduplisert, deretter ble versjon 1.1 utgitt, som er litt annerledes, men hintet ble ikke oppdatert. Ingen problem. Bare filer som samsvarer (som kan gjenopprettes) med versjon 1.0 dedupliseres.

Heuristikken som behandler hint-filen er et godt eksempel for å forstå det indre mekanismen bak heuristikker. Den behandler kun filer hashget-hint.json (eller .hashget-hint.json med punktum) og ignorerer alle andre. Basert på denne filen, bestemmer den hvilken URL pakken skal indekseres, og hashget indekserer den (hvis det ikke ble gjort tidligere).

HashServer

Det ville vært ganske tidkrevende å utføre full indeksering ved oppretting av sikkerhetskopier. For dette må du laste ned hver pakke, pakke den ut, og indeksere den. Derfor bruker hashget et system med HashServer. Ved oppdagelse av en installert debian-pakke, hvis den ikke finnes i lokale HashPackage, prøver man først å laste ned HashPackage fra hashserveren. Og bare hvis det ikke lykkes, laster hashget selv ned og hasher pakken (og laster den opp til hashserveren, slik at hashserveren kan tilby den videre).

HashServer er ikke et nødvendig element i systemet, ikke kritisk, og fungerer utelukkende for å øke hastigheten og redusere belastningen på depotene. Det kan enkelt slås av (med alternativet --hashserver uten parametere). I tillegg kan du enkelt lage din egen hashserver..

Inkrementelle og differensiale sikkerhetskopier, planlagt foreldelse

hashget lar deg enkelt lage et system for inkrementelle og differensiale sikkerhetskopier.Hvorfor ikke indekser vår egen backup (med alle våre unike filer)? En enkelt kommando --submit Og alt er klart! Den næste backup, som hashget laver, vil ikke inkludere filer fra dette arkiv.

Men det er ikke en særlig god tilgang, fordi det kan vise sig, at vi ved gendannelse skal trække alle hashget-backups gennem hele historien (hvis der i hver vil være mindst én unik fil). Der findes et mekanisme til planlagt forældelse af backups. Ved indeksering kan man angive en forældelsesdato for HashPackage --expires 2019-06-01, og ved denne dato (fra kl. 00:00) vil det ikke blive brugt. Selve arkivet kan efter denne dato ikke slettes (Selvom hashget bekvemt kan vise URLs for alle vores backups, der er forældede/blev forældede på nuværende tidspunkt eller på en hvilken som helst dato).

For eksempel, hvis man den 1. laver en fuld backup, og indeksere den med en levetid indtil slutningen af måneden - så får vi en differential backup-struktur.

Hvis vi også indeksere nye backups på samme måde - vil det være et system af inkrementelle backups.

I modsætning til traditionelle systemer tillader hashget at bruge flere grundlæggende kilder. Backup vil blive forkortet både ved at forkorte filer fra tidligere backups (hvis der er nogen), og ved hjælp af offentlige filer (det, der kan downloades).

Hvis vi af en eller anden grund ikke stoler på pålideligheden af Debian-ressourcerne (https://snapshot.debian.org/) eller bruger en anden distribution, kan vi blot én gang lave en fuld backup med alle pakkerne, og derefter basere os på den (deaktivere heuristikken). Nu, hvis alle servere fra vores distributioner viser sig at være utilgængelige (i souvenirinternettet eller under en zombie-apokalypse), men vores backups vil være i orden - kan vi gendanne fra enhver kort differential backup, der kun bygger på vores tidligere backups.

Hashget stoler kun på pålidelige genopretningskilder efter dit valg. Hvad du anser for pålideligt - det vil blive brugt.

FilePool og Glacier

The mechanism has been FilePool giver mulighed for ikke konstant at henvende sig til eksterne servere for at downloade pakker, men at bruge pakker fra lokale kataloger eller en virksomhedsserver, for eksempel:

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

eller

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

For creating a pool in the local directory, just create a directory and place the files in it; hashget will find what it needs based on hashes. To make the pool available via HTTP, you need to create symlinks in a special way, which can be done with one command (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). The HTTP FilePool consists of static files, so it can be served by any simple web server, and the server load is almost zero.

Thanks to FilePool, you can use not only HTTP(S) resources as basic resources, but also, for example,, Amazon Glacier.

After uploading the backup to Glacier, we get its Upload ID and use it as a URL. For example:

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

Now new (differential) backups will rely on this backup and will be shorter. After unpacking the diff backup, we can check which resources it depends on:

hashget --info /tmp/unpacked/ list

and simply use a shell script to download all these files from Glacier into the pool and start a regular recovery: hashget -u /tmp/unpacked --pool /tmp/pool

Is it worth it?

In the simplest case, you will just pay less for backups (if you store them somewhere in the cloud for a fee). Maybe—much, much less.

But that's not the only thing. Quantity turns into quality. You can use this to achieve a quality upgrade in the backup scheme. For example, since our backups are now shorter, we can perform daily backups instead of monthly backups. We can store them not for six months as before, but for 5 years. Previously, backups were kept in slow but cheap 'cold' storage (Glacier), and now you can store them in hot storage, from where you can quickly download the backup and recover within minutes, not days.

You can increase the reliability of backup storage. If we currently store them in one storage, by reducing the volume of backups, we can store them in 2-3 storages and comfortably survive in case one of them fails.

How to try it and start using it?

Go to the GitLab page https://gitlab.com/yaroslaff/hashget, install it with one command (pip3 install hashget[plugins]) og bare leser og følger quick-start. Jeg tror at alle de enkle tingene tar omtrent 10-15 minutter. Deretter kan du prøve å komprimere virtuelle maskiner, lage hint-filer hvis nødvendig for å oppnå enda høyere kompresjon, eksperimentere med puljer, lokal hash-database og hash-server hvis det er interessant, og dagen etter se hva størrelsen på den inkrementelle sikkerhetskopien blir over gårsdagens.

Kilde: habr.com