Linuks i taśma sprawiają wrażenie pary idealnej.
Narzędzia są elastyczne. Automatyzacja jest możliwa. Można oskryptować dokładnie to, co potrzebne, decydować o podziale danych, weryfikować wszystko, prowadzić katalogi po swojemu i nie płacić za ociężałe pakiety komercyjne. Dla odpowiedniego administratora taka swoboda jest niezwykle pociągająca.
W tym też miejscu wiele procedur taśmowych traci stabilność.
Możliwość oskryptowania to nie to samo co przejrzystość procedur
Oto pułapka.
Własna procedura taśmowa w Linuksie może wyglądać elegancko w terminalu i okazać się koszmarem w dniu przywracania danych. Zadania tar, polecenia mt, punkty montowania LTFS, niestandardowe manifesty, generowane indeksy, mapowania kodów kreskowych, pliki sum kontrolnych, logika buforowania: każdy element z osobna może mieć głęboki sens, podczas gdy cały system pozostaje zrozumiały wyłącznie dla osoby, która go złożyła.
Niedawne dyskusje o narzędziach taśmowych pod Linuksem stale powracały do tego dylematu. Użytkownicy mieli dobre powody, by oczekiwać przejrzystych procedur skryptowych: nie chcieli tkwić w zamkniętych formatach ani ukrytych katalogach. Zależało im na procesie, który można skontrolować i kontrolować.
Ten instynkt jest zdrowy. Pozostaje jednak zdrowy tylko wtedy, gdy procedury zachowują czytelność po upływie czasu.
Taśma obnaża każdy brak w dokumentacji
Ponieważ z taśm zazwyczaj nie korzysta się codziennie z pełnym zaangażowaniem emocjonalnym.
Zadania działają. Nośniki rotują. Mijają tygodnie i miesiące. Pewnego dnia trzeba przywrócić ważne dane i nagle każde nieudokumentowane założenie staje się zagrożeniem. Który zestaw archiwalny należał do danej sekwencji taśm? Która wersja skryptu zapisała tę partię? Czy kompresja była włączona? Gdzie jest manifest? Na której maszynie zapisano instrukcje przywracania? Czy katalog jest na tyle odizolowany, by przetrwać awarię, która wymusiła przywracanie danych?
Skryptowy przepływ pracy, który nie daje jasnych odpowiedzi na te pytania, nie jest jeszcze dojrzały, bez względu na to, jak zgrabnie wygląda kod powłoki.
Dobre procedury taśmowe w Linuksie są do bólu jednoznaczne
Do takiego standardu warto dążyć.
Konsekwentnie generują manifesty. Rejestrują, gdzie co trafiło. Weryfikują zapisy. Dokumentują kroki przywracania poza maszyną wykonującą backup. Dbają o przewidywalny podział na nośniki. Definiują zasady etykietowania. Unikają improwizacji. Krótko mówiąc: poświęcają odrobinę elegancji na rzecz znacznie wyższej trwałości.
Dlatego część zespołów przechodzi w końcu od zestawu sprytnych skryptów do pełnego oprogramowania do kopii zapasowych: nie dlatego, że Linux ich zawiódł, lecz dlatego, że ramy organizacyjne stały się ważniejsze niż przyjemność z ręcznej kontroli.
A czasem bywa odwrotnie: starannie przygotowane procedury linuksowe okazują się właściwym rozwiązaniem, ponieważ administratorzy wykazują dyscyplinę niezbędną do zachowania ich trwałości.
Każdy z tych rezultatów jest w porządku. Niebezpieczne jest jedynie założenie, że samo istnienie skryptów dowodzi istnienia działającego systemu backupu.
Tak nie jest.
Taśma i tak wymaga dyscypliny. Linux daje pełną swobodę, by sprostać tym wymaganiom znakomicie albo twórczo je zignorować. Różnica nie leży w platformie. Chodzi o to, czy proces pozostanie zrozumiały, gdy jego autor będzie zmęczony, nieobecny lub zajęty usuwaniem rzeczywistej awarii.
Oto punkt odniesienia. Możliwość skryptowania to funkcja. Możliwość odzyskania danych to sedno sprawy.