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 с текста "Здравей свят"?

Защо в моя бекъп има 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 и открива инсталираните debian пакети, и ако те не са индексирани (за тях не са създадени HashPackage), ги изтегля и индексира. Получава се много приятен ефект — hashget винаги ще може да дедуплицира дебиянските ОС, дори ако те имат най-новите пакети.

Файлове-подсказки (hintове)

Ако в мрежата ви се използва някакъв ваш собствен проприетарен пакет или публичен пакет, който не е включен в евристиките на 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

и просто със shell скрипт да изтеглим от глетчера всичките тези файлове в пул и да стартираме обикновено възстановяване: 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 минути. След това можем да опитаме да компресираме виртуалките си, да направим, ако е необходимо, hint-файлове, за да се компресират още повече, да поиграем с пуловете, локалната база от хешове и хешсервера, ако ни е интересно, а на следващия ден да видим какъв ще е размерът на инкременталния бекъп върху вчерашния.

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