Terminal pogryzł człowieka: zbackup

Na temat tworzenia kopii bezpieczeństwa wrażliwych danych napisano już chyba wszystko. Mamy dziesiątki jeśli nie setki przeróżnych rozwiązań. A to lokalnych, a to zdalnych, z kompresją, bez kompresji, z szyfrowaniem lub bez, zabezpieczane hasłem i długo by jeszcze wymieniać. Dlatego na tle tego wszystkiego zbackup nie wybija się jakimś ambitnym szczegółem. Jednak są niuanse które sprawiają, że zbackup można rozważać jako wydajny system archiwizowania danych.

W ogromnym uproszczeniu program ten można zaprezentować jako rozwiązanie wykorzystujące deduplikację danych podczas tworzenia kolejnych kopii naszych zasobów. Co to oznacza? Raz stworzone archiwum .tar które zgłosimy do zbackup zostanie przeanalizowane pod kątem powtarzających się regionów, tak podzielone (i skatalogowane) oraz skompresowane (LZMA). Kolejne archiwum .tar będzie już korzystało z poprzednich danych i tak dalej, i tak dalej. Jak łatwo sobie wyobrazić, pierwsza kopia będzie miała mniej więcej taką objętość jak oryginalne dane. Ale każda kolejna a także kopie innych danych – już zdecydowanie mniej – ponieważ w repozytorium backupów zapisane zostaną tylko zmiany.

Czy to działa? Łatwo można wyliczyć objętość archiwum, które codziennie tworzy kopię katalogu Obrazy (300MB) za pomocą standardowego tar -cfz. Po miesiącu będziemy tam mieli równiutko 30 razy 300MB paczek tar.gz. Wykorzystując zbackup możemy zminimalizować zużycie przestrzeni dyskowej do ~300MB. Teraz docieramy do poważniejszych rozważań – dlaczego kopie bezpieczeństwa (z deduplikacją) zamiast standardowej synchronizacji systemu plików? (np. rsync, rdiff-backup). Wszak taka synchronizacja również umożliwia wersjonowanie plików i podobne oszczędności, jeżeli archiwizowane pliki się nie zmieniły. Lecz przyznacie, że o wiele prościej jest przywrócić cały katalog z konkretnego dnia (miesiąca, godziny), niż ręcznie wydłubywać pożądane pliki ze zsynchronizowanej przestrzeni plików.

Tak więc takie rozwiązanie ma swoje plusy. A a co z minusami? To rozwiązania przeznaczone dla pomysłowych dłubaczy. Zbackup nie oferuje żadnego interfejsu (ok) i ogranicza zarządzanie naszym backupem do prostych funkcji „zrób backup” i „przywróć backup”. Żadnego przeglądania, listowania, statystyk, itp. O wszystko musimy zatroszczyć się sami, tj. odpowiednio nazywać archiwizowane katalogi, napisać sobie skrypt do automatyzacji tego zadania, itp. Jednak wystarczy to zrobić raz i w zasadzie można o kwestii kopii zapomnieć – reszta będzie działa się „automagicznie”.

Do sprawnego posługiwania się tym narzędziem potrzebujemy minimum wiedzy co w tym programie piszczy. Po pierwsze, zbackup potrzebuje swojej zorganizowanej przestrzeni na kopie bezpieczeństwa:

zbackup init --non-encrypted /tmp/zbackup/

Ciekawscy odkryją, że struktura /tmp/zbackup zawiera kolejne katalogi backups/, bundles/, index/ i info/. Argument non-encrypted powoduje to, co sugeruje jego nazwa – dane nie zostaną zaszyfrowane. Kolejną możliwością jest password-file i wskazanie pliku z hasłem (man 5 zbackup). Oczywiście, nikt przy zdrowych zmysłach nie tworzy takiego repozytorium w katalogu /tmp – powyższe to tylko przykład.

Załóżmy, że zechcemy gromadzić tam kopie katalogu /home/toja/Obrazy. Ciekawostką jest to, że zbackup to narzędzie strumieniowe, zatem:

tar c /home/toja/Obrazy | zbackup backup --non-encrypted /tmp/backup/backups/Obrazy-`date '+%Y-%m-%d'`

To dlatego na początku wspomniałem o archiwach tar, gdyż za pomocą tego polecenia najszybciej zorganizujemy w jeden plik cały nasz katalog z danymi. Można oczywiście backupować pojedynczy plik – wtedy naszym przyjacielem będzie cat mojplik. Ciąg po | jak widać stawia sprawę jasno – żadnej automatyki. Musimy pouczyć zbackup, że chcemy wykonać backup bez szyfrowania, a nazwa pliku będzie taka jak podaliśmy. Wersję określi polecenie date. Jeżeli ktoś chce wykonywać kopie godzinowe musi to uwzględnić w formacie daty.

Zatem mamy kopię. A jak ją teraz przywrócić? Znowu, musimy pamiętać (albo wpisać do raz do skryptu) gdzie znajduje się nasze repozytorium zbackup, określić które archiwum i z jaką datą nas interesuje. Zbackup odtworzy nam elegancko plik .tar w którym odnajdziemy nasze pliki.

zbackup restore --non-encrypted /tmp/zbackup/backups/Obrazy-2016-12-14 > /tmp/Obrazy-2016-12-14.tar

W tej prostocie jest metoda. Nawet bardziej złożony skrypt do backupowania katalogów na naszym serwerze to zaledwie kilka linijek i jeden – dwa parametry. Żadnej złożonej składni, itp. Minusem jest to, że sam zbackup nie oferuje obsługi zdalnych repozytoriów. W przypadku, gdy chcemy backup przechowywać gdzieś na kolejnej maszynie, musimy posłużyć się poleceniem rsync (również jedna linijka w naszym skrypcie). Nie poleciłbym również tego programu do domowego użytku. Na potrzeby naszych desktopów powstało wiele bardziej intuicyjnych (GUI) rozwiązań.

Kolejna sympatyczna rzecz – zbackup znajdziemy w repozytoriach naszych Linuksów – tak po prostu.