Bawasan ang mga backup ng 99.5% gamit ang hashget

hashget - ito ay libre, open source deduplikator ay isang utility na katulad ng isang archiver na nagbibigay-daan sa iyong makabuluhang bawasan ang laki ng mga backup, pati na rin ayusin ang mga incremental at differential backup scheme at higit pa.

Ito ay isang pangkalahatang-ideya na artikulo upang ilarawan ang mga tampok. Ang aktwal na paggamit ng hashget (medyo simple) ay inilarawan sa README proyekto at dokumentasyon ng wiki.

Paghahambing

Ayon sa batas ng genre, magsisimula ako kaagad sa intriga - paghahambing ng mga resulta:

Sampol ng data
hindi naka-pack na laki
.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% )

Background kung ano dapat ang isang mainam at epektibong backup

Sa bawat oras na gumawa ako ng isang backup ng isang bagong likhang virtual machine, ako ay pinagmumultuhan ng pakiramdam na ako ay gumagawa ng mali. Bakit ako nakakakuha ng isang mabigat na backup mula sa system, kung saan ang aking hindi mabibili at hindi masisira na pagkamalikhain ay isang isang linyang index.html na may text na "Hello world"?

Bakit may 16 MB /usr/sbin/mysqld sa aking backup? Posible nga bang sa mundong ito ay may karangalan akong panatilihin ang mahalagang file na ito, at kung mabigo ako, mawawala ito sa sangkatauhan? Malamang hindi. Ito ay naka-imbak sa lubos na maaasahang mga debian server (ang pagiging maaasahan at oras ng pag-andar na hindi maihahambing sa kung ano ang maaari kong ibigay), pati na rin sa mga backup (milyon-milyong mga ito) ng iba pang mga admin. Kailangan ba talaga nating gumawa ng 10+ 000st copy ng mahalagang file na ito para mapahusay ang pagiging maaasahan?

Sa pangkalahatan hashget at malulutas ang problemang ito. Kapag nakaimpake, lumilikha ito ng napakaliit na backup. Kapag nag-unpack - isang ganap na naka-unpack na sistema, katulad ng kung ano ito kung tar -c / tar -x. (Sa madaling salita, ito ay lossless packaging)

Paano gumagana ang hashget

Ang hashget ay may mga konsepto ng Package at HashPackage, sa kanilang tulong ay nagsasagawa ito ng deduplication.

pakete (plastik na bag). Isang file (karaniwan ay isang .deb o .tar.gz archive) na maaaring ligtas na ma-download mula sa Internet, at mula sa kung saan ang isa o higit pang mga file ay maaaring makuha.

HashPackage β€” isang maliit na JSON file na kumakatawan sa isang Package, kasama ang package URL at hash sums (sha256) ng mga file mula dito. Halimbawa, para sa isang 5 megabyte mariadb-server-core package, ang laki ng hashpackage ay 6 kilobytes lamang. Halos isang libong beses na mas mababa.

Deduplikasyon β€” paggawa ng archive na walang mga duplicate na file (kung alam ng deduplikator kung saan maaaring ma-download ang orihinal na package, binabawasan nito ang mga duplicate mula sa archive).

Packaging

Kapag nag-iimpake, ang lahat ng mga file mula sa direktoryo na naka-pack ay ini-scan, ang kanilang mga hash sum ay kinakalkula, at kung ang kabuuan ay matatagpuan sa isa sa mga kilalang HashPackages, ang metadata tungkol sa file (pangalan, hash, mga karapatan sa pag-access, atbp.) ay nai-save. sa isang espesyal na file na .hashget-restore.json, na isasama rin sa archive.

Sa pinakasimpleng kaso, ang packaging mismo ay mukhang hindi mas kumplikado kaysa sa tar:

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

Inaalisan

Ang pag-unpack ay ginagawa sa dalawang yugto. Una ang karaniwang pag-unpack ng tar:

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

pagkatapos ay ibalik mula sa network:

hashget -u /path/to/data

Kapag nire-restore, binabasa ng hashget ang .hashget-restore.json file, dina-download ang mga kinakailangang package, ina-unpack ang mga ito, at kinukuha ang mga kinakailangang file, ini-install ang mga ito sa mga kinakailangang path, kasama ang kinakailangang may-ari/grupo/pahintulot.

Mas mahirap na mga bagay

Ang inilarawan sa itaas ay sapat na para sa mga "gusto ito tulad ng tar, ngunit upang i-pack ang aking Debian sa 4 megabytes." Tingnan natin ang mas kumplikadong mga bagay sa ibang pagkakataon.

Pag-index

Kung ang hashget ay walang kahit isang HashPackage, kung gayon hindi nito magagawang i-deduplicate ang anuman.

Maaari ka ring lumikha ng isang HashPackage nang manu-mano (sa simpleng: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), ngunit may mas maginhawang paraan.

Upang makuha ang kinakailangang hashpackage, mayroong isang yugto pag-index (awtomatikong isinagawa ito gamit ang command --pack) At heuristics. Kapag nag-i-index, hashget "mga feed" ang bawat file na makikita sa lahat ng available na heuristic na interesado dito. Ang Heuristics ay maaaring mag-index ng anumang Package upang lumikha ng isang HashPackage.

Halimbawa, ang Debian heuristic ay gustong-gusto ang file /var/lib/dpkg/status at nakakakita ng mga naka-install na debian package, at kung hindi sila na-index (walang HashPackage na ginawa para sa kanila), i-download at ini-index ang mga ito. Ang resulta ay isang napakagandang epekto - ang hashget ay palaging epektibong i-deduplicate ang mga Debian OS, kahit na mayroon silang pinakabagong mga pakete.

Mga file ng pahiwatig

Kung ang iyong network ay gumagamit ng ilan sa iyong pagmamay-ari na mga pakete o isang pampublikong pakete na hindi kasama sa hashget heuristics, maaari kang magdagdag ng isang simpleng hashget-hint.json hint file dito tulad nito:

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

Susunod, sa tuwing may gagawing archive, mai-index ang package (kung hindi pa ito nauna), at aalisin ang mga file ng package mula sa archive. Walang kinakailangang programming, lahat ay maaaring gawin mula sa vim at i-save sa bawat backup. Pakitandaan na salamat sa paraan ng hash sum, kung lokal na binago ang ilang file mula sa package (halimbawa, binago ang configuration file), ang mga binagong file ay ise-save sa archive β€œas is” at hindi puputulin.

Kung ang ilan sa iyong sariling mga pakete ay pana-panahong ina-update, ngunit ang mga pagbabago ay hindi masyadong malaki, maaari kang magpahiwatig lamang para sa mga pangunahing bersyon. Halimbawa, sa bersyon 1.0 gumawa sila ng pahiwatig na tumuturo sa mypackage-1.0.tar.gz, at ganap itong ma-deduplicate, pagkatapos ay inilabas nila ang bersyon 1.1, na bahagyang naiiba, ngunit ang pahiwatig ay hindi na-update. ayos lang. Tanging ang mga file na tumutugma (maaaring ibalik sa) bersyon 1.0 ang deduplicated.

Ang heuristic na nagpoproseso ng hint file ay isang magandang halimbawa para sa pag-unawa sa panloob na mekanismo kung paano gumagana ang heuristics. Pinoproseso lang nito ang mga hashget-hint.json file (o .hashget-hint.json na may tuldok) at binabalewala ang lahat ng iba pa. Mula sa file na ito, tinutukoy nito kung aling URL ng package ang dapat i-index, at ini-index ito ng hashget (kung hindi pa nito nagagawa)

HashServer

Magiging masyadong matrabaho ang magsagawa ng buong pag-index kapag gumagawa ng mga backup. Upang gawin ito, kailangan mong i-download ang bawat pakete, i-unpack ito, at i-index ito. Samakatuwid hashget ay gumagamit ng isang scheme na may HashServer. Kapag may nakitang naka-install na Debian package, kung hindi ito matatagpuan sa lokal na HashPackage, isang pagtatangka ay unang ginawa upang i-download lamang ang HashPackage mula sa hash server. At kung hindi ito gumana, mismong ang hashget ang nagda-download at nagha-hash ng package (at nag-upload nito sa hashserver, para ibigay ito ng hashserver sa hinaharap).

Ang HashServer ay isang opsyonal na elemento ng scheme, hindi kritikal, nagsisilbi lamang itong pabilisin at bawasan ang pagkarga sa mga repositoryo. Madaling hindi pinagana (opsyonal --hashserver walang mga parameter). Bilang karagdagan, maaari mong madali gumawa ng sarili mong hashserver.

Incremental at differential backups, nakaplanong pagkaluma

hashget ginagawang napakadaling gumawa ng diagram incremental at differential backup. Bakit hindi namin i-index ang aming backup mismo (kasama ang lahat ng aming natatanging mga file)? Isang grupo --submit at tapos ka na! Ang susunod na backup na gagawin ng hashget ay hindi magsasama ng mga file mula sa archive na ito.

Ngunit ito ay hindi isang napakahusay na diskarte, dahil maaaring lumabas na kapag ibinalik ay kailangan nating hilahin ang lahat ng mga backup ng hashget sa buong kasaysayan (kung ang bawat isa ay naglalaman ng hindi bababa sa isang natatanging file). May mekanismo para dito nakaplanong pagkaluma ng mga backup. Kapag nag-index, maaari mong tukuyin ang petsa ng pag-expire ng HashPackage --expires 2019-06-01, at pagkatapos ng petsang ito (mula 00:00), hindi na ito gagamitin. Ang archive mismo ay hindi maaaring tanggalin pagkatapos ng petsang ito (Bagaman ang hashget ay maaaring maginhawang ipakita ang mga URL ng lahat ng mga backup na bulok sa sandaling ito o sa anumang petsa).

Halimbawa, kung gumawa kami ng isang buong backup sa ika-1 at i-index ito nang panghabambuhay hanggang sa katapusan ng buwan, makakakuha kami ng differential backup scheme.

Kung mag-i-index kami ng mga bagong backup sa parehong paraan, magkakaroon ng scheme ng incremental backups.

Hindi tulad ng mga tradisyonal na scheme, hinahayaan ka ng hashget na gumamit ng maraming pinagbabatayan na mapagkukunan. Ang backup ay mababawasan pareho sa pamamagitan ng pagbabawas ng mga file mula sa mga nakaraang backup (kung mayroon man) at ng mga pampublikong file (kung ano ang maaaring i-download).

Kung sa ilang kadahilanan ay hindi kami nagtitiwala sa pagiging maaasahan ng mga mapagkukunan ng Debian (https://snapshot.debian.org/) o gumagamit ng isa pang pamamahagi, maaari lang tayong gumawa ng isang buong backup nang isang beses kasama ang lahat ng mga pakete, at pagkatapos ay umasa dito (sa pamamagitan ng hindi pagpapagana ng heuristics). Ngayon, kung ang lahat ng mga server ng aming mga distribusyon ay lumabas na hindi available sa amin (sa souvenir Internet o sa panahon ng zombie apocalypse), ngunit ang aming mga backup ay maayos, maaari kaming makabawi mula sa anumang short diff backup na umaasa lamang sa aming mga naunang backup. .

Umaasa lang ang Hashget sa mga pinagkakatiwalaang source ng pagbawi sa IYONG paghuhusga. Ang mga itinuturing mong maaasahan ay gagamitin.

FilePool at Glacier

ΠœΠ΅Ρ…Π°Π½ΠΈΠ·ΠΌ FilePool nagbibigay-daan sa iyo na huwag patuloy na makipag-ugnayan sa mga panlabas na server upang mag-download ng mga pakete, ngunit gumamit ng mga pakete mula sa isang lokal na direktoryo o corporate server, halimbawa:

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

o

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

Upang gumawa ng pool sa isang lokal na direktoryo, kailangan mo lamang na lumikha ng isang direktoryo at magtapon ng mga file dito, makikita mismo ng hashget kung ano ang kailangan nito gamit ang mga hash. Upang gawing naa-access ang pool sa pamamagitan ng HTTP, kailangan mong lumikha ng mga symlink sa isang espesyal na paraan; ginagawa ito sa isang utos (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). Ang HTTP FilePool mismo ay mga static na file, kaya ang anumang simpleng web server ay maaaring maghatid nito, ang load sa server ay halos zero.

Salamat sa FilePool, maaari mong gamitin hindi lamang ang (mga) mapagkukunang http bilang mga pangunahing mapagkukunan, kundi pati na rin halimbawa,Amazon Glacier.

Pagkatapos i-upload ang backup sa glacier, kukunin namin ang Upload ID nito at ginagamit namin ito bilang isang URL. Halimbawa:

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

Ngayon, ang mga bagong (differential) na backup ay ibabatay sa backup na ito at magiging mas maikli. Pagkatapos i-unpack ng tar ang diffbackup, makikita natin kung saang mga mapagkukunan ito umaasa:

hashget --info /tmp/unpacked/ list

at gumamit lang ng shell script upang i-download ang lahat ng mga file na ito mula sa Glacier patungo sa pool at patakbuhin ang karaniwang pagbawi: hashget -u /tmp/unpacked β€”pool /tmp/pool

Ang laro ba ay nagkakahalaga ng kandila?

Sa pinakasimpleng kaso, magbabayad ka lang ng mas mababa para sa mga backup (kung iimbak mo ang mga ito sa isang lugar sa cloud para sa pera). Siguro marami, mas kaunti.

Ngunit hindi lang iyon. Ang dami ay nagiging kalidad. Magagamit mo ito para makakuha ng mataas na kalidad na pag-upgrade sa iyong backup scheme. Halimbawa, dahil ang aming mga backup ay mas maikli na ngayon, hindi kami makakagawa ng buwanang pag-backup, ngunit araw-araw. Itabi ang mga ito hindi sa loob ng anim na buwan, tulad ng dati, ngunit sa loob ng 5 taon. Dati, iniimbak mo ito sa mabagal ngunit murang "malamig" na imbakan (Glacier), ngayon ay maaari mo itong iimbak sa mainit na imbakan, kung saan maaari mong palaging mabilis na mag-download ng backup at ibalik ito sa loob ng ilang minuto, hindi sa isang araw.

Maaari mong dagdagan ang pagiging maaasahan ng backup na imbakan. Kung kasalukuyan naming iniimbak ang mga ito sa isang pasilidad ng imbakan, pagkatapos ay sa pamamagitan ng pagbabawas ng dami ng mga backup, magagawa naming iimbak ang mga ito sa 2-3 mga pasilidad ng imbakan at mabubuhay nang walang sakit kung masira ang isa sa mga ito.

Paano subukan at simulan ang paggamit?

Pumunta sa gitlab page https://gitlab.com/yaroslaff/hashget, i-install gamit ang isang utos (pip3 install hashget[plugins]) at basahin at isagawa ang mabilisang pagsisimula. Sa tingin ko aabutin ng 10-15 minuto para magawa ang lahat ng simpleng bagay. Pagkatapos ay maaari mong subukang i-compress ang iyong mga virtual machine, gumawa ng mga file ng pahiwatig kung kinakailangan upang mapalakas ang compression, maglaro sa mga pool, isang lokal na database ng hash at isang hash server kung interesado ka, at sa susunod na araw ay tingnan kung ano ang laki ng incremental na backup ay nasa tuktok ng kahapon.

Pinagmulan: www.habr.com

Magdagdag ng komento