Skróć kopie zapasowe o 99,5% przy użyciu hashget

hashget to jest darmowy, open-source deduplikator — narzędzie podobne do archiwizatora, które pozwala znacznie zmniejszyć rozmiar kopii zapasowych, a także zorganizować schematy kopii zapasowych inkrementacyjnych i różnicowych oraz nie tylko.

To artykuł przeglądowy opisujący możliwości. Samo użycie hashget (dość proste) opisano w README projekcie i dokumentacji wiki.

Porównanie

Zgodnie z prawem gatunku, zacznę od intrygi — porównania wyników:

Przykład danych
rozpakowany rozmiar
.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% )

Tło, jaki powinien być idealny i skuteczny backup

Za każdym razem, gdy robiłem kopię zapasową świeżo utworzonej wirtualnej maszyny, nie dawało mi spokoju uczucie, że coś robię źle. Dlaczego uzyskuję tak dużą kopię zapasową systemu, w którym moje bezcenne nieśmiertelne dzieła to tylko jednowierszowy index.html z tekstem „Hello world”?

Dlaczego w mojej kopii zapasowej znajduje się 16-megowy /usr/sbin/mysqld? Czyżby w tym świecie to ja miałem zaszczyt przechowywać ten ważny plik, a jeśli nie uda mi się — będzie on stracony dla ludzkości? Prawdopodobnie nie. Znajduje się on na wysoce niezawodnych serwerach debiana (nieporównywalnych z tym, co mogę zapewnić ja), a także w kopiach zapasowych (milionach ich) innych administratorów. Czy naprawdę musimy tworzyć dla zwiększenia niezawodności 10 000 000 + 1 kopię tego ważnego pliku?

Generalnie hashget i rozwiązuje ten problem. Podczas pakowania — tworzy bardzo małą kopię zapasową. Podczas rozpakowywania — całkowicie rozpakowany system, analogiczny do tego, który byłby przy tar -c / tar -x. (Innymi słowy, to pakowanie bezstratne)

Jak działa hashget

W hashget istnieją pojęcia Package i HashPackage, za pomocą których wykonuje deduplikację.

Pakiet (pakiet). Plik (zwykle archiwum .deb lub .tar.gz), który można pewnie pobrać z sieci i z którego można uzyskać jeden lub więcej plików.

HashPackage — mały plik JSON, reprezentujący Package, w tym zawierający URL pakietu i sumy kontrolne (sha256) plików z niego. Na przykład dla pakietu mariadb-server-core o rozmiarze 5 megabajtów, rozmiar hashpackage wynosi tylko 6 kilobajtów. Około tysiąc razy mniej.

Dedupikacja — tworzenie archiwum bez zduplikowanych plików (jeśli deduplikator wie, gdzie można pobrać oryginalny pakiet, skraca duplikaty w archiwum).

Pakowanie

Podczas pakowania przeglądane są wszystkie pliki z katalogu, który jest pakowany, obliczane są ich sumy kontrolne, a jeśli suma znajduje się w jednym z znanych HashPackage, metadane pliku (nazwa, suma kontrolna, uprawnienia itp.) są zapisywane w specjalnym pliku .hashget-restore.json, który również zostanie dołączony do archiwum.

Samo pakowanie w najprostszej formie nie wygląda bardziej skomplikowanie niż tar:

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

Rozpakowanie

Rozpakowywanie odbywa się w dwóch etapach. Najpierw zwykłe rozpakowywanie tar:

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

następnie przywracanie z sieci:

hashget -u /path/to/data

Podczas przywracania hashget odczytuje plik .hashget-restore.json, pobiera potrzebne pakiety, rozpakowuje je i ekstrakcji potrzebnych plików, instalując je w odpowiednich ścieżkach, z odpowiednimi owner/group/permissions.

Bardziej skomplikowane rzeczy

To, co zostało opisane powyżej — jest już wystarczające dla tych, którzy "chcą jak tar, ale aby spakować mojego Debiana w 4 megabajty". Następnie przyjrzymy się bardziej skomplikowanym rzeczom.

Indeksowanie

Jeśli hashget nie miałby żadnego HashPackage, nie byłby w stanie niczego deduplikować.

Można także ręcznie utworzyć HashPackage (prosto: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my), ale istnieje wygodniejsza droga.

Aby uzyskać potrzebne hashpackage, istnieje etap indeksowania (automatycznie wykonywany podczas polecenia --pack) i heurystyki. Podczas indeksowania hashget "podaje" każdy znaleziony plik wszystkim znanym heurystykom, które go interesują. Heurystyki mogą następnie zindeksować jakiś Package, aby stworzyć HashPackage.

Na przykład, heurystyka Debiana lubi plik /var/lib/dpkg/status i wykrywa zainstalowane pakiety debiana, a jeśli nie są zindeksowane (nie stworzono dla nich HashPackage), pobiera je i indeksuje. Powstaje bardzo przyjemny efekt — hashget zawsze będzie skutecznie deduplikować systemy operacyjne Debiana, nawet jeśli zawierają najnowsze pakiety.

Pliki-podpowiedzi (hints)

Jeśli w Twojej sieci używasz jakiegoś własnego pakietu lub publicznego pakietu, który nie jest uwzględniony w heurystykach hashget, możesz dodać prosty plik hint hashget-hint.json według wzoru:

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

Następnie, za każdym razem, gdy tworzony jest archiwum, pakiet będzie indeksowany (jeśli nie był wcześniej), a pliki pakietu zostaną usunięte z archiwum. Nie ma potrzeby programowania, wszystko można zrobić w vim, co pozwala zaoszczędzić przy każdym kopii zapasowej. Zauważ, że dzięki podejściu opartemu na sumach kontrolnych, jeśli niektóre pliki pakietu zostaną lokalnie zmodyfikowane (na przykład plik konfiguracyjny) — zmienione pliki zostaną zachowane w archiwum „tak jak są”, nie będą skracane.

Jeśli jakiś Twój własny pakiet jest okresowo aktualizowany, ale zmiany nie są zbyt duże, można zrobić hint tylko dla głównych wersji. Na przykład w wersji 1.0 zrobiono hint wskazujący na mypackage-1.0.tar.gz, a on będzie całkowicie deduplikowany, potem wydano wersję 1.1, która nieco się różni, a hint nie został zaktualizowany. Nic się nie dzieje. Deduplicowane są tylko pliki, które pasują (które można odzyskać) do wersji 1.0.

Heurystyka, która przetwarza plik hint — to dobry przykład na zrozumienie wewnętrznego działania heurystyk. Przetwarza tylko pliki hashget-hint.json (lub .hashget-hint.json z kropką) i ignoruje wszystkie inne. Na podstawie tego pliku ustala, jaki URL pakietu powinien zostać zaindeksowany, a hashget go indeksuje (jeśli to nie zostało wcześniej zrobione).

HashServer

Byłoby dość pracochłonne przy tworzeniu kopii zapasowych w pełni przeprowadzić indeksację. Wymagałoby to pobrania każdego pakietu, rozpakowania, a następnie indeksowania. Dlatego hashget korzysta z schematu z HashServer. Gdy zostanie wykryty zainstalowany pakiet debianowy, jeśli nie zostanie znaleziony w lokalnych HashPackage, najpierw próbuje pobrać HashPackage z serwera hash. Dopiero jeśli to się nie uda — hashget sam pobiera i hashuje pakiet (i przesyła na hashserver, aby później hashserver go udostępniał).

HashServer to nieobowiązkowy element schematu, niekrytyczny, służy wyłącznie do przyspieszenia i zmniejszenia obciążenia repozytoriami. Łatwo go wyłączyć (opcją --hashserver bez parametrów). Ponadto, można łatwo stworzyć własny hashserver.

Kopie zapasowe inkrementalne i różnicowe, zaplanowane wygasanie

hashget umożliwiają bardzo łatwe stworzenie schematu kopii zapasowych inkrementalnych i różnicowych. Dlaczego nie zindeksować naszego własnego backupu (ze wszystkimi naszymi unikalnymi plikami)? Jedna komenda --submit I wszystko gotowe! Następna kopia zapasowa, którą utworzy hashget, nie będzie zawierać plików z tego archiwum.

Jednak to nie jest najlepsze podejście, ponieważ może się zdarzyć, że podczas przywracania będziemy musieli przeszukiwać wszystkie kopie zapasowe hashget w całej historii (jeśli w każdej z nich będzie przynajmniej jeden unikalny plik). W tym celu istnieje mechanizm planowanego wygaszania kopii zapasowych. Przy indeksowaniu można określić datę wygaszenia HashPackage --expires 2019-06-01, a po nadejściu tej daty (od 00:00) nie będzie już używany. Samego archiwum po tej dacie nie trzeba usuwać (choć hashget może wygodnie pokazać URL-e wszystkich kopii zapasowych, które są już przestarzałe/wygasną do tej pory lub w dowolnej dacie).

Na przykład, jeśli 1. dnia będziemy robić pełną kopię zapasową, i indeksować ją z czasem życia do końca miesiąca — uzyskamy schemat kopii zapasowej różnicowej.

Jeśli również będziemy indeksować nowe kopie zapasowe — otrzymamy schemat kopii zapasowych inkrementalnych.

W przeciwieństwie do tradycyjnych schematów, hashget pozwala na użycie kilku podstawowych źródeł. Kopia zapasowa zostanie skrócona zarówno dzięki skróceniu plików z poprzednich kopii zapasowych (jeśli istnieją), jak i dzięki plikom publicznym (to, co można pobrać).

Jeśli z jakiegoś powodu nie ufamy niezawodności zasobów debianowych (https://snapshot.debian.org/) lub używamy innej dystrybucji, możemy po prostu raz zrobić pełną kopię zapasową ze wszystkimi pakietami i później opierać się na niej (wyłączając heurystykę). Teraz, jeśli wszystkie serwery naszych dystrybucji będą dla nas niedostępne (w suwenirowym internecie lub podczas apokalipsy zombie), ale nasze kopie zapasowe będą w porządku — będziemy mogli przywrócić się z dowolnej krótkiej różnicowej kopii zapasowej, opierając się tylko na naszych wcześniejszych kopiach zapasowych.

Hashget opiera się tylko na niezawodnych źródłach przywracania według WASZEGO uznania. To, co uważasz za niezawodne — to będzie użyte.

FilePool i Glacier

Mechanizm FilePool pozwala nie polegać stale na zewnętrznych serwerach do pobierania pakietów, a zamiast tego używać pakietów z lokalnego katalogu lub serwera korporacyjnego, na przykład:

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

lub

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

Aby utworzyć pulę w lokalnym katalogu, wystarczy po prostu stworzyć katalog i wrzucić do niego pliki, hashget sam znajdzie to, czego potrzebuje według hashy. Aby udostępnić pulę przez HTTP, należy w specjalny sposób utworzyć symlinki, co można zrobić jedną komendą (hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool). Sam HTTP FilePool to statyczne pliki, więc może go obsługiwać każdy najprostszy serwer WWW, obciążenie serwera jest prawie zerowe.

Dzięki FilePool jako podstawowe zasoby można wykorzystać nie tylko zasoby HTTP(S), ale i, na przykład, Amazon Glacier.

Po przesłaniu kopii zapasowej na Glacier uzyskujemy jej Upload ID i używamy go jako URL. Na przykład:

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

Teraz nowe (różnicowe) kopie zapasowe będą opierały się na tej kopii i będą krótsze. Po rozpakowaniu różnicowej kopii zapasowej możemy zobaczyć, na jakie zasoby się opiera:

hashget --info /tmp/unpacked/ list

i po prostu shell skryptem pobrać z Glacier wszystkie te pliki do puli i uruchomić zwykłe przywracanie: hashget -u /tmp/unpacked --pool /tmp/pool

Czy warto się starać?

W najprostszym przypadku - po prostu zapłacisz mniej za kopie zapasowe (jeśli przechowujesz je gdzieś w chmurze za opłatą). Może to być znacznie mniej.

Ale to nie wszystko. Ilość przechodzi w jakość. Możesz to wykorzystać, aby uzyskać jakościową aktualizację schematu kopii zapasowych. Na przykład, skoro nasze kopie zapasowe są teraz krótsze - można robić nie miesięczne kopie zapasowe, ale codzienne. Przechowywać je nie pół roku, jak wcześniej, ale 5 lat. Wcześniej przechowywaliśmy w wolnym, ale tanim "zimnym" magazynie (Glacier), teraz możesz przechowywać w gorącym, skąd zawsze można szybko pobrać kopię zapasową i przywrócić ją w kilka minut, a nie przez dzień.

Można zwiększyć niezawodność przechowywania kopii zapasowych. Jeśli teraz przechowujemy je w jednym magazynie, to skracając objętość kopii zapasowych - możemy przechowywać w 2-3 magazynach i bez bólu przetrwać, jeśli jeden z nich ulegnie uszkodzeniu.

Jak spróbować i zacząć korzystać?

Wchodzimy na stronę GitLab https://gitlab.com/yaroslaff/hashget, instalujemy jedną komendą (pip3 install hashget[plugins]) i po prostu czytamy i wykonujemy quick-start. Myślę, że wykonanie wszystkich prostych zadań zajmie 10-15 minut. Potem można spróbować zoptymalizować swoje wirtualki, stworzyć w razie potrzeby pliki hint, aby uzyskać lepszą kompresję, pobawić się pulami, lokalną bazą hashy i serwerem haszy, jeśli będzie to interesujące, a następnego dnia sprawdzić, jaki będzie rozmiar inkrementalnej kopii zapasowej na wczorajszej.

Źródło: habr.com

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster