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

Това е обзорна статия за описание на функциите. Действителното използване на hashget (доста просто) е описано в README проект и wiki документация.

Сравнение

Според закона на жанра, ще започна веднага с интригата - сравнявайки резултатите:

Извадка от данни
размер без опаковка
.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 с текст „Здравей свят“?

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

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

Как работи hashget

hashget има понятията Package и HashPackage, с тяхна помощ извършва дедупликация.

Пакет (найлонов плик). Файл (обикновено .deb или .tar.gz архив), който може да бъде изтеглен сигурно от интернет и от който могат да бъдат получени един или повече файлове.

HashPackage — малък JSON файл, представляващ пакет, включително URL адреса на пакета и хеш суми (sha256) на файлове от него. Например, за пакет mariadb-server-core от 5 мегабайта, размерът на хеш-пакета е само 6 килобайта. Около хиляда пъти по-малко.

Дедупликация — създаване на архив без дублиращи се файлове (ако дедупликаторът знае къде може да бъде изтеглен оригиналният пакет, той намалява дубликатите от архива).

Опаковка

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

В най-простия случай самата опаковка не изглежда по-сложна от катран:

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

По-трудни неща

Описаното по-горе вече е достатъчно за тези, които „искат като катран, но да опаковат моя Debian в 4 мегабайта.“ Нека разгледаме по-сложните неща по-късно.

Индексиране

Ако hashget изобщо нямаше нито един HashPackage, тогава той просто нямаше да може да дедупликира нищо.

Можете също да създадете HashPackage ръчно (просто: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), но има по-удобен начин.

За да получите необходимия хеш-пакет, има етап индексиране (изпълнява се автоматично с командата --pack) И евристика. Когато индексира, hashget „подава“ всеки намерен файл на всички налични евристики, които се интересуват от него. Евристиката след това може да индексира всеки пакет, за да създаде HashPackage.

Например, евристиката на Debian харесва файла /var/lib/dpkg/status и открива инсталираните пакети на Debian и ако те не са индексирани (няма създаден HashPackage за тях), ги изтегля и индексира. Резултатът е много хубав ефект - hashget винаги ще дедупликира Debian OS ефективно, дори ако имат най-новите пакети.

Подсказващи файлове

Ако вашата мрежа използва някои от вашите патентовани пакети или публичен пакет, който не е включен в хевристиката на hashget, можете да добавите обикновен файл с подсказки hashget-hint.json към нея по следния начин:

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

След това всеки път, когато се създава архив, пакетът ще бъде индексиран (ако не е бил преди това) и файловете на пакета ще бъдат премахнати от архива. Не е необходимо програмиране, всичко може да се направи от vim и да се записва във всяко архивиране. Моля, обърнете внимание, че благодарение на подхода на хеш-сумата, ако някои файлове от пакета се променят локално (например конфигурационен файл е променен), тогава променените файлове ще бъдат запазени в архива „както е“ и няма да бъдат съкратени.

Ако някои от вашите собствени пакети се актуализират периодично, но промените не са много големи, можете да намекнете само за основните версии. Например във версия 1.0 те направиха подсказка, сочеща към mypackage-1.0.tar.gz, и тя ще бъде напълно дедупликирана, след това пуснаха версия 1.1, която е малко по-различна, но подсказката не беше актуализирана. Всичко е наред. Дедупликират се само файлове, които съответстват (могат да бъдат възстановени до) версия 1.0.

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

HashServer

Би било доста трудоемко да се извърши пълно индексиране при създаване на резервни копия. За да направите това, трябва да изтеглите всеки пакет, да го разопаковате и индексирате. Следователно hashget използва схема с HashServer. Когато бъде открит инсталиран пакет на Debian, ако не е намерен в локалния HashPackage, първо се прави опит за просто изтегляне на HashPackage от хеш сървъра. И само ако това не работи, hashget сам изтегля и хешира пакета (и го качва на 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) ресурси като основни ресурси, но също така например, Амазонски ледник.

След като качим резервното копие на ледника, получаваме неговия идентификатор за качване и го използваме като URL адрес. Например:

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

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

hashget --info /tmp/unpacked/ list

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

Играта струва ли си свещта?

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

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

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

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

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

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