Jak nie dać się zaskoczyć przez automatyczne czyszczenie rekordów plików i zadań
2 wrzesień 2012, autor: Marcin Haba (gani)
Jeśli któregoś dnia zauważyłeś, że zaczynają znikać rekordy Twoich backupów, to jest bardzo prawdopodobne, że albo zjadła je tajemnicza wróżka backupuszka lub zadziałało automatyczne czyszczenie rekordów z bazy danych. O wróżce backupuszce nic mi bliżej nie wiadomo, lecz na temat czyszczenia rekordów plików i zadań możesz przeczytać w niniejszym artykule.
Wstęp
Dziś przedstawię temat trzech dyrektyw z konfiguracji Bacula, których nieznajomość (lub nieświadomość działania) może wprowadzić nowych użytkowników Bacula w zakłopotanie. Mam tu na myśli dyrektywy: File Retention, Job Retention oraz AutoPrune. Pomysł na napisanie artykułu o tych dyrektywach zrodził się na forum tegoż serwisu w niedawnych wątkach:
Nie przeciągając wstępu przechodzę do treści właściwej artykułu, w której spróbuję wyjaśnić, o jakie zakłopotanie chodzi, jak jemu przeciwdziałać oraz po co to całe zamieszanie :)
Dyrektywy widmo
Podczas konfiguracji serwisu klienta Bacula konieczne jest odpowiednie przygotowanie pliku konfiguracyjnego serwisu klienta oraz dodanie odpowiedniej sekcji Client w pliku konfiguracyjnym serwisu zarządcy (Director). Zakładając, że mam już skonfigurowanego klienta od strony jego serwisu, wpis sekcji Client w pliku bacula-dir.conf może wyglądać jak poniżej:
Client {
Name = star-fd
Address = 10.0.0.2
FD Port = 9102
Catalog = MyCatalog
Password = "tsevfmd5AoM7p+yxHme+n+Fi8iViugvF5eqEXS/PzfDm"
Maximum Concurrent Jobs = 1
}
Niby nic nadzwyczajnego, ot standardowa procedura dodawania klienta do konfiguracji serwisu Director. Niemniej jednak, po uruchomieniu backupów z tak skonfigurowanego klienta zostanie zapisana w bazie danych informacja o czasie zachowania rekordów plików i zadań w bazie danych dotyczących tego klienta. Mógłbym teraz spytać:
"Jakie czasy zachowania danych?"
czy też stwierdzić:
"Ja tych opcji nie konfigurowałem!".
Otóż, prawdą jest, że KAŻDY zdefiniowany klient Bacula posiada swoje czasy zachowania rekordów plików i backupów w bazie danych. Nie ma możliwości na ich wyłączenie. Co więcej, nie trzeba tych opcji konfigurować do działania, aby one działały. I co jeszcze więcej, rekordy w bazie danych dla plików i backupów będą w wymienionej tu konfiguracji czyszczone po upłynięciu czasu zachowania danych bez naszej interakcji z Bacula. Po każdym wykonanym zadaniu (np. backupie) będą sprawdzane rekordy dla plików i zadań, a gdy któreś z nich znajdują się w bazie danych dłużej niż ich czas zachowania danych, to zostaną one wyczyszczone z bazy danych.
Takie zachowanie Bacula dzieje się za sprawą dyrektyw zasobu Client w pliku konfiguracyjnym Director:
File Retention = okres_czasu
Job Retention = okres_czasu
AutoPrune = yes/no
Domyślne wartości tych dyrektyw, które obowiązują nawet wtedy, gdy nie są zdefiniowane są następujące:
File Retention = 60 days
Job Retention = 180 days
AutoPrune = yes
Oznacza to, że w przypadku wymienionej wyżej konfiguracji klienta wszystkie trzy dyrektywy będą działać, i po każdym backupie zostaną sprawdzone czasy zachowania danych dla plików i zadań.
Podsumowując, powyższa konfiguracja klienta star-fd jest równoważna z taką, w której dopisałbym domyślne wartości dyrektyw File Retention, Job Retention i AutoPrune:
Client {
Name = star-fd
Address = 10.0.0.2
FD Port = 9102
Catalog = MyCatalog
Password = "tsevfmd5AoM7p+yxHme+n+Fi8iViugvF5eqEXS/PzfDm"
Maximum Concurrent Jobs = 1
File Retention = 60 days
Job Retention = 180 days
AutoPrune = yes
}
Efekt działania będzie taki sam dla braku definicji wytłuszczonych tutaj dyrektyw jak i w przypadku ich podania z domyślnymi wartościami.
Mianowicie, po upływie 60 dni od wykonania pierwszego backupu z klienta star-fd przy kolejnym backupie zostaną wyczyszczone rekordy plików dla pierwszego backupu. W listingu zadań np. przy użyciu komendy list jobs nic się nie zmieni, gdyż rekordy zadań będą jeszcze obecne.
Po upływie 180 dni od czasu wykonania pierwszego backupu z klienta star-fd da się zauważyć, że pierwszy backup zniknie z listingu po wykonaniu komendy list jobs.
W ten sposób po upływie czasu zachowania danych (czy to dla plików czy dla zadań) po każdym wykonaniu backupu coś zacznie znikać z bazy danych. Dla jasności powiem, że NIE oznacza to, że dane czyszczonych rekordów zadań w bazie danych zaczną znikać również z woluminów. Dane będą nadal bezpiecznie spoczywać na woluminach. Operacja wywołana automatycznym czyszczeniem rekordów w bazie danych ma zastosowanie wyłącznie dla samych wpisów w bazie danych i nie odnoszą się do plików zapisanych na woluminach.
Czy jest mi potrzebne czyszczenie rekordów plików i zadań?
Rozmiar bazy danych Bacula może nawet podczas jednego backupu zwiększyć swoją objętość o np. połowę. Dzieje się tak za sprawą tego, że każdy zapisany na wolumenie plik ma odpowiadający mu rekord zapisany w bazie danych Bacula. Z tego też powodu rekordy plików w bazie Bacula stanowią ok. 95% zajętości całej bazy danych. Dyrektywa czyszczenia rekordów plików i zadań na pewno pomoże zwiększyć kontrolę nad rozmiarem bazy danych. Czyszczenie rekordów dla przestarzałych plików i zadań może też być wykonywane prewencyjnie w ramach "pielęgnacji" rozmiaru bazy danych tak, aby któregoś pięknego słonecznego poniedziałku nie okazało się, że zabrakło miejsca na bazę danych.
Osobiście nie jestem zwolennikiem stosowania czyszczenia rekordów w bazie danych dla plików, gdyż uniemożliwia to odtwarzanie pojedynczych plików. Co do czyszczenia rekordów zadań, to w mojej opinii lepszym do tego celu nadaje się recykling woluminów. Inna sprawa, że po wyczyszczeniu rekordów dla plików i zadań jednym ze sposobów na przywrócenie pierwotnego stanu bazy danych może być przeskanowanie woluminów przy użyciu narzędzia bscan. Jest to jednak mocno czasochłonne zadanie i traktowałbym go jako swego rodzaju mniej eleganckie obejście problemu.
Jak wyłączyć automatyczne czyszczenie rekordów plików i zadań?
Wspomniana w niniejszym artykule została dyrektywa AutoPrune. Jeśli nie została ona podana w konfiguracji zasobu Client lub jeśli została załączona poprzez:
Client {
Name = "star-fd"
[ciach]
AutoPrune = yes
}
to po upływie czasów zachowania danych rekordy plików i zadań będą systematycznie znikać z bazy wraz z nowo uruchomionymi zadaniami. Aby wyłączyć takie zachowanie Bacula, potrzeba wyłączyć dyrektywę AutoPrune poprzez przypisanie jej wartości no:
Client {
Name = "star-fd"
[ciach]
AutoPrune = no
}
Jak rozpoznać, czy działa u mnie czyszczenie rekordów plików i zadań?
W celu rozpoznania czyszczenia rekordów plików i zadań warto spojrzeć do dzienników Baculi czyli tzw. logów z zadań. Oto przykładowy listing z podsumowania zadania backupu, w którym po jego zakończeniu zostały wyczyszczone rekordy czterech zadań:
02-Sep 16:18 gani-desktop-dir JobId 45: Bacula gani-desktop-dir
5.2.5 (26Jan12):
Build OS: x86_64-pc-linux-gnu ubuntu 12.04
JobId: 45
Job: BackupClient1.2012-09-02_16.17.46_04
Backup Level: Full
Client: "gani-desktop-fd" 5.2.5 (26Jan12)
x86_64-pc-linux-gnu,ubuntu,12.04
FileSet: "Full Set" 2011-01-06 16:30:00
Pool: "Test Pool" (From Job resource)
Catalog: "MyCatalog" (From Client resource)
Storage: "File" (From Job resource)
Scheduled time: 02-Sep-2012 16:17:44
Start time: 02-Sep-2012 16:17:53
End time: 02-Sep-2012 16:18:57
Elapsed time: 1 min 4 secs
Priority: 10
FD Files Written: 597
SD Files Written: 597
FD Bytes Written: 53,382,775 (53.38 MB)
SD Bytes Written: 53,450,832 (53.45 MB)
Rate: 834.1 KB/s
Software Compression: None
VSS: no
Encryption: no
Accurate: no
Volume name(s): plik
Volume Session Id: 1
Volume Session Time: 1346595060
Last Volume Bytes: 53,510,498 (53.51 MB)
Non-fatal FD errors: 3
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK -- with warnings
02-Sep 16:18 gani-desktop-dir JobId 45: Begin pruning Jobs older
than 6 months .
02-Sep 16:18 gani-desktop-dir JobId 45: Pruned 4 Jobs for client
gani-desktop-fd from catalog.
02-Sep 16:18 gani-desktop-dir JobId 45: Begin pruning Files.
02-Sep 16:18 gani-desktop-dir JobId 45: No Files found to prune.
02-Sep 16:18 gani-desktop-dir JobId 45: End auto prune.
Szybszym sposobem na sprawdzenie tego, czy automatyczne prune (AutoPrune) rekordów plików i zadań jest włączone jest wydanie komendy:
show client=nazwa_klienta
Np.:
show client=gani-desktop-fd
Client: name=gani-desktop-fd address=10.0.0.3 FDport=9102 MaxJobs=1
JobRetention=6 months FileRetention=2 months AutoPrune=0
--> Catalog: name=MyCatalog address=*None* DBport=0 db_name=bacula
db_driver=*None* db_user=bacula MutliDBConn=0
W tym przypadku AutoPrune jest wyłączone (wytłuszczona wartość ustawiona jest na zero).
Manualne czyszczenie rekordów w bazie danych Bacula
Automatyzacja automatyzacją, można ją załączać i wyłączać, lecz może zajść potrzeba wyczyszczenia rekordów plików i zadań na tzw. żądanie. Można tego dokonać poprzez wykonanie komendy prune files (dla plików) lub prune jobs (dla zadań):
Poniżej przykłady użycia komendy prune dla plików i zadań:
* prune files
Automatically selected Client: gani-desktop-fd
The current File retention period is: 1 month
Continue? (yes/mod/no): yes
Pruned Files from 35 Jobs for client gani-desktop-fd from catalog.
* prune jobs
Automatically selected Client: gani-desktop-fd
The current Job retention period is: 6 months
Continue? (yes/mod/no): yes
Pruned 34 Jobs for client gani-desktop-fd from catalog.
Zaznaczam jednak, że dyrektywa prune respektuje czasy zachowania danych (retention time) więc zostaną wyczyszczone jedynie te rekordy plików i zadań, których czas retention minął.
Podsumowanie
Opisane dyrektywy czasu zachowania danych oraz automatyzacja ich egzekwowania mogą przynieść korzyści, jeśli używa się je znając dobrze ich zastosowanie i konsekwencje. Myślę, że lepiej poznać ich działanie i sposoby konfiguracji, niż obudzić się z przysłowiowym "palcem w nocniku" zastanawiając się nad tym, czemu znikają zadania z bazy danych.