Bacula.pl

Zadania weryfikacji Bacula

26 grudzień 2019, autor: Marcin Haba (gani)

Podczas codziennej pracy komponenty Bacula przetwarzają wiele danych, zapisując je jako kopie zapasowe na wolumenach, a także zapisując atrybuty plików zarówno na wolumenach jak i w bazie danych. Wszystkie te trzy miejsca: system plików klienta Bacula, wolumen i baza danych są więc powiązane w ten sposób, iż tuż po wykonaniu backupu, zawierają spójne ze sobą dane. W niniejszym artykule spróbuję przedstawić sposoby sprawdzenia zgodności danych i metadanych kopii zapasowych z każdego z tych miejsc, używając do tego zadania weryfikacji.

Zanim jednak przyjrzymy się bliżej poszczególnym poziomom zadań weryfikacji, chciałbym zwrócić najpierw uwagę na to, jakie możliwości w kontekście weryfikowania prezentuje każdy z komponentów Bacula. Pomoże to zrozumieć zasadę działania wszystkich poziomów zadania weryfikacji.

I. Funkcje komponentów Bacula podczas działania zadań weryfikacji

1. Director

Odpowiada za porównywanie przesłanych mu atrybutów plików od File Daemon'a z odpowiednimi atrybutami plików z bazy danych Bacula. Innymi słowy, w zadaniach weryfikacji Director ma zdolność porównywania atrybutów. Ma on także zdolność porównywania sum kontrolnych plików, jednak sam ich nie oblicza, gdyż to zadanie File Daemon'a.

2. File Daemon

Może odczytywać atrybuty plików z systemu plików, a także może odczytywać atrybuty plików przesłanych mu z wolumenów od Storage Daemon'a. Kolejną zdolnością, którą się charakteryzuje, jest możliwość obliczania sum kontrolnych. Obliczanie sum ma miejsce w przypadku zadania weryfikacji poziomu Data. Po odczytaniu atrybutów pliku ma możliwość przesyłania ich do Director'a. Sam w sobie posiada też zdolność porównywania rozmiaru i sum kontrolnych przesłanych mu od Director'a dla zadania weryfikacji poziomu Data z załączoną opcją accurate.

3. Storage Daemon

Może odczytywać z wolumenów dane backupów i przesyłać je do File Daemon'a w celu analizy i weryfikacji. Ma to miejsce dla zadań weryfikacji o poziomach Data i VolumeToCatalog.

II. Słowniczek pojęć

1. Atrybuty plików

Pod tym terminem kryją się następujące właściwości plików: numer i-węzła, uprawnienia, liczba dowiązań twardych, identyfikator użytkownika będącego właścicielem pliku, grupa przypisana do pliku, rozmiar pliku, czas dostępu do pliku (ATIME), czas modyfikacji pliku (MTIME), czas zmiany pliku (CTIME).

2. Metadane backupu

Są to atrybuty plików i ich sumy kontrolne zapisane na wolumenie Bacula razem z danymi backupu.

3. Dane backupu

Są to zapisane pliki w kopii zapasowej (bez metadanych).

III. Poziomy zadań weryfikacji

1. VolumeToCatalog - weryfikacja zgodności atrybutów plików zapisanych na wolumenie i atrybutów plików w bazie danych

Poziom ten weryfikuje zapisane na wolumenie atrybuty plików i sumy kontrolne z atrybutami plików i sumami kontrolnymi zapisanymi w bazie danych Bacula. Nie weryfikuje on jednak samych danych backupu (jedynie atrybuty i sumy). Przyda się więc do sprawdzenia, czy metadane plików na wolumenach odpowiadają tym w bazie danych Bacula.

2. Data - weryfikacja zgodności danych na wolumenie i opcjonalna weryfikacja rozmiaru pliku i sumy kontrolnej z wolumenu z tymi z bazy danych Bacula

Cała praca weryfikacyjna spoczywa tu nie po stronie Directora, a po stronie File Daemon'a. To on otrzymuje "surowe" dane z wolumenu od Storage Daemon'a, w których znajdują się i dane backupu i sumy kontrolne plików, a także ich atrybuty. Z danych backupu oblicza rozmiary i sumy kontrolne plików i porównuje je z rozmiarami i sumami, które pochodzą z metadanych backupu na wolumenie. Zadanie weryfikacji poziomu Data to dobry sposób na sprawdzenie, czy dane na wolumenach są w nienaruszonym stanie, czy nie zostały w jakiś sposób uszkodzone np. przez błędy na nośniku danych wolumenów (dysk, taśma). Podczas tego zadania weryfikacji oprócz rozmiaru i sumy kontrolnej, nie są sprawdzanie żadne dodatkowe wartości danych backupu.

Zadanie weryfikacji poziomu Data używa dyrektywy Verify z opcji zasobu FileSet, np:

FileSet {
 Name = "Moj Backup FileSet"
 Include {
  Options {
   Signature = SHA1
   Verify = s1
  }
  File = "/home/gani"
 }
}

Wspierane do tej pory wartości to s (sprawdzanie rozmiaru), 5 (sprawdzanie sumy kontrolnej MD5), 1 (sprawdzanie sumy kontrolnej SHA1). Jeżeli opcja s nie jest określona, to File Daemon nie będzie obliczał ani porównywał rozmiaru pliku z danych backupu. Jeżeli ani opcja 1 ani 5 nie jest określona, to File Daemon nie będzie obliczał ani porównywał sumy kontrolnej z danych backupu.

Jeżeli zadanie weryfikacji zostanie uruchomione z opcją accurate, to porównane zostaną również sumy kontrolne i rozmiary plików z metadanych backupu na wolumenie z sumami kontrolnymi i rozmiarami z bazy danych przesłanymi przez Director'a. Całe porównanie odbywa się po stronie File Daemon'a.

3. DiskToCatalog - weryfikacja zgodności atrybutów plików w systemie plików File Daemon'a z atrybutami plików w bazie danych

Celem tego poziomu weryfikacji jest porównanie atrybutów plików z systemu plików po stronie File Daemon'a z atrybutami plików backupu zapisanymi w bazie danych Bacula. Dzięki temu typowi weryfikacji można określić czy od czasu ostatniego backupu atrybuty plików uległy zmianie czy też nie, a jeśli tak, to jak bardzo. Możliwe do ustawienia kryteria porównywania atrybutów plików w dyrektywie Verify w opcjach zasobu FileSet to:

• i - porównywanie numeru i-węzła
• p - porównywanie uprawnień pliku
• n - porównanie ilości dowiązań twardych
• u - porównanie identyfikatora użytkownika (właściciela pliku)
• g - porównanie identyfikatora grupy przypisanej do pliku
• s - porównanie rozmiaru pliku
• a - porównanie czasu dostępu (ATIME)
• m - porównanie czasu modyfikacji (MTIME)
• c - porównanie czasu zmiany (CTIME)
• d - zgłoś zmniejszenie rozmiaru pliku
• 5 - porównanie sumy kontrolnej MD5
• 1 - porównanie sumy kontrolnej SHA1

Przykładowa konfiguracja porównywania uprawnień pliku, numeru i-węzła, ilości dowiązań twardych i sumy kontrolnej MD5:

FileSet {
 Name = "Moj Backup FileSet"
 Include {
  Options {
   Signature = MD5
   Verify = pins5
  }
  File = "/home/gani"
 }
}

4. InitCatalog - utworzenie stanu bazowego atrybutów plików do porównania z zadaniem weryfikacji poziomu Catalog

Dzięki poziomowi InitCatalog można odczytać stan atrybutów plików z systemu plików File Daemon'a i zapisać go w bazie danych. Posłuży on jako baza do określenia tego, czy coś się zmieniło w systemie plików czy też nie. Zadania poziomu InitCatalog i Catalog tworzą swego rodzaju osobną parę zadań weryfikacji i same w sobie nie weryfikują ani atrybutów plików backupu ani samych danych backupu. W zamian za to są dobrym narzędziem do zrobienia czegoś na kształt migawki z katalogów systemu plików i monitorowania czy coś się w nich zmieniło od czasu ostatniego zadania poziomu InitCatalog.

5. Catalog - weryfikacja atrybutów plików od czasu wykonania zadania poziomu InitCatalog

Ten poziom weryfikacji można określić jako skanowanie systemu plików w poszukiwaniu określonych zmian. W zdefiniowaniu kryterium określającego, czy zmiana zaszła czy nie, do dyspozycji mamy kilka różnych atrybutów określanych w zasobie FileSet, takich jak:

• i - porównywanie numeru i-węzła
• p - porównywanie uprawnień pliku
• n - porównanie ilości dowiązań twardych
• u - porównanie identyfikatora użytkownika (właściciela pliku)
• g - porównanie identyfikatora grupy przypisanej do pliku
• s - porównanie rozmiaru pliku
• a - porównanie czasu dostępu (ATIME)
• m - porównanie czasu modyfikacji (MTIME)
• c - porównanie czasu zmiany (CTIME)
• d - zgłoś zmniejszenie rozmiaru pliku
• 5 - porównanie sumy kontrolnej MD5
• 1 - porównanie sumy kontrolnej SHA1

Przed uruchomieniem zadania poziomu Catalog, powinno wykonać się co najmniej jedno zadanie poziomu InitCatalog.

IV. Wspólne opcje weryfikacji

1. Wybranie zadania do weryfikacji poprzez jego nazwę

W celu określenia tego, jaki konkretnie backup chce się weryfikować, można użyć parametru komendy bconsole run o nazwie verifyjob=nazwa_zadania, np.:

run job="Moje zadanie weryfikacji" verifyjob="Backup123"

W tym wywołaniu zostanie wzięty pod uwagę ostatni backup zadania o nazwie "Backup123".

Wartość VerifyJob można też określić w dyrektywie zasobu Job, który służy do weryfikacji, np.:

Job {
 Name = "Moje zadanie weryfikacji"
 Type = "Verify"
 Level = "VolumeToCatalog"
 ......
 VerifyJob = "Backup123"
}

Dzięki temu nie trzeba go podawać za każdym razem przy ręcznym uruchomieniu zadania i takie zadanie może zostać użyte w harmonogramie zadań Bacula.

Dyrektywa i parametr VerifyJob mogą być używane przez zadania weryfikacji o poziomach DiskToCatalog, VolumeToCatalog i Data.

2. Wybranie zadania do weryfikacji poprzez jego identyfikator

Drugim sposobem na określenie tego, jaki backup chce się weryfikować jest użycie parametru komendy run o nazwie jobid=identyfikator_zadania. Można go użyć w następujący sposób:

run job="Moje zadanie weryfikacji" jobid=1234

W tym przykładzie zweryfikowane będą dane zadania o identyfikatorze 1234.

Parametr jobid może być używany przez zadania weryfikacji o poziomach DiskToCatalog, VolumeToCatalog i Data.

V. Podsumowanie

Jak można zauważyć po przeczytaniu niniejszego artykułu, każdy poziom weryfikacji służy do innego celu i weryfikuje inne wartości, także używając do tego różnych komponentów Bacula. Zachęcam do poczynienia własnych prób z zadaniami weryfikacji, a także do zautomatyzowania procesu weryfikowania.