Ă€r en gratis, öppen kĂ€llkods deduplicator â en verktyg liknande en kompressor som gör det möjligt att betydligt minska storleken pĂ„ backupfiler, samt organisera inkrementella och differentiella backup-scheman och mer.
Detta Àr en översiktsartikel som beskriver funktionerna. SjÀlva anvÀndningen av hashget (ganska enkelt) beskrivs i projektet och .
JÀmförelse
Enligt genre förvÀntas jag inleda med en spÀnnande jÀmförelse av resultaten:
Dataexempel
uppackad storlek
.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% )
Bakgrund, hur en ideal och effektiv backup bör se ut
Varje gÄng jag gjorde en backup av en nyligen skapad virtuell maskin, kÀndes det som om jag gjorde nÄgot fel. Varför fÄr jag en tung backup frÄn ett system dÀr min ovÀrderliga, odödliga skapelse Àr en endaste rad index.html med texten "Hello world"?
Varför finns det en 16-megabytes backup av /usr/sbin/mysqld i min backup? Ăr det verkligen sĂ„ att just jag har fĂ„tt Ă€ran att lagra denna viktiga fil, och om jag misslyckas â kommer den att gĂ„ förlorad för mĂ€nskligheten? Troligen inte. Den finns lagrad pĂ„ högpĂ„litliga Debian-servrar (vars pĂ„litlighet och driftsĂ€kerhet inte gĂ„r att jĂ€mföra med vad jag kan sĂ€kerstĂ€lla), liksom i backupkopior (miljoner av dem) hos andra administratörer. MĂ„ste vi verkligen skapa en 10 000 000 + 1:a kopia av denna viktiga fil för att öka pĂ„litligheten?
Generellt sett löses detta problem. Vid packning gör den en mycket liten backup. Vid uppackning fÄr man ett helt uppackat system, liknande det som skulle ha skapats med tar -c / tar -x. (Med andra ord, detta Àr lossless packning)
Hur hashget fungerar
Hashget anvÀnder begrepp som Package och HashPackage för att utföra deduplicering.
Package (paket). En fil (vanligtvis en .deb eller .tar.gz arkiv) som kan laddas ner pÄ ett tillförlitligt sÀtt frÄn nÀtet och varifrÄn man kan fÄ en eller flera filer.
HashPackage Àr en liten JSON-fil som representerar Package, inklusive URL:en för paketet och hash-kontroller (sha256) av filerna i det. Till exempel, för paketet mariadb-server-core med en storlek pÄ 5 megabyte, Àr storleken pÄ hashpackage endast 6 kilobyte. UngefÀr tusen gÄnger mindre.
Deduplicering â att skapa ett arkiv utan duplicerade filer (om deduplicatorn vet var originalpaketet kan laddas ner, minskar den dubbleringar i arkivet).
Packning
NÀr du packar en katalog, granskas alla filer i den packade katalogen, deras hash-vÀrden berÀknas, och om ett hash-vÀrde finns i en av de kÀnda HashPackage, sparas filmetadata (namn, hash, behörigheter etc.) i en sÀrskild fil .hashget-restore.json, som ocksÄ kommer att inkluderas i arkivet.
SjÀlva packningen ser i enklaste fall inte mer komplicerad ut Àn tar:
hashget -zf /tmp/mybackup.tar.gz --pack /path/to/dataPacka upp
Uppackningen görs i tvÄ steg. Först den vanliga tar-uppackningen:
tar -xf mybackup.tar.gz -C /path/to/datasedan ÄterstÀllningen frÄn nÀtverket:
hashget -u /path/to/dataVid ÄterstÀllning lÀser hashget filen .hashget-restore.json, laddar ner nödvÀndiga paket, packar upp dem och extraherar nödvÀndiga filer, och placerar dem pÄ rÀtt platser, med rÀtt Àgare/grupp/behörigheter.
Mer komplexa saker
Det som beskrivits ovan Àr redan tillrÀckligt för dem som "vill ha nÄgot som fungerar som tar, men vill packa min Debian i 4 megabyte". LÄt oss titta pÄ mer komplexa saker.
Indexering
Om hashget inte hade nÄgot HashPackage, skulle det helt enkelt inte kunna deduplicera nÄgot.
Ett HashPackage kan ocksÄ skapas manuellt (enkel: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), men det finns ett enklare sÀtt.
För att fÄ de nödvÀndiga hashpaketen, finns det ett steg indexering (det utförs automatiskt med kommandot --pack) och heuristik. Vid indexering "matningar" hashget varje funnen fil till alla befintliga heuristiker som den Àr intresserad av. Heuristiker kan sedan indexera ett paket för att skapa ett HashPackage.
Till exempel gillar Debian-heuristiken filen /var/lib/dpkg/status och upptĂ€cker installerade Debian-paket, och om de inte Ă€r indexerade (inga HashPackage skapats för dem), laddar de ner och indexerar dem. Resultatet blir en mycket trevlig effekt â hashget kommer alltid effektivt att deduplicera Debian-baserade system, Ă€ven om de har de senaste paketen.
Hint-filer
Om ditt nÀtverk anvÀnder ett eget proprietÀrt paket eller ett offentligt paket som inte Àr inkluderat i hashgets heuristiker, kan du lÀgga till en enkel hint-fil hashget-hint.json enligt mallen:
{
"project": "wordpress.org",
"url": "https://ru.wordpress.org/wordpress-5.1.1-ru_RU.zip"
}DĂ€refter kommer varje gĂ„ng ett arkiv skapas paketet att indexeras (om det inte redan har gjorts) och filerna i paketet kommer att dedupliceras frĂ„n arkivet. Ingen programmering behövs, allt kan göras frĂ„n vim och spara utrymme i varje backup. Observera att tack vare tillvĂ€gagĂ„ngssĂ€ttet med checksummor, om nĂ„gra filer i paketet Ă€ndras lokalt (till exempel om konfigurationsfilen Ă€ndras) â sĂ„ kommer de Ă€ndrade filerna att sparas i arkivet 'som de Ă€r' utan att förkortas.
Om nÄgot av dina egna paket uppdateras regelbundet, men Àndringarna inte Àr sÄ stora, kan du göra en hint endast för huvudversionerna. Till exempel, i version 1.0 görs en hint som pekar pÄ mypackage-1.0.tar.gz, och den kommer att dedupliceras helt, sedan slÀpptes version 1.1, som skiljer sig nÄgot, och hintet uppdaterades inte. Inga problem. Endast filer som matchar (som kan ÄterstÀllas) med version 1.0 dedupliceras.
Heuristiken som hanterar hint-filen â Ă€r ett bra exempel för att förstĂ„ det interna mekanismen för hur heuristiker fungerar. Den hanterar endast filer hashget-hint.json (eller .hashget-hint.json med punkt) och ignorerar alla andra. Baserat pĂ„ denna fil bestĂ€mmer den vilken URL paketet ska indexeras och hashget indexerar den (om det inte har gjorts tidigare).
HashServer
Det skulle vara ganska arbetsintensivt att helt utföra indexering vid skapandet av backuper. För detta mĂ„ste varje paket laddas ner, packas upp och indexeras. DĂ€rför anvĂ€nder hashget ett schema med . Vid upptĂ€ckten av ett installerat debian-paket, om det inte hittas i lokala HashPackage, görs först ett försök att bara ladda ner HashPackage frĂ„n hashservern. Och endast om det inte lyckas â laddar hashget ner och hash-kodar paketet sjĂ€lv (och laddar upp det till hashservern, sĂ„ att hashservern senare kan ge det).
HashServer Àr inte en obligatorisk del av schemat, det Àr inte kritiskt och anvÀnds uteslutande för att snabba upp och minska belastningen pÄ arkiven. Den kan enkelt stÀngas av (med alternativet --hashserver utan parametrar). Dessutom kan man enkelt .
Inkrementella och differensbackuper, planerat förÄldrade
gör det mycket enkelt att skapa ett schema . Varför skulle vi inte indexera vÄr egen backup (med alla vÄra unika filer)? Ett kommando --submit Och allt Àr klart! NÀsta backup som hashget skapar kommer inte att inkludera filer frÄn detta arkiv.
Men det Àr inte en bra strategi, eftersom det kan hÀnda att vi vid ÄterstÀllning mÄste hÀmta alla hashget-backuper genom hela historien (om det i varje backup finns Ätminstone en unik fil). För detta finns en mekanism . Vid indexering kan du ange förÄldran datum för HashPackage --expires 2019-06-01, och vid denna datum (frÄn 00:00) kommer den inte att anvÀndas. Det finns ingen anledning att ta bort sjÀlva arkivet efter detta datum (Àven om hashget kan enkelt visa URL: erna för alla backuper som vi har fÄtt förÄldrade/förÄldras vid denna tidpunkt eller nÄgot datum).
Till exempel, om vi gör en full backup den 1:a och indexerar den med en livslĂ€ngd till slutet av mĂ„naden â kommer vi att fĂ„ en differentialbackup-schema.
Om vi ocksĂ„ indexerar nya backuper pĂ„ samma sĂ€tt â kommer det att bli ett schema för inkrementell backuper.
Till skillnad frÄn traditionella scheman tillÄter hashget anvÀndning av flera grundkÀllor. Backup kommer att minskas genom att minska filer frÄn tidigare backuper (om sÄdana finns), och genom offentliga filer (det som kan laddas ner).
Om vi av nĂ„gon anledning inte litar pĂ„ tillförlitligheten hos Debians resurser () eller anvĂ€nder en annan distribution, kan vi en gĂ„ng göra en full backup med alla paket och sedan förlita oss pĂ„ den (). Nu, om alla servrar för vĂ„ra distributioner skulle bli otillgĂ€ngliga för oss (i den souvenir-internet eller vid ett zombie-apokalyps), men vĂ„ra backuper Ă€r i ordning â kan vi Ă„terstĂ€lla frĂ„n vilken kort differentialbackup som helst som endast förlitar sig pĂ„ vĂ„ra tidigare backuper.
Hashget förlitar sig endast pĂ„ pĂ„litliga Ă„terstĂ€llningskĂ€llor efter DITT val. De som du anser vara pĂ„litliga â kommer att anvĂ€ndas.
FilePool och Glacier
Mekanismen möjliggör att inte stÀndigt behöva kontakta externa servrar för att hÀmta paket, utan att anvÀnda paket frÄn den lokala katalogen eller företagets server, till exempel:
$ hashget -u . --pool /tmp/pooleller
$ hashget -u . --pool http://myhashdb.example.com/För att skapa en pool i en lokal katalog rÀcker det med att helt enkelt skapa en katalog och lÀgga in filer, hashget hittar sjÀlv det den behöver baserat pÄ hash-vÀrden. För att göra poolen tillgÀnglig via HTTP mÄste man pÄ ett sÀrskilt sÀtt skapa symboliska lÀnkar, vilket görs med ett kommando (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). SjÀlva HTTP FilePool Àr statiska filer, sÄ vilken enkel webbserver som helst kan hantera det, belastningen pÄ servern Àr nÀstan obefintlig.
Tack vare FilePool kan man anvÀnda inte bara resurser pÄ http(s) som basresurser, utan Àven, , Amazon Glacier.
Efter att ha laddat upp backupen till Glacier fÄr vi dess Upload ID och anvÀnder det som URL. Till exempel:
hashget --submit Glacier_Upload_ID --file /tmp/my-glacier-backup.tar.gz --project glacier --hashserver --expires 2019-09-01Nu kommer nya (differentiella) backuper att baseras pÄ denna backup och vara kortare. Efter att ha packat upp diffbackupen kan vi se vilka resurser den Àr beroende av:
hashget --info /tmp/unpacked/ listoch med ett enkelt shell-script ladda ner alla dessa filer frÄn Glacier till pool och starta en vanlig ÄterstÀllning: hashget -u /tmp/unpacked --pool /tmp/pool
Ăr det vĂ€rt mödan?
I det enklaste fallet â kommer du bara att betala mindre för backuper (om du lagrar dem nĂ„gonstans i molnet mot avgift). Kanske â mycket mycket mindre.
Men det Ă€r inte allt. MĂ€ngd blir till kvalitet. Du kan anvĂ€nda detta för att fĂ„ en kvalitetsuppgradering av backup-schema. Till exempel, eftersom vĂ„ra backuper nu Ă€r kortare â kan vi göra backup dagligen istĂ€llet för mĂ„nadsvis. Lagra dem inte i ett halvĂ„r som tidigare, utan i 5 Ă„r. Tidigare lagrade vi i lĂ„ngsam men billig "kall" lagring (Glacier), nu kan du lagra i varm lagring dĂ€r du alltid snabbt kan ladda ner backupen och Ă„terstĂ€lla pĂ„ nĂ„gra minuter istĂ€llet för en dag.
Du kan öka tillförlitligheten i backup-lagringen. Om vi nu lagrar dem i ett lagringsutrymme, kan vi genom att minska storleken pÄ backuperna lagra dem i 2-3 lagringsutrymmen och utan problem överleva om nÄgot av dem skadas.
Hur kan man prova och börja anvÀnda?
GÄ till GitLab-sidan , installera med ett kommando (pip3 install hashget[plugins]) och bara lÀser och följer quick-start. Jag tror att allt enkelt arbete tar ungefÀr 10-15 minuter. Sedan kan du prova att komprimera dina virtuella maskiner, skapa eventuella hint-filer för att komprimera ytterligare, experimentera med pooler, den lokala hash-databasen och hashservern om det skulle intressera dig, och nÀsta dag se hur stor den inkrementella backupen blir utöver gÄrdagens.
KĂ€lla: habr.com
