Bacula.pl

Jesienne porządki w magazynie wolumenów plikowych

20 listopad 2012, autor: Marcin Haba (gani)

Wstęp

Proces automatyzacji wykonywania kopii zapasowych zazwyczaj przynosi najwięcej satysfakcji, gdy jest już po etapie wdrożenia. Wtedy to można rozsiąść się w fotelu i z przyjemnością oglądać, jak wyzwalane poprzez harmonogramy wykonują się kolejne kopie zapasowe, najstarsze taśmy samoczynnie poddają się recyklingowi woluminów, urządzenia backupowe sprawnie zmieniają kolejne wolumeny na potrzeby wykonywanych zadań i wszystko to działa jak w przysłowiowym szwajcarskim zegarku.

Ten sielankowy opis z życia administratora kopii zapasowych zapewne pozostałby klasycznym opisem zadowolonego administratora, gdyby nie życiowe figle, które to weryfikują utopijne marzenie o całkowicie zautomatyzowanym cyklu backupowym. Jednym z takich figli może być przypuszczalnie znany większości czytelników komunikat:

No space left on device

Dziś chciałbym poruszyć temat zagospodarowania przestrzeni dyskowej na woluminy plikowe Bacula poprzez cyklicznie przycinanie poddawanych recyklingowi woluminów plikowych.

O co ta cała heca?

W procesie recyklingu realizowanym przez Bacula woluminy przechodzą przez cztery podstawowe etapy, podczas których stan woluminów zmienia się następująco:

Na początku wolumin posiada stan Append. Następnie po zapełnieniu woluminu lub spełnieniu któregoś z limitów nałożonych na wolumin, wolumin przechodzi w stan Full lub Used. Kolejny etap to czekanie, aż czas retencji dla woluminu zakończy się i będzie możliwe wyczyszczenie rekordów plików z bazy danych i tym samym przejście w stan Purged. Po przejściu w stan Purged dane rekordów plików i zadań zostają wyczyszczone z bazy danych Bacula. Następnie przygotowane do nadpisania od początku woluminy “leżakują” do czasu, aż któreś z zadań poprosi o nie i nadpisze ich zawartość od nowa.

Wspomniany tu proces “leżakowania” jest etapem, podczas którego w bazie danych Bacula nie ma już rekordów plików i zadań, a rzeczywiste dane backupów nadal znajdują się na woluminach. Dzieje się tak za sprawą tego, że Bacula ze swego założenia stara się utrzymać dane na woluminach tak długo jak to tylko możliwe. Może zajść sytuacja, że wolumen zostanie oznaczony stanem Purged przez pomyłkę administratora lub przez niedopasowany odpowiednio czas retencji woluminów. W takiej sytuacji nawet gdy wolumen zostanie już oznaczony stanem Purged to będzie możliwy on do przywrócenia z powrotem do bazy danych Bacula np. poprzez użycie narzędzia bscan. Innym sposobem na uratowanie danych wolumena oznaczonego statusem Purged może być wypakowanie zawartości wolumena (lub jego części) przy pomocy narzędzia bextract.

W tym artykule zakładam, że nie została popełniona żadna pomyłka związana z przedwczesnym od spodziewanego oznaczeniem wolumena stanem Purged. Wracając do wspomnianego etapu “leżakowania” woluminów, czyli - powtarzając - czasu gdy nie ma już rekordów plików i zadań dla wolumena w bazie danych, wolumen jest oznaczony stanem Purged i oczekuje na nadpisanie od nowa, to podczas oczekiwania na nadpisanie wolumen plikowy nadal zajmuje przestrzeń dyskową. Co więcej, będzie ją zajmował tak długo, aż nie zostanie napisany od nowa przez jakiś backup. Nadpisanie to może nastąpić w optymistycznym wariancie np. zaraz po przejściu wolumena w stan Purged. W wariancie bardziej realistycznym wolumen ten przez pewien przedział czasu będzie oczekiwał na nadpisanie . Jeśli wolumen plikowy zajmuje mało miejsca dyskowego, to w zajętości całkowitej przestrzeni dyskowej magazynu urządzenia plikowego nie zostanie zbyt odczuwalnie zauważony. Jeśli jednak nazbierało się w nim kilka, kilkanaście lub kilkadziesiąt gigabajtów danych, to będzie to można odczuć na zajętości magazynu urządzenia. Jeśli takich wolumenów nazbiera się kilka, to narzut może liczyć np. kilkaset gigabajtów. W wielu przypadkach znacznie milej byłoby, gdyby wolumen został przycięty zaraz po przejściu w stan Purged. Wtedy to oczekiwałby on na nadpisanie nie zajmując niemal żadnej przestrzeni dyskowej (nie wliczając rozmiaru etykiety woluminu zapisanej w jego pliku). Do tego celu może posłużyć dyrektywa zasobu Pool o nazwie Action On Purge.

Action On Purge

Istnieje możliwość zdefiniowania w pliku konfiguracyjnym zarządcy Bacula (ang. Director) puli wolumenów, dla której przy przechodzeniu jej wolumenów w stan Purged będzie możliwe przycięcie woluminów tak, aby powróciły do rozmiaru, jaki posiadały tuż po zaetykietowaniu a przed pierwszym użyciem. W tym celu potrzeba dodać do zasobu puli wolumenów dyrektywę Bacula o nazwie Action On Purge w następujący sposób:

Pool {
    Name = "Jakas Pula"
    ...
    Action On Purge = Truncate
}

(trzy kropki w listingu oznaczają, że jest to wycinek konfiguracji)

Przypisanie dyrektywie Action On Purge wartości Truncate daje możliwość przycięcia wolumenów z takiej puli jeszcze przed faktycznym nadpisaniem ich przez nowe backupy. Nie działa to jednak automatycznie i samo zdefiniowanie Action On Purge dla puli urządzenia plikowego nie spowoduje przycięcia wolumena po przejściu w stan Purged. W tym celu w tekstowej konsoli Bacula potrzeba wydać następującą komendę:

purge volume action=Truncate pool="Jakas Pula" storage="Jakies Urzadzenie Plikowe"

Po wykonaniu tej komendy wszystkie woluminy ze statusem Purged z puli woluminów o nazwie "Jakas Pula" i które są obsługiwane przez urządzenie o nazwie "Jakies Urzadzenie Plikowe" zostaną przycięte.

Automatyzacja przycinania woluminów

Gdy opanuje się już przycinanie plikowych woluminów Bacula przy użyciu dyrektywy Action On Purge można pokusić się o zautomatyzowanie operacji przycinania. Z pomocą w automatyzacji przychodzi zadanie administracyjne Bacula wpięte w harmonogram zadań, co przedstawia poniższy listing:

Schedule {
    Name = "Przyciananie Wolumenow"
    Run = sun at 18:00
}

Job {
    Name = "Przytnij"
    Type = Admin
    Schedule = "Przyciananie Wolumenow"
    ...
    RunScript {
        RunsWhen=After
        RunsOnClient=No
        Console = "purge volume action=Truncate allpools storage=JakisStorage"
    }
}

(trzy kropki w listingu oznaczają, że jest to wycinek konfiguracji)

Takie zadanie administracyjne można uruchamiać np. po każdym cyklu wykonanych backupów. W powyższym przykładzie w komendzie przycinającej wolumeny zostało użyte słowo kluczowe allpools, co w tym wypadku dotyczy woluminów wszystkich puli pod warunkiem, że są one obsługiwane przez urządzenie o nazwie "JakisStorage".

Zamiast zadania administracyjnego Baculi można użyć zadanie backupu, które po zakończeniu zapisywania danych backupu wywoła komendę przycięcia wolumenów. Bardziej eleganckie jednak wydaje się użycie zadania administracyjnego.

Podsumowanie

Nabranie wprawy w używaniu przycinania wolumenów może zaoszczędzić znaczną ilość miejsca. Myślę również, że warto używać dyrektywy Action On Purge rozważnie, pamiętając przede wszystkim o tym, że to nie czynnik miejsca w magazynie danych powinien wyznaczać to, jakie backupy przechowuje się i jak długo.