- гэта бясплатны, оперсорсный дэдуплікатар - падобная на архіватар утыліта, якая дазваляе значна скараціць памер бэкапаў, а таксама арганізаваць схемы інкрыментальнага і дыферэнцыяльнага бэкапу і не толькі.
Гэта аглядны артыкул для апісання магчымасцяў. Само выкарыстанне hashget (даволі простае) апісана ў праекта і .
параўнанне
Па законе жанру, пачну адразу з інтрыгі - параўнання вынікаў:
Выбар дадзеных
unpacked size
.tar.gz
hashget .tar.gz
WordPress-5.1.1
43 Mb
11 Mb ( 26% )
155 Kb ( 0.3% )
Linux ядро 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% )
Перадгісторыя, якім павінен быць ідэальны і эфектыўны бэкап
Кожны раз, калі я рабіў бэкап свежастворанай віртуалкі, мне не давала спакою пачуццё, што я нешта раблю не так. Чаму ў мяне атрымліваецца важкі бэкап ад сістэмы, дзе маёй неацэннай нятленнай творчасці – аднарадковы index.html з тэкстам «Hello world»?
Чаму ў маім бэкапу ёсць 16-мегабайтны /usr/sbin/mysqld? Няўжо ў гэтым свеце менавіта мне выпаў гонар захоўваць гэты важны файл, і калі я не зладжуся - ён будзе страчаны для чалавецтва? Хутчэй за ўсё няма. Ён захоўваецца на высоканадзейных серверах debian (надзейнасць і бесперабойнасць якіх ні ў якое параўнанне не ідзе з тым, што магу забяспечыць я), а таксама ў рэзервовых копіях (мільёнах іх) іншых адмінаў. Ці сапраўды нам трэба ствараць для падвышэння надзейнасці 10 + 000'ую копію гэтага важнага файла?
Увогуле-то і вырашае гэтую праблему. Пры пакаванні - ён стварае вельмі маленькі бэкап. Пры распакаванні - цалкам распакаваную сістэму, аналагічную той, якая была б пры tar -c / tar -x. (Іншымі словамі, гэта lossless ўпакоўка)
Як працуе hashget
У hashget ёсць паняцці Package і HashPackage, з іх дапамогай ён выконвае дэдуплікацыю.
пакет (пакет). Файл (звычайна архіў .deb ці .tar.gz), які можна надзейна спампаваць з сеткі, і з якога можна атрымаць адзін ці больш файлаў.
HashPackage - невялікі JSON файл, які прадстаўляе Package, у тым ліку які змяшчае URL пакета і хэш-сумы (sha256) файлаў з яго. Напрыклад, для пакета mariadb-server-core памерам 5 мегабайт памер hashpackage усяго 6 кілабайт. Прыкладна ў тысячу разоў менш.
Дэдуплікацыя - стварэнне архіва без дубляваных файлаў (калі дэдупліктар ведае, дзе можа быць запампаваны арыгінал пакета, ён скарачае дублі з архіва).
Запакоўка
Пры пакаванні праглядаюцца ўсе файлы з пакаванага каталога, лічацца іх хэш-сумы, і калі сума знойдзена ў адным з вядомых HashPackage, то метададзеныя аб файле (імя, хэш, правы доступу і т.д.) захоўваюцца ў адмысловы файл .hashget-restore.json, які таксама будзе ўключаны ў архіў.
Сама запакоўка ў найпростым выпадку выглядае не складаней tar'а:
hashget -zf /tmp/mybackup.tar.gz --pack /path/to/dataраспакаванне
Распакоўка робіцца ў два этапы. Спачатку звычайная tar распакаванне:
tar -xf mybackup.tar.gz -C /path/to/dataзатым аднаўленне з сеткі:
hashget -u /path/to/dataПры аднаўленні hashget чытае файл .hashget-restore.json, спампоўвае неабходныя пакеты, распакоўвае іх, і здабывае неабходныя файлы, усталёўваючы іх на патрэбныя шляхі, з патрэбнымі owner/group/permissions.
Больш складаныя рэчы
Тое, што апісана вышэй – ужо дастаткова, для тых, каму "хачу як tar, але каб спакаваў мой Debian у 4 мегабайта". Далей паглядзім больш складаныя рэчы.
Індэксаванне
Калі ў hashget зусім не было б ніводнага HashPackage, то ён проста не змог бы нічога дэдуплікаваць.
Стварыць HashPackage можна і ўручную (проста: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), але ёсць шлях зручней.
Для таго, каб атрымаць патрэбныя hashpackage, ёсць этап індэксавання (ён аўтаматычна выконваецца пры камандзе --pack) І эўрыстыкі. Пры індэксаванні hashget "скормлівае" кожны знойдзены файл усім наяўным эўрыстыкам, якім ён цікавы. Эўрыстыкі затым могуць праіндэксаваць які-небудзь Package, каб стварыць HashPackage.
Напрыклад, дэбіянаўская эўрыстыка кахае файл /var/lib/dpkg/status і выяўляе ўсталяваныя debian пакеты, і калі яны не праіндэксаваныя (для іх не створаны HashPackage), спампоўвае і індэксуе іх. Атрымліваецца вельмі прыемны эфект - hashget заўсёды будзе эфектыўна дэдуплікаваць дэбіянаўскія АС, нават калі на іх ёсць самыя новыя пакеты.
Файлы-падказкі (хінты)
Калі ў вашай сетцы выкарыстоўваецца нейкі ваш прапрыетарны пакет або публічны пакет, які не ўключаны ў эўрыстыкі hashget, вы можаце дадаць у яго просты hint-файл hashget-hint.json па ўзоры:
{
"project": "wordpress.org",
"url": "https://ru.wordpress.org/wordpress-5.1.1-ru_RU.zip"
}Далей, кожны раз пры стварэнні архіва пакет будзе праіндэксаваны (калі не быў раней), і файлы пакета будуць дэдуплікаваны з архіва. Не трэба ніякага праграмавання, усё можна зрабіць з vim і зэканоміць у кожным бэкапе. Заўважце, што дзякуючы падыходу праз хэшсумы, калі нейкія файлы з пакета будуць зменены лакальна (напрыклад, зменены файл канфігурацыі) - то змененыя файлы захаваюцца ў архіве "як ёсць" не буду скарочаныя.
Калі нейкі ваш уласны пакет абнаўляецца перыядычна, але змены не вельмі вялікія, можна рабіць hint толькі для асноўных версій. Напрыклад, у версіі 1.0 зрабілі хінт з указаннем на mypackage-1.0.tar.gz, і яна будзе цалкам дэдуплікавацца, затым выпусцілі версію 1.1, якая крыху адрозніваецца, а хінт не абнавілі. Нічога страшнага. Дэдупліцыруюцца толькі файлы, якія супадаюць (якія можна аднавіць) з версіяй 1.0.
Эўрыстыка, якая апрацоўвае hint-файл - добры прыклад для разумення ўнутранага механізму працы эўрыстык. Ён апрацоўвае толькі файлы hashget-hint.json (ці .hashget-hint.json з кропкай) і ігнаруе ўсе астатнія. Па гэтым файле ён вызначае, які URL пакета павінен быць праіндэксаваны, і hashget яго індэксуе (калі гэтага не было зроблена раней)
HashServer
Было б даволі працаёмка пры стварэнні бэкапаў поўнасцю выконваць індэксаванне. Для гэтага трэба спампаваць кожны пакет, распакаваць, праіндэксаваць. Таму hashget выкарыстоўвае схему з . Пры выяўленні ўсталяванага debian'аўскага пакета, калі ён не знойдзецца ў лакальных HashPackage, спачатку робіцца спроба проста спампаваць HashPackage з хэш-сервера. І толькі калі гэта не атрымліваецца — hashget сам спампоўвае і хэшуе пакет (і загружае на hashserver, каб у далейшым hashserver яго даваў).
HashServer - не абавязковы элемент схемы, не крытычны, служыць выключна для паскарэння і зніжэння нагрузкі на рэпазітары. Лёгка адключаецца (опцыяй --hashserver без параметраў). Акрамя таго, лёгка можна .
Інкрыментальныя і дыферэнцыяльныя бэкапы, запланаванае састарэнне
дазваляе вельмі проста зрабіць схему . Чаму б нам не праіндэксаваць сам наш бэкап (з усімі нашымі ўнікальнымі файламі)? Адна каманда --submit і ўсё гатова! Наступны бэкап, які створыць hashget, не будзе ўключаць файлы з гэтага архіва.
Але гэта не вельмі добры падыход, таму што можа аказацца так, што пры аднаўленні нам давядзецца тузаць усе hashget-бэкапы за ўсю гісторыю (калі ў кожным будзе хаця б адзін унікальны файл). Для гэтага ёсць механізм . Пры індэксаванні можна пазначыць дату састарэння HashPackage --expires 2019-06-01, і па наступленні гэтай даты (c 00:00), ён не будзе выкарыстаны. Сам архіў можна пасля гэтай даты не выдаляць.
Напрыклад, калі 1-га чысла рабіць фул бэкап, і індэксаваць яго з часам жыцця да канца месяца - мы атрымаем схему дыферэнцыяльнага бэкапу.
Калі гэтак жа будзем індэксаваць і новыя бэкапы - будзе схема інкрыментальных бэкапаў.
У адрозненне ад традыцыйных схемаў, hashget дазваляе выкарыстоўваць некалькі базавых крыніц. Бекап будзе скарочаны і за кошт скарачэння файлаў з папярэдніх бэкапаў (калі яны ёсць), і за кошт публічных файлаў (тое, што можна выпампаваць).
Калі мы па нейкай прычыне не давяраем надзейнасці дэбіянаўскіх рэсурсаў () або выкарыстоўвае іншы дыстрыбутыў, мы проста можам адзін раз зрабіць поўны бэкап з усімі пакетамі, і далей абапірацца ўжо на яго (). Зараз, калі ўсе серверы нашых дыстрыбутываў апынуцца нам недаступныя (у сувенірным Інтэрнэце або пры зомбі-апакаліпсісе), але нашы бэкапы будуць у парадку - мы зможам аднавіцца з любога кароткага дыф-бэкапу, які абапіраецца толькі на нашы больш раннія бэкапы.
Hashget абапіраецца толькі на надзейныя крыніцы аднаўлення па Вашым меркаванні. Якія вы лічыце надзейнымі - тыя і будуць выкарыстаныя.
FilePool і Glacier
механізм дазваляе не звяртацца стала да вонкавых сервераў для запампоўкі пакетаў, а выкарыстоўваць пакеты з лакальнага каталога ці карпаратыўнага сервера, напрыклад:
$ hashget -u . --pool /tmp/poolабо
$ hashget -u . --pool http://myhashdb.example.com/Каб зрабіць пул у лакальным каталогу - досыць проста стварыць каталог і накідаць у яго файлаў, hashget сам па хешах знойдзе тое, што яму трэба. Каб зрабіць пул даступным праз HTTP, трэба спецыяльным чынам стварыць сімлінкі, гэта робіцца адной камандай (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). Сам HTTP FilePool - гэта статычныя файлы, так што абслугоўваць яго можа любы найпросты вэбсервер, нагрузка на сервер амаль нулявая.
Дзякуючы FilePool у якасці базавых рэсурсаў можна выкарыстоўваць не толькі рэсурсы на http(s), але і, , Amazon Glacier.
Пасля аплаада бэкапу на гласьер атрымліваем яго Upload ID і выкарыстаем яго ў якасці URL. Напрыклад:
hashget --submit Glacier_Upload_ID --file /tmp/my-glacier-backup.tar.gz --project glacier --hashserver --expires 2019-09-01Цяпер новыя (дыферэнцыяльныя) бэкапы будуць абапірацца на гэты бэкап і будуць карацейшыя. Пасля tar распакавання дыфбэкапу мы можам паглядзець, на якія рэсурсы ён абапіраецца:
hashget --info /tmp/unpacked/ listі проста шелл-скрыптам спампаваць з гласьера ўсе гэтыя файлы ў pool і запусціць звычайнае ўзнаўленне: hashget -u /tmp/unpacked -pool /tmp/pool
Ці варта аўчынка выраба
У найпростым выпадку - вы проста будзеце менш плаціць за бэкапы (калі вы іх захоўваеце дзесьці ў воблаку за грошы). Можа быць - значна-значна менш.
Але гэта не адзінае. Колькасць пераходзіць у якасць. Можаце выкарыстоўваць гэта, каб атрымаць якасны апгрэйд схемы бэкапаў. Напрыклад, раз бэкапы ў нас цяпер карацейшыя — можна рабіць не штомесячны бэкап, а штодзённы. Захоўваць іх не паўгода, як раней, а 5 год. Раней захоўвалі ў павольным але танным "халодным" сховішчы (Glacier), зараз можаце захоўваць у гарачым, адкуль можна заўсёды хутка спампаваць бэкап і аднавіцца за хвіліны, а не за дзень.
Можна павялічыць надзейнасць захоўвання бэкапаў. Калі зараз мы іх захоўваем у адным сховішчы, то скараціўшы аб'ём бэкапаў - зможам захоўваць у 2-3 сховішчах і бязбольна перажыць, калі адно з іх пашкодзіцца.
Як паспрабаваць і пачаць карыстацца?
Заходзім на гітлаб старонку , усталёўваны адной камандай (pip3 install hashget[plugins]) і проста чытаем-выконваем quick-start. Думаю, усё простыя рэчы зрабіць - зойме хвілін 10-15. Затым можна паспрабаваць паціснуць свае віртуалкі, зрабіць, калі трэба, хінт-файлы, каб уціскалася мацней, пагуляцца з пуламі, лакальнай базай хэшаў і хэшсерверам, калі цікава будзе, а на наступны дзень паглядзець, які будзе памер інкрыментальнага бэкапа па-над учорашнім.
Крыніца: habr.com