hashget е безплатен, с отворен код дедупликатор — утилита, подобна на архиватор, която позволява значително да се намали размерът на резервните копия, както и да се организират схеми за инкрементално и диференциално резервно копиране и не само.

Това е обзорна статия, която описва възможностите. Самото използване на hashget (доста просто) е описано в README проекта и wiki документацията.

Сравнение

По закона на жанра, ще започна веднага с интригата — сравнение на резултатите:

Данни
разопакован размер
.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% )

Предисторията, какъв трябва да бъде идеалният и ефективен резервен копие

Всеки път, когато правех резервно копие на новосъздадена виртуална машина, не ме оставяше чувството, че правя нещо нередно. Защо получавам тежко резервно копие от система, където моето безценно, нетленно творчество — е едноредов index.html с текста „Hello world“?

Защо в резервното ми копие има 16-мегабайтния /usr/sbin/mysqld? Не ми ли се е паднало да съхранявам този важен файл по единствен начин, и ако не успея — той ще бъде загубен за човечеството? Най-вероятно не. Той се съхранява на високо надеждни сървъри на debian (надеждността и непрекъснатостта на които не могат да се сравнят с това, което мога да осигуря), а също така в резервни копия (милиони от тях) на други администратори. Наистина ли трябва да създаваме 10 000 000 + 1-ва копия на този важен файл, за да увеличим надеждността?

По принцип hashget и решава този проблем. При опаковане — той създава много малко резервно копие. При разопаковане — напълно разопакована система, аналогична на тази, която би била при tar -c / tar -x. (С други думи, това е без загуби опаковане)

Как работи hashget

В hashget има понятия Package и HashPackage, с които той изпълнява дедупликация.

Package (пакет). Файл (обикновено архив .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 и открива инсталираните дебian пакети и ако те не са индексирани (за тях не са създадени 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 се направи hint с посочване на mypackage-1.0.tar.gz, и той ще бъде напълно дедуплициран, след това се пусна версия 1.1, която леко се различава, а hint не се актуализира. Няма проблем. Дедуплицират се само файловете, които съвпадат (които могат да бъдат възстановени) с версия 1.0.

Евристиката, която обработва hint-файла — добър пример за разбиране на вътрешния механизъм на работа на евристиките. Тя обработва само файлове hashget-hint.json (или .hashget-hint.json с точка) и игнорира всички останали. По този файл тя определя, какъв URL на пакета трябва да бъде индексиран, и hashget го индексира (ако това не е направено по-рано).

HashServer

Би било доста трудоемко при създаване на копия да се извършва пълно индексиране. За това е нужно да се свали всеки пакет, да се разархивира и да се индексира. Затова hashget използва схема с HashServer. При откритие на инсталиран debian пакет, ако той не бъде намерен в локалните HashPackage, първо се прави опит просто да се свали HashPackage от хеш-сервера. И само ако това не е успешно — hashget сам сваля и хешира пакета (и го качва на hashserver, за да може впоследствие hashserver да го предоставя).

HashServer — не е задължителен елемент на схемата, не е критичен, служи изключително за ускоряване и намаляване на натоварването на хранилищата. Лесно се изключва (опцията --hashserver без параметри). Освен това, лесно можете да направите собствен hashserver.

Инкрементални и диференциални копия, планирано остаряване

hashget позволява много лесно да се създаде схема на инкрементални и диференциални копия. Защо да не индексираме самото си копие (с всички наши уникални файлове)? Една команда --submit и всичко е готово! Следващото архивиране, което ще създаде hashget, няма да включва файловете от този архив.

Но това не е много добър подход, тъй като може да се окаже, че при възстановяване трябва да извикаме всички архиви hashget от цялата история (ако в всеки от тях има поне един уникален файл). За това има механизъм за планирано остаряване на архивите.При индексиране може да се посочи дата на остаряване на HashPackage --expires 2019-06-01, и след настъпването на тази дата (в 00:00), той няма да бъде използван. Самият архив може след тази дата да не се изтрива (въпреки че hashget може удобно да покаже URL адресите на всички архиви, които са ни изтекли/ще изтекат в момента или на всяка дата).

Например, ако на 1-во число направим пълно архивиране и го индексираме с времеви живот до края на месеца — ще получим схема на диференциално архивиране.

Ако също така индексираме и новите архиви — ще има схема на инкрементално архивиране.

За разлика от традиционните схеми, hashget позволява да се използват няколко основни източника. Архивът ще бъде намален както чрез премахване на файлове от предишни архиви (ако има такива), така и чрез публични файлове (тези, които могат да се изтеглят).

Ако по някаква причина не се доверяваме на надеждността на Debian ресурсите (https://snapshot.debian.org/) или използваме друга дистрибуция, просто можем да направим едно пълно архивиране с всички пакети и впоследствие да се опираме на него (изключвайки хевристиката). Сега, ако всички сървъри на нашите дистрибуции се окажат недостъпни (в сувенирния интернет или при зомби-апокалипсис), но нашите архиви са в ред — ще можем да се възстановим от всяко кратко диф-архивиране, опирайки се само на нашите по-ранни архиви.

Hashget се опира само на надеждни източници за възстановяване по ВАШЕ желание. Каквито вие считате за надеждни — те и ще бъдат използвани.

FilePool и Glacier

Механизмът FilePool позволява да не се обръщате постоянно към външни сървъри за изтегляне на пакети, а да използвате пакети от локален каталог или корпоративен сървър, например:

$ 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

Сега новите (диференциални) бекъпи ще се основават на този бекъп и ще са по-кратки. След разархивирането на дифбекъпа можем да видим на какви ресурси разчита:

hashget --info /tmp/unpacked/ list

и просто с шел-скрипт да изтеглим всички тези файлове от гласьера в пула и да стартираме обикновено възстановяване: hashget -u /tmp/unpacked --pool /tmp/pool

Какво е положението?

В най-простия случай — просто ще плащате по-малко за бекъпи (ако ги съхранявате някъде в облака платено). Може би — много-много по-малко.

Но това не е всичко. Количеството преминава в качество. Можете да използвате това, за да получите качествен ъпгрейд на схемата на бекъпите. Например, сега бекъпите ни са по-кратки — можем да правим не месечен бекъп, а ежедневен. Да ги съхраняваме не половин година, както преди, а 5 години. По-рано съхранявахме в бавен, но евтин „ студен“ склад (Glacier), сега можете да съхранявате в горещ, откъдето можете да изтеглите бекъп бързо и да се възстановите за минути, а не за ден.

Можете да увеличите надеждността на съхранението на бекъпи. Ако в момента ги съхраняваме в едно хранилище, то като намалим обема на бекъпите — можем да ги съхраняваме в 2-3 хранилища и безболезнено да преживеем, ако едно от тях се повреди.

Как да опитате и да започнете да ползвате?

Отиваме на страницата в GitLab https://gitlab.com/yaroslaff/hashget, инсталираме с една команда (pip3 install hashget[plugins]) и просто следвайте quick-start. Смятам, че всички основни задачки ще отнемат около 10-15 минути. След това можете да опитате да компресирате виртуалките си, да създадете хинт-файлове, ако е необходимо, за по-силно свиване, да поиграете с пуловете, локалната база от хешове и хеш-сървъра, ако ви е интересно, а на следващия ден да видите какъв ще е размерът на инкременталния бекъп спрямо вчерашния.

Източник: habr.com