- ingyenes, nyílt forráskódú deduplikátor egy archiválóhoz hasonló segédprogram, amely lehetővé teszi a biztonsági mentések méretének jelentős csökkentését, valamint a növekményes és differenciális biztonsági mentési sémák és egyebek megszervezését.
Ez egy áttekintő cikk a funkciók leírására. A hashget tényleges használatát (meglehetősen egyszerű) a projekt és .
Сравнение
A műfaj törvénye szerint rögtön az intrikával kezdem - az eredményeket összehasonlítva:
Adatminta
kicsomagolt méret
.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% )
Háttér, hogy milyennek kell lennie egy ideális és hatékony biztonsági mentésnek
Minden alkalommal, amikor biztonsági másolatot készítettem egy frissen létrehozott virtuális gépről, kísértett az érzés, hogy valamit rosszul csinálok. Miért kapok egy tetemes biztonsági mentést a rendszertől, ahol az én felbecsülhetetlen értékű, elpusztíthatatlan kreativitásom egy egysoros index.html „Hello world” szöveggel?
Miért van egy 16 MB /usr/sbin/mysqld a biztonsági mentésemben? Valóban lehetséges, hogy ebben a világban megtiszteltetés számomra, hogy megtarthatom ezt a fontos aktát, és ha nem sikerül, az emberiség számára elveszik? Valószínűleg nem. Rendkívül megbízható debian szervereken (melyek megbízhatósága és üzemideje össze sem hasonlítható azzal, amit tudok), valamint más rendszergazdák (több milliónyi) biztonsági másolatában tárolják. Valóban létre kell hoznunk 10 000 000+ első példányt ebből a fontos fájlból a megbízhatóság növelése érdekében?
Általában és megoldja ezt a problémát. Ha be van csomagolva, nagyon kis biztonsági másolatot készít. Kicsomagoláskor - teljesen kicsomagolt rendszer, hasonló ahhoz, ami lenne, ha tar -c / tar -x. (Más szóval ez veszteségmentes csomagolás)
Hogyan működik a hashget
A hashget rendelkezik a Package és a HashPackage fogalmával, ezek segítségével hajtja végre a deduplikációt.
Csomag (nejlonzacskó). Egy fájl (általában .deb vagy .tar.gz archívum), amely biztonságosan letölthető az internetről, és amelyből egy vagy több fájl beszerezhető.
HashPackage — egy csomagot képviselő kis JSON-fájl, beleértve a csomag URL-címét és a fájlok hash-összegét (sha256). Például egy 5 megabájtos mariadb-server-core csomagnál a hashcsomag mérete csak 6 kilobájt. Körülbelül ezerszer kevesebb.
Deduplikáció — archívum létrehozása duplikált fájlok nélkül (ha a deduplikátor tudja, honnan tölthető le az eredeti csomag, akkor csökkenti a duplikációkat az archívumból).
Csomagolás
Csomagoláskor a csomagolt könyvtár összes fájlját átvizsgálja, kivonatösszegüket kiszámítja, és ha az összeg megtalálható valamelyik ismert HashPackage-ben, akkor a fájl metaadatai (név, hash, hozzáférési jogok stb.) mentésre kerülnek. egy speciális .hashget-restore.json fájlban, amely szintén bekerül az archívumba.
A legegyszerűbb esetben maga a csomagolás nem tűnik bonyolultabbnak, mint a kátrány:
hashget -zf /tmp/mybackup.tar.gz --pack /path/to/dataKicsomagolás
A kicsomagolás két lépésben történik. Először a szokásos kátrányos kicsomagolás:
tar -xf mybackup.tar.gz -C /path/to/datamajd állítsa vissza a hálózatról:
hashget -u /path/to/dataA visszaállításkor a hashget beolvassa a .hashget-restore.json fájlt, letölti a szükséges csomagokat, kicsomagolja, és kicsomagolja a szükséges fájlokat, a szükséges utakra telepítve, a szükséges tulajdonos/csoport/jogosultságokkal.
Nehezebb dolgok
A fent leírtak már bőven elégek azoknak, akik „mint a tar-t akarják, de 4 megabájtba pakolni a Debianomat”. Nézzünk később bonyolultabb dolgokat.
Indexelés
Ha a hashgetnek egyáltalán nem lenne egyetlen HashPackage-je sem, akkor egyszerűen nem tudna semmit deduplikálni.
HashPackage-et manuálisan is létrehozhat (egyszerűen: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), de van egy kényelmesebb módja is.
A szükséges hashpackage megszerzéséhez van egy szakasz indexelés (automatikusan végrehajtódik a paranccsal --pack) És heurisztika. Indexeléskor a hashget minden talált fájlt „táplál” az összes elérhető heurisztika számára, amely érdeklődik iránta. A heurisztika ezután bármilyen csomagot indexelhet, hogy létrehozzon egy HashPackage-et.
Például a Debian heurisztikus szereti a /var/lib/dpkg/status fájlt, és észleli a telepített debian csomagokat, és ha nincsenek indexelve (nincs hozzájuk készített HashPackage), letölti és indexeli őket. Az eredmény egy nagyon szép hatás - a hashget mindig hatékonyan deduplikálja a Debian operációs rendszereket, még akkor is, ha azok a legújabb csomagokkal rendelkeznek.
Tippfájlok
Ha a hálózat az Ön saját fejlesztésű csomagjai közül néhányat, vagy olyan nyilvános csomagot használ, amely nem szerepel a hashget-heurisztikában, hozzáadhat egy egyszerű hashget-hint.json tippfájlt a következőképpen:
{
"project": "wordpress.org",
"url": "https://ru.wordpress.org/wordpress-5.1.1-ru_RU.zip"
}Ezután minden egyes archívum létrehozásakor a csomag indexelésre kerül (ha korábban nem volt), és a csomagfájlok duplikálásra kerülnek az archívumból. Nincs szükség programozásra, mindent meg lehet csinálni a vim-ről, és minden mentésben elmenthető. Kérjük, vegye figyelembe, hogy a hash sum megközelítésnek köszönhetően, ha a csomag egyes fájljait lokálisan módosítják (például egy konfigurációs fájlt módosítanak), akkor a módosított fájlok „ahogy vannak” mentésre kerülnek az archívumba, és nem csonkolódnak.
Ha néhány saját csomagot rendszeresen frissítenek, de a változtatások nem túl nagyok, akkor csak a főbb verziókra utalhat. Például az 1.0-s verzióban tettek egy utalást a mypackage-1.0.tar.gz-re, és ez teljesen deduplikálva lesz, majd kiadták az 1.1-es verziót, ami kicsit eltér, de a tippet nem frissítették. Ez rendben van. Csak az 1.0-s verziónak megfelelő (visszaállítható) fájlok duplikálása történik meg.
A tippfájlt feldolgozó heurisztika jó példa a heurisztika működésének belső mechanizmusának megértésére. Csak a hashget-hint.json fájlokat dolgozza fel (vagy a .hashget-hint.json fájlt egy ponttal), és figyelmen kívül hagyja az összes többit. Ebből a fájlból meghatározza, hogy melyik csomag URL-jét kell indexelni, és a hashget indexeli (ha még nem tette meg)
HashServer
Meglehetősen munkaigényes lenne a teljes indexelés végrehajtása a biztonsági mentések létrehozásakor. Ehhez le kell töltenie az egyes csomagokat, ki kell csomagolnia és indexelnie kell. Ezért a hashget egy sémát használ . Ha egy telepített Debian-csomagot észlel, és az nem található a helyi HashPackage-ben, először megpróbálja egyszerűen letölteni a HashPackage-et a hash-kiszolgálóról. És csak akkor, ha ez nem működik, a hashget maga tölti le és kivonatolja a csomagot (és feltölti a hashserverre, hogy a hashszerver a jövőben ezt biztosítsa).
A HashServer a séma opcionális eleme, nem kritikus, kizárólag a tárolók terhelésének felgyorsítására és csökkentésére szolgál. Könnyen letiltható (opcionális --hashserver paraméterek nélkül). Ezen kívül könnyen .
Növekményes és differenciális mentések, tervezett elavulás
nagyon egyszerűvé teszi a diagram elkészítését . Miért nem indexeljük magát a biztonsági másolatunkat (az összes egyedi fájlunkkal együtt)? Egy csapat --submit és kész! A következő biztonsági másolat, amelyet a hashget hoz létre, nem fogja tartalmazni az archívum fájljait.
De ez nem túl jó megközelítés, mert előfordulhat, hogy a visszaállítás során le kell húznunk az összes hashget biztonsági másolatot a teljes előzményben (ha mindegyik tartalmaz legalább egy egyedi fájlt). Erre van egy mechanizmus . Indexeléskor megadhatja a HashPackage lejárati dátumát --expires 2019-06-01, és ezen időpont után (00:00 órától) nem kerül felhasználásra. Maga az archívum ezen dátum után nem törölhető (bár a hashget kényelmesen meg tudja mutatni az összes pillanatnyilag vagy bármely napon romlott/lesz rohadt mentés URL-jét).
Például, ha 1-én készítünk egy teljes biztonsági mentést és indexeljük a hónap végéig tartó élettartammal, akkor differenciális biztonsági mentési sémát kapunk.
Ha az új biztonsági mentéseket ugyanúgy indexeljük, akkor lesz egy növekményes biztonsági mentés séma.
A hagyományos sémákkal ellentétben a hashget lehetővé teszi több mögöttes forrás használatát. A biztonsági mentés mennyisége csökkenni fog mind a korábbi biztonsági mentésekből származó fájlok csökkentésével (ha vannak ilyenek), mind a nyilvános fájlokkal (amiket le lehet tölteni).
Ha valamilyen okból nem bízunk a Debian erőforrások megbízhatóságában () vagy más disztribúciót használ, egyszerűen készíthetünk teljes biztonsági másolatot egyszer az összes csomagról, majd támaszkodhatunk rá (). Ha most kiderül, hogy disztribúcióink összes szervere nem elérhető számunkra (a szuvenír interneten vagy egy zombiapokalipszis idején), de a biztonsági mentéseink rendben vannak, minden olyan rövid diff biztonsági mentésből helyreállhatunk, amely csak a korábbi biztonsági mentéseinkre támaszkodik. .
A Hashget csak az ÖN belátása szerint támaszkodik megbízható helyreállítási forrásokra. Az Ön által megbízhatónak ítélteket fogják használni.
FilePool és Glacier
Механизм lehetővé teszi, hogy ne lépjen kapcsolatba folyamatosan külső szerverekkel a csomagok letöltéséhez, hanem használjon csomagokat egy helyi címtárról vagy vállalati szerverről, például:
$ hashget -u . --pool /tmp/poolvagy
$ hashget -u . --pool http://myhashdb.example.com/Ahhoz, hogy egy helyi könyvtárban készletet hozzon létre, csak létre kell hoznia egy könyvtárat, és bele kell dobnia a fájlokat, a hashget maga fogja megtalálni, amire szüksége van a hashek segítségével. Ahhoz, hogy a készlet elérhetővé váljon HTTP-n keresztül, speciális módon szimbolikus hivatkozásokat kell létrehoznia; ez egyetlen paranccsal (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). Maga a HTTP FilePool statikus fájlok, így bármilyen egyszerű webszerver ki tudja szolgálni, a szerver terhelése szinte nulla.
A FilePoolnak köszönhetően nem csak a http(s) erőforrásokat használhatja alaperőforrásként, hanem azt is ,Amazon-gleccser.
Miután feltöltöttük a biztonsági másolatot a gleccserre, megkapjuk a feltöltési azonosítóját, és URL-ként használjuk. Például:
hashget --submit Glacier_Upload_ID --file /tmp/my-glacier-backup.tar.gz --project glacier --hashserver --expires 2019-09-01Most az új (differenciális) biztonsági mentések ezen a biztonsági másolaton fognak alapulni, és rövidebbek lesznek. A diffbackup tar kicsomagolása után láthatjuk, hogy milyen erőforrásokra támaszkodik:
hashget --info /tmp/unpacked/ listés csak egy shell szkript segítségével töltse le ezeket a fájlokat a Glacierből a medencébe, és futtassa a szokásos helyreállítást: hashget -u /tmp/unpacked —pool /tmp/pool
Megéri a játék a gyertyát?
A legegyszerűbb esetben egyszerűen kevesebbet fog fizetni a biztonsági mentésekért (ha pénzért valahol a felhőben tárolja őket). Talán sokkal, de sokkal kevésbé.
De nem ez az egyetlen dolog. A mennyiség minőséggé változik. Használhatja ezt a biztonsági mentési séma kiváló minőségű frissítéséhez. Például mivel a biztonsági mentéseink rövidebbek, nem havi, hanem napi mentést készíthetünk. Tárolja őket nem hat hónapig, mint korábban, hanem 5 évig. Korábban lassú, de olcsó „hideg” tárolóban (Glacier) tároltad, most már meleg tárolóban tárolhatod, ahonnan mindig gyorsan letölthetsz egy mentést és percek alatt visszaállíthatod, nem egy nap alatt.
Növelheti a biztonsági mentések megbízhatóságát. Ha jelenleg egy tárolóban tároljuk őket, akkor a mentések mennyiségének csökkentésével 2-3 tárolóban tudjuk tárolni és fájdalommentesen túlélni, ha valamelyik megsérül.
Hogyan lehet kipróbálni és elkezdeni használni?
Menj a gitlab oldalra , telepítse egy paranccsal (pip3 install hashget[plugins]), és csak olvassa el és hajtsa végre a gyorsindítást. Szerintem 10-15 percet vesz igénybe minden egyszerű dolog elvégzése. Ezután megpróbálhatja tömöríteni a virtuális gépeit, szükség esetén tippfájlokat készíteni, hogy erősebb legyen a tömörítés, játszani poolokkal, helyi hash adatbázissal és hash szerverrel, ha érdekel, és másnap megnézheti, mekkora a növekményes biztonsági mentés mérete. a tegnapi tetején lesz.
Forrás: will.com