Loading

NewsyRSS - Newsy

news Bacula 9.0 - coraz bliżej
10 czerwiec 2017

Wielkimi krokami zbliża się nowe wydanie Bacula oznaczone numerem 9.0.

news Bacula 7.4.0 - nowe wydanie
24 styczeń 2016

Nowa wersja Bacula 7.4.0

news Bacula 7.2.0 - nowe wydanie
14 sierpień 2015

Dziś została wydana wersja Bacula 7.2.0

Bacula 9.0.8

Bacula.pl poleca

Open-E Data Storage Solutions

Jesteśmy na Facebooku

Znajdziesz nas w Google+

drukuj artykuł wersja PDF poleć artykuł znajomym

Jak nie dać się zaskoczyć przez automatyczne czyszczenie rekordów plików i zadań

2 wrzesień 2012, autor: Marcin Haba (gani),

news

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.


Bacula w internecie

O nas

Bacula.pl jest niekomercyjnym serwisem poświęconym tematyce oprogramowania Bacula. Ideą witryny jest prezentacja funkcjonalności Bacula.

Ta strona używa plików cookies (niezbędnych do prawidłowego działania). (więcej informacji)