Reducer backups med 99,5% med hashget

hashget — er et gratis, open source deduplicator — et værktøj, der ligner en arkiver, som gør det muligt at reducere størrelsen på backups betydeligt samt organisere inkrementelle og differentielle backup-skemaer og mere.

Dette er en oversigtsartikel til at beskrive funktionerne. Den faktiske brug af hashget (ret enkel) er beskrevet i README projektet og wiki-dokumentationen.

Sammenligning

I henhold til genren, vil jeg straks begynde med en spændende sammenligning af resultaterne:

Data sample
udpakket 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% )

Forhistorien, hvordan den ideelle og effektive backup skal være

Hver gang jeg lavede en backup af en nyoprettet virtuel maskine, havde jeg en foruroligende følelse af, at jeg gjorde noget forkert. Hvorfor får jeg en tung backup fra systemet, hvor mit uvurderlige og uforgængelige kreative produkt blot er et enkelt index.html med teksten “Hello world”?

Hvorfor er der en 16-megabyte /usr/sbin/mysqld i min backup? Er det virkelig mig, der har ansvaret for at gemme denne vigtige fil, og hvis jeg fejler, vil den gå tabt for menneskeheden? Sikkert ikke. Den gemmes på pålidelige debian-servere (hvis pålidelighed og tilgængelighed slet ikke kan sammenlignes med, hvad jeg kan levere), samt i backup (millioner af dem) af andre administratorer. Er det nødvendigt for os at skabe 10.000.000 + 1’ste kopi af denne vigtige fil for at forbedre pålideligheden?

Generelt hashget løser dette problem. Ved pakning skaber den en meget lille backup. Ved udpakning produceres et fuldt udpakket system, der svarer til det, der ville være ved tar -c / tar -x. (Med andre ord er det tabsfri pakning)

Hvordan hashget fungerer

I hashget er der begreberne Package og HashPackage, som bruges til deduplication.

Package (pakke). En fil (normalt en .deb eller .tar.gz arkiv), som kan downloades sikkert fra nettet, og hvorfra man kan få en eller flere filer.

HashPackage — en lille JSON-fil, der repræsenterer Package, inklusive URL'en til pakken og hash-værdier (sha256) for filerne deri. For eksempel, for pakken mariadb-server-core med en størrelse på 5 megabyte, er størrelsen på hashpackage kun 6 kilobyte. Omtrent tusinde gange mindre.

Deduplicering — oprettelse af et arkiv uden dublerede filer (hvis deduplicatoren ved, hvor den originale pakke kan downloades, reducerer den dubletter fra arkivet).

Pakning

Når der pakkes, gennemses alle filer i den pakkede mappe, deres hashværdier beregnes, og hvis værdien findes i en af de kendte HashPackage, gemmes metadata om filen (navn, hash, adgangsrettigheder osv.) i en særlig fil .hashget-restore.json, som også vil blive inkluderet i arkivet.

Selve pakkningen ser i sin simplicitet ikke mere kompliceret ud end tar:

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

Udpakning

Udpakning sker i to trin. Først den almindelige tar-udpakkning:

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

derefter gendannelse fra netværket:

hashget -u /path/to/data

Ved gendannelse læser hashget filen .hashget-restore.json, downloader de nødvendige pakker, pakker dem ud og udtrækker de nødvendige filer, som placeres på de ønskede stier med de korrekte ejer-/gruppe-/tilladelser.

Mere komplekse ting

Det ovenstående er allerede tilstrækkeligt for dem, der siger "jeg vil have noget som tar, men som kan pakke mit Debian ned på 4 megabyte". Lad os nu se på mere komplekse ting.

Indeksering

Hvis hashget slet ikke havde nogen HashPackage, ville det simpelthen ikke kunne deduplisere noget.

Du kan også oprette en HashPackage manuelt (simpelt: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), men der er en mere praktisk måde.

For at få de nødvendige hashpackages er der et trin indeksering (det udføres automatisk ved kommandoen --pack) og heuristikker. Under indeksering "server" hashget hver fundet fil til alle tilgængelige heuristikker, som det er interesseret i. Heuristikkerne kan derefter indeksere en hvilken som helst pakke for at skabe en HashPackage.

For eksempel elsker den debianske heuristik filen /var/lib/dpkg/status og opdager installerede Debian-pakker, og hvis de ikke er indekseret (hvis der ikke er oprettet HashPackage for dem), downloader og indekserer den dem. Det giver en meget behagelig effekt — hashget vil altid effektivt deduplisere Debian OS'er, selvom de har de nyeste pakker.

Hint-filer

Hvis der i dit netværk bruges en eller anden proprietær pakke eller en offentlig pakke, der ikke er inkluderet i hashgets heuristikker, kan du tilføje en simpel hint-fil hashget-hint.json efter mønsteret:

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

Når du opretter et arkiv, bliver pakken indekseret (hvis den ikke allerede er det), og filerne i pakken vil blive dedupliceret fra arkivet. Der kræves ingen programmering, alt kan gøres fra vim og spare plads i hvert backup. Bemærk, at takket være tilgangen gennem hashsummer, hvis nogle filer i pakken ændres lokalt (f.eks. hvis konfigurationsfilen ændres), så vil de ændrede filer blive gemt i arkivet "som de er" og ikke blive forkortet.

Hvis en af dine egne pakker opdateres jævnligt, men ændringerne ikke er så store, kan du lave hint kun for hovedversionerne. For eksempel, i version 1.0 blev der lavet et hint med henvisning til mypackage-1.0.tar.gz, og den vil blive fuldstændig deduplicerede. Derefter blev version 1.1 udgivet, som er lidt anderledes, og hintet blev ikke opdateret. Det er ikke noget problem. Kun filer, der matcher (og som kan gendannes) med version 1.0, bliver deduplicerede.

Heuristikken, der behandler hint-filen, er et godt eksempel til forståelse af den interne mekanisme for heuristik. Den behandler kun filer hashget-hint.json (eller .hashget-hint.json med punktum) og ignorerer alle andre. I henhold til denne fil bestemmer den, hvilken URL pakken skal indekseres, og hashget indekserer den (hvis dette ikke allerede er blevet gjort).

HashServer

Det ville være ret tidskrævende at udføre en fuld indeksering ved oprettelse af backups. For dette skal hver pakke downloades, udpakkes og indekseres. Derfor bruger hashget et skema med HashServer. Når en installeret Debian-pakke opdages, og hvis den ikke findes i de lokale HashPackage, forsøges det først at downloade HashPackage fra hashserveren. Og kun hvis det ikke lykkes, downloader og hasher hashget pakken selv (og uploader den til hashserver, så hashserveren kan give den senere).

HashServer er ikke et obligatorisk element i skemaet, det er ikke kritisk og bruges udelukkende til at fremskynde og reducere belastningen på repositories. Det kan let deaktiveres (med indstillingen --hashserver uden parametre). Derudover er det nemt at oprette din egen hashserver..

Inkrementelle og differentielle backups, planlagt forældelse

hashget giver en meget enkel mulighed for at lave et skema for inkrementelle og differentielle backups.Hvorfor skal vi ikke indekser vores backup (med alle vores unikke filer)? En kommando --submit Og det er klar! Næste backup, som hashget opretter, vil ikke inkludere filer fra dette arkiv.

Men det er ikke en særlig god tilgang, fordi det kan vise sig, at vi under genopretningen skal hente alle hashget-backups fra hele historien (hvis der i hver er mindst én unik fil). Der findes en mekanisme til planlagt udløb af backupper. Ved indeksering kan man angive en udløbsdato for HashPackage --expires 2019-06-01, og ved denne dato (fra kl. 00:00) vil den ikke blive brugt. Selve arkivet kan efter denne dato ikke slettes (Selvom hashget kan vise URL'er til alle backupper, der er blevet eller vil blive udløbet på nuværende tidspunkt eller på en hvilken som helst dato).

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

Hvis vi også indekserer de nye backupper på samme måde - vil det være en inkrementel backup-plan.

I modsætning til traditionelle ordninger gør hashget det muligt at anvende flere grundlæggende kilder. Backup'en vil blive reduceret både ved at udelade filer fra tidligere backupper (hvis der er nogle), og ved offentlige filer (det, som kan downloades).

Hvis vi af en eller anden grund ikke stoler på pålideligheden af debianske ressourcer (https://snapshot.debian.org/) eller bruger en anden distribution, kan vi gøre en fuld backup med alle pakker én gang, og derefter basere os på den (ved at deaktivere heuristikken). Nu, hvis alle serverne for vores distributioner bliver utilgængelige for os (i souvenirinternettet eller under zombie-apokalypsen), men vores backupper er i orden - kan vi genoprette fra en hvilken som helst kort diffs backup, der kun er baseret på vores tidligere backupper.

Hashget bygger udelukkende på pålidelige genopretningskilder efter DIN vurdering. De, som du betragter som pålidelige, vil blive brugt.

FilePool og Glacier

Mekanisme FilePool gør det muligt ikke konstant at henvende sig til eksterne servere for at hente pakker, men at bruge pakker fra en lokal mappe eller en virksomhedsserver, for eksempel:

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

eller

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

For creating a pool in a local directory, simply create a directory and place files in it; hashget will find what it needs by hashes. To make the pool accessible via HTTP, you must create symlinks in a special way, which can be done with a single 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, with nearly zero load on the server.

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

After uploading the backup to the 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 see what resources it relies on:

hashget --info /tmp/unpacked/ list

and simply use a shell script to download all these files from the glacier to the pool and start a normal restore: hashget -u /tmp/unpacked --pool /tmp/pool

Is the effort worth it?

In the simplest case, you will just pay less for backups (if you store them somewhere in the cloud for a fee). It could be significantly less.

But that’s not all. Quantity turns into quality. You can use this to achieve a quality upgrade of your backup scheme. For instance, since backups are now shorter, you can perform daily backups instead of monthly ones. You can keep them not for six months, as before, but for five years. Previously, they were stored in slow but cheap 'cold' storage (Glacier), now you can store them in hot storage, from which you can quickly download a backup and restore in minutes instead of a day.

You can increase the reliability of backup storage. If we currently store them in one storage, by reducing the size of backups, we can store them in 2-3 storages and withstand the failure of one without issues.

How to try and start using it?

Visit the GitLab page https://gitlab.com/yaroslaff/hashget, install with a single command (pip3 install hashget[plugins]) og bare læse og udføre quick-start. Jeg tror, at det vil tage omkring 10-15 minutter at gøre de enkle ting. Derefter kan du prøve at komprimere dine virtuelle maskiner, lave, hvis nødvendigt, hint-filer for at komprimere endnu mere, lege med puljerne, den lokale hash-database og hash-serveren, hvis det interesserer dig, og dagen efter se, hvad størrelsen på den inkrementelle backup vil være ovenpå gårsdagens.

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster