Podstawowa instalacja i konfiguracja oprogramowania Bacula
2 październik 2010, autor: Marcin Haba (gani)
Artykuł zawiera przykład podstawowej konfiguracji Bacula. Kierowany jest głównie do osób początkujących i zaczynających swą przygodę z Bacula, lecz mam nadzieję, że również ci, którzy poznali już trochę Bacula również znajdą tu coś dla siebie. Można powiedzieć, że tekst jest swego rodzaju przewodnikiem na temat instalacji i konfiguracji serwisów Bacula rozmieszczonych w obrębie 5 komputerów.
Pierwsze spojrzenie na Bacula
W zestawie programów Bacula można wyróżnić trzy najważniejsze komponenty:
- klient
- demon magazynowania
- zarządca
Programy te współpracują ze sobą komunikując się za pośrednictwem protokołów TCP. Zasada działania opiera się o metodykę klient-serwer.
Do przechowywania metadanych plików kopii zapasowych Bacula wykorzystuje zewnętrzny serwer bazodanowy. Składowane są w nim również szczegółowe informacje m.in. o parametrach kopii zapasowych, woluminach, klientach.
W kwestii interfejsu administracyjnego użytkownik może wybrać pomiędzy tekstową konsolą lub którymś z zarządzających programów graficznych.
Komponenty Bacula
Przed przystąpieniem do instalacji Baculi, niezbędne okaże się zrozumienie przeznaczenia poszczególnych jej programów jak i ich wzajemnej zależności. Dlatego też pokuszę się o przedstawienie kilku ogólnych definicji.
Klient - instalowany jest na komputerach klientów. W zakres jego możliwości wchodzą wszelkiego typu operacje na plikach jak choćby zebranie i dostarczenie danych do demona magazynowania podczas backupu czy też odebranie i zapisanie danych na komputerze klienta w operacji przywracania danych. Otrzymuje on konkretne rozkazy od serwisu zarządcy i na tej podstawie podejmuje akcje. Plik konfiguracyjny tego serwisu nazywa się bacula-fd.conf, a plik binarny to bacula-fd.
Demon magazynowania – demon odpowiedzialny za wykonywanie operacji na woluminach urządzeń archiwizujących. Dlatego też pracuje on na komputerze przeznaczonym do składowania kopii zapasowych. Jest to jedyny serwis Baculi, który ma dostęp do urządzeń archiwizujących. Za jego pośrednictwem możliwy jest odczyt i zapis danych kopii zapasowych. Konfiguracja demona magazynowania znajduje się w pliku bacula-sd.conf. Plik tego programu nazywa się bacula-sd.
Zarządca – jak może sugerować nazwa, jest to usługa nadzorująca pracę pozostałych serwisów. Do zarządcy trafiają wszystkie komendy użytkownika, na podstawie których steruje on pracą pozostałych serwisów Baculi. Sprawuje on pieczę nad takimi funkcjami jak np: harmonogramy zadań, raportowanie, statusy usług, odczyt i zapis informacji w bazie danych.
Zależności komponentów
Poniższy rysunek przedstawia schemat przepływu informacji pomiędzy serwisami Bacula podczas wykonywania backupu.
Rysunek 1: Schemat przepływu informacji pomiędzy serwisami Bacula podczas backupu.
Sposoby instalacji
Użytkownik ma do wyboru dwa rodzaje instalacji:
- z pakietów binarnych – w repozytoriach wielu dystrybucji systemu GNU można znaleźć pakiety z programami Bacula. Jeśli jest się posiadaczem takiego systemu, droga instalacji przy pomocy managera pakietów wydaje się łatwa. Manager pakietów daje kontrolę nad zainstalowanymi pakietami i często pozwala śledzić dostępne aktualizacje.
- kompilacja ze źródeł – kod źródłowy programów Bacula można pobrać z oficjalnego projektu Bacula w serwisie SourceForge.net. Najogólniej mówiąc, ten typ instalacji pozwala na dopasowanie programów Bacula do własnych potrzeb poprzez konfigurację źródeł z odpowiednimi przełącznikami.
W niniejszym artykule spróbuję opisać instalację Bacula ze źródeł. Opis instalacji z pakietów binarnych wybranych systemów operacyjnych byłby problematyczny z faktu różnorodności tychże systemów jak i różnic w nazewnictwie pakietów.
Założenia instalacyjne
Przedstawiony poniżej opis instalacji zakłada następującą konfigurację sprzętową (5 komputerów):
- Serwis zarządcy instalowany na komputerze o nazwie "darkstar" z systemem operacyjnym GNU/Linux. Na komputerze działa serwer bazodanowy PostgreSQL, który zostanie wykorzystany do pracy z Bacula.
- Demon magazynowania instalowany na komputerze z systemem GNU/Linux. Ma on podłączony napęd taśm magnetycznych typu SLR7 oraz dodatkowy dysk twardy. Obydwa urządzenia będą wykorzystane do archiwizacji danych. Komputer nazywa się "hardstar".
- Klient instalowany na komputerze z systemem Windows XP. Nazwa komputera to "easystar"
- Klient instalowany na komputerze o nazwie "freestar" z systemem GNU/Linux.
- Komputer z dowolnym systemem operacyjnym, na którym możliwa jest praca konsoli Baculi lub graficznego narzędzia administracyjnego.
Powyższą konfigurację przedstawia ilustracja:
Rysunek 2: Założenia instalacyjne
Umieszczenie serwisu zarządcy na komputerze z serwerem baz danych zwiększa wydajność zapisu do bazy danych, ponieważ w tej konfiguracji zarządca nie musi łączyć się z kolejnym komputerem i przesyłać zapytania SQL poprzez sieć. Nie znaczy to jednak, że odseparowanie tych usług na osobnych komputerach jest złym rozwiązaniem. Zaprojektowanie topologii usług powinno być dopasowane do indywidualnych potrzeb i warunków, jakimi dysponuje użytkownik.
Instalacja demona magazynowania
Jako pierwszy zostanie zainstalowany serwis demona magazynowania na komputerze o nazwie "hardstar". W tym celu należy zaopatrzyć się w źródła Bacula. W chwili pisania artykułu najnowszym stabilnym wydaniem Bacula jest wersja 5.0.2 i to właśnie ta wersja zostanie użyta do instalacji. Archiwa ze źródłami można pobrać z oficjalnego projektu Bacula w serwisie SourceForge.net. Projekt znajduje się pod adresem:
http://sourceforge.net/projects/bacula/
Podstawowa konfiguracja źródeł demona magazynowania przedstawia się następująco:
root@hardstar# tar zxf ./bacula-5.0.2.tar.gz
root@hardstar# cd ./bacula-5.0.2
root@hardstar# ./configure --prefix=/usr/local/bacula \
--disable-build-dird \
--with-scriptdir=/usr/local/bacula/scripts \
--with-postgresql=/usr
gdzie przełączniki oznaczają:
--prefix=[katalog] – określa lokalizację, gdzie zainstalowany ma być demon magazynowania. Tutaj przyjęto lokalizację /usr/local/bacula, lecz nic nie stoi na przeszkodzie wskazać inną lokalizację.
--disable-build-dird – wyłącza kompilację zarządcy ponieważ na tym komputerze będzie pracować tylko demon magazynowania.
--with-scriptdir=[katalog] – wskazuje lokalizację, do której trafią skrypty Bacula m.in. do obsługi zmieniarki taśm magnetycznych, do backupu na DVD czy do startowania usług.
--with-postgresql=[katalog] – wskazanie miejsca, gdzie znajdują się pliki nagłówkowe PostgreSQL, które zostaną wykorzystane podczas kompilacji. Jako że na komputerze "hardstar" nie ma zainstalowanego serwera baz danych, potrzeba doinstalować pakiet z plikami nagłówkowymi serwera PostgreSQL lub skompilować serwer baz danych tylko na potrzeby otrzymania plików nagłówkowych.
Jeśli konfiguracja źródeł przebiegła bez błędów, to można przeprowadzić kompilację.
root@hardstar# make
Jeśli kompilacja powiodła się, można przejść do instalacji poprzez komendę:
root@hardstar# make install
Co trzeba wiedzieć przed konfiguracją serwisów
Podczas kompilacji został wygenerowany przykładowy plik konfiguracyjny demona magazynowania. Znajduje się on w lokalizacji:
/usr/local/bacula/etc/bacula-sd.conf
Można w nim podejrzeć składnię używaną w plikach konfiguracyjnych Bacula. Tutaj wspomnę o trzech jej elementach:
- zasób – składa się z typu oraz nazwy
- dyrektywa – pojedyncza opcja konfiguracyjna
- komentarz – tekst poprzedzony znakiem #
Przykład
# To jest komentarz
TypZasobu {
Name = "Nazwa zasobu"
Dyrektywa = "Wartosc 1" # To też jest komentarz
Inna Dyrektywa = Wartosc2
}
Wartości powyższych dyrektyw Name i Dyrektywa opatrzone są znakami cudzysłowia natomiast wartość dyrektywy Inna Dyrektywa występuje bez cudzysłowiów. Do poprawnego parsowania przez Bacula plików konfiguracyjnych wymagane jest, aby wartości zawierające spacje umieszczane były pomiędzy cudzysłowie, natomiast wszystkie inne wartości mogą być w cudzysłowiach lecz nie muszą. W tym artykule przyjąłem konwencję taką, że tylko wartości ze spacją będą opatrzone znakami cudzysłowia, wszystkie inne natomiast pozostaną bez cudzysłowiów. Zazwyczaj wartościami zawierającymi spacje są nazwy własne zasobów nadawane przez użytkownika.
Konfiguracja demona magazynowania
Przystępując do wprowadzenia własnej konfiguracji demona magazynowania można usunąć całą domyślną zawartość pliku konfiguracyjnego bacula-sd.conf na komputerze "hardstar".
Plik konfiguracyjny bacula-sd.conf może zawierać cztery typy zasobów. Są to:
- Storage – główna konfiguracja demona magazynowania,
- Director – dane zarządcy uprawnionego do używania urządzeń demona magazynowania,
- Device – definicja urządzenia archiwizującego,
- Messages – opcje przekazywania logów demona magazynowania do serwisu zarządcy.
W zasobie Storage ustawia się parametry globalne dla całego serwisu magazynowania. Trafiają tu ustawienia charakteryzujące sam serwis i sposób jego działania w systemie operacyjnym. Przykład konfiguracji zasobu Storage:
Storage {
Name = hardstar-sd
Working Directory = /usr/local/bacula/var/bacula/working
PID Directory = /var/run
SD Address = 10.0.0.3
SD Port = 9103
Maximum Concurrent Jobs = 2
}
gdzie użyte dyrektywy oznaczają:
Name – nazwa demona magazynowania. Nie jest ona powiązana z żadną inną konfiguracją usług. Można wpisać dowolną nazwę, lecz dobrze wpisać taką, aby łatwo móc zidentyfikować tego demona magazynowania np. w dzienniku Bacula (przy założeniu, że taką samą nazwę nada się demonowi magazynowania w pliku konfiguracyjnym zarządcy). Tutaj została przyjęta jako nazwa komputera z suffixem "-sd", dzięki czemu będzie wiadomo z jakiego komputera pochodzi komunikat oraz jakiego typu to serwis (sd – Storage Daemon).
Working Directory – katalog, w którym serwis będzie przechowywał pliki swoich statusów. Dobrą praktyką jest zdefiniować taki katalog, który przeznaczony będzie tylko do tego celu.
PID Directory – lokalizacja, w której demon magazynowania będzie zapisywał plik z identyfikatorem procesu, jaki otrzymał demon przy starcie. W powyższej konfiguracji jest to /var/run, ponieważ często w tej lokalizacji systemy "uniksowe" przechowują pliki PID, więc użytkownik nie będzie musiał zapamiętywać dodatkowej lokalizacji.
SD Address – dyrektywa definiuje adres IP interfejsu, na którym będzie nasłuchiwał demon. Jak widać na schemacie z podrozdziału "Założenia instalacyjne" (Rysunek 2) adresem IP komputera "hardstar" jest 10.0.0.3, dlatego taki adres został podany w tej dyrektywie.
SD Port – numer portu, na którym nasłuchiwać będzie demon. Domyślnym portem komunikacyjnym demona magazynowania jest 9103. Można tu podać inny numer portu jeśli taką potrzebę ma użytkownik.
Maximum Concurrent Jobs – liczba zadań, która może być obsługiwana w tym samym czasie przez tego demona. Zasada działania urządzeń archiwizacyjnych z Bacula mówi o tym, że jedno urządzenie może jednocześnie wykonywać jedno zadanie (np. backup). Dokładniej rzecz ujmując chodzi tu o fakt, że jedno urządzenie może mieć w tym samym czasie podmontowany jeden wolumin, nawet jeśli urządzeniem jest dysk. Reguła ta nie dotyczy bibliotek taśmowych (również wirtualnych bibliotek taśmowych), które mogą posiadać po kilka napędów taśmowych i wszystkich ich używać w tym samym czasie. Jednak nawet w tym wypadku liczba napędów mogących wykonywać backup jest skończona. Wartość omawianej dyrektywy można więc oszacować na podstawie możliwości podłączonych i skonfigurowanych urządzeń. W opisywanej konfiguracji podłączone urządzenia to dysk i streamer, więc jednocześnie demon może obsłużyć 2 zadania (jedno na urządzenie dyskowe i jedno na streamer).
Konfigurując dalej demona magazynowania zdefiniuję zasób Director. Jest to wymagany zasób określający zarządcę, który będzie mógł skorzystać z tego demona magazynowania. W tym celu do pliku bacula-sd.conf potrzeba dopisać definicję zasobu Director:
Director {
Name = darkstar-dir
Password = "haslo do demona magazynowania"
}
gdzie użyte dyrektywy oznaczają:
Name – nazwa zarządcy uprawnionego do używania demona magazynowania. O ile nazwa demona magazynowania mogła być dowolna, to nazwa zarządcy określanego w tej dyrektywie musi odpowiadać nazwie zarządcy zdefiniowanej na komputerze "darkstar" w jego pliku konfiguracyjnym. Dzieje się tak ponieważ zarządca łącząc się z demonem magazynowania przedstawia się swoją nazwą, która jest weryfikowana z nazwą podaną w tej dyrektywie.
Password – hasło, którym zarządca będzie autoryzował się do demona magazynowania. Podane tu hasło definiowane jest również w pliku konfiguracyjnym zarządcy.
Trzecim typem zasobu, który zostanie zapisany w pliku konfiguracyjnym demona magazynowania jest zasób Device. Dyrektywy w nim użyte dostarczają dokładnych informacji o urządzeniu archiwizacyjnym oraz o tym, w jaki sposób Bacula będzie to urządzenie używać. Komputer o nazwie "hardstar" posiada podłączone dwa urządzenia, więc będą też dwa zasoby Device: jedno dla urządzenia dyskowego, drugie dla streamera SLR7. W celu skonfigurowania demona magazynowania potrzebne będą dodatkowe informacje o tych urządzeniach. Zakładam więc, że napęd taśm magnetycznych dostępny jest w systemie operacyjnym poprzez plik urządzenia:
/dev/nst0
a punkt montowania dodatkowego dysku zlokalizowany jest w:
/mnt/storage/
Konfiguracja urządzeń zostanie dopisana do pliku bacula-sd.conf.
# Urządzenie dysku
Device {
Name = "Urzadzenie Plikowe"
Archive Device = /mnt/storage
Device Type = File
Media Type = File
Removable Media = no
Random Access = yes
Requires Mount = no
}
# Urządzenie streamer SLR7
Device {
Name = "Naped tasmowy"
Archive Device = /dev/nst0
Device Type = Tape
Media Type = SLR7
Removable Media = yes
Random Access = no
Always Open = yes
}
Użyte dyrektywy oznaczają kolejno:
Name – nazwa urządzenia. Ta sama nazwa jest definiowana również w pliku konfiguracyjnym zarządcy, który będzie posługiwał się nią podczas odwoływania się do demona magazynowania.
Archive Device – lokalizacja urządzenia. Jeśli urządzeniem jest dysk, to podawany jest tutaj punkt jego montowania. Jeśli urządzeniem jest napęd taśm magnetycznych, podawany jest plik urządzenia (tutaj jest to /dev/nst0). W przypadku napędów taśmowych ważne jest, aby podawać plik /dev/nstX zamiast /dev/stX (gdzie X to numer urządzenia). Różnica pomiędzy "st" (SCSI Tape Drive) a "nst" (Non-Rewind SCSI Tape Drive) jest taka, że w przypadku podania tego pierwszego w chwili gdy urządzenie zakończy zadaną operację, demon magazynowania przewinie taśmę na początek. Nst natomiast gwarantuje, że napęd taśmowy nie będzie przewijał taśmy po każdej operacji na nim wykonanej. Podsumowując – w przypadku napędów taśm magnetycznych (również tych z urządzenia autoloadera lub biblioteki taśmowej) podajemy /dev/nstX zamiast /dev/stX.
Device Type – określa typ urządzenia. Możliwe typy urządzeń to:
- File – dla dysków,
- Tape – dla urządzeń taśmowych,
- Fifo – dla kolejek FIFO,
- DVD – dla napędów DVD-ROM.
Podanie tej dyrektywy nie jest konieczne, ponieważ jeżeli nie zostanie ona podana, to Bacula określi typ urządzenia na podstawie jego lokalizacji podanej w dyrektywie Archive Device. Niemniej jednak uważam, że warto to wiedzieć, gdy gdzieś napotka się tą dyrektywę.
Media Type – typ woluminu. Określa jakiego typu nośniki obsługuje dane urządzenie. Nie należy tego rozumować jakoby istniała jakaś skończona lista wspieranych typów nośników. Jest to po prostu ciąg znaków określony przez użytkownika do nazwania typu nośników. W przypadku urządzenia plikowego podałem nazwę "File" lecz równie dobrze mogłem podać nazwę "Pliki", tak jak w przypadku streamera zamiast SLR7 mogłem podać dowolną inną nazwę (np. "tasma"). Typ nośników ma znaczenie dla Bacula, gdyż jednoznacznie identyfikuje, jakie urządzenie może obsługiwać jakiego typu nośniki. Ma to szczególne znaczenie w przypadku napędów taśm, ponieważ możemy posiadać kilka napędów taśmowych, które obsługują ten sam typ nośników, np. taśmy LTO-2. Podczas operacji przywracania danych Bacula może użyć jakikolwiek napęd obsługujący ten typ nośników. Nieco inaczej wygląda to w sytuacji, gdy urządzeniami są dyski. Wtedy powinno się definiować unikalny typ nośnika dla każdego takiego urządzenia. Wynika to z faktu, że każdy dysk posiada inny punkt montowania, a woluminy przechowywane na dyskach nie są "ruchome".
Removable Media – mówi o tym, czy urządzenie obsługuje wymienne nośniki. Dla urządzeń taśmowych, napędów DVD jak i wyjmowalnych dysków (np. dyski zewnętrzne lub pendrive) dyrektywa powinna być ustawiona na "yes". Dla stałych dysków dyrektywa powinna być ustawiona na "no". W sytuacji, gdy zdefiniowane jest, że urządzenie ma możliwość wymiany nośników (Removable Media = yes), a nośnik podczas backupu zostanie zapełniony, to Bacula zgłosi żądanie wymiany nośnika, aby móc kontynuować backup na innej taśmie.
Random Access – mówi Baculi o tym, jakiego typu jest urządzenie pod względem dostępu do niego. Chodzi tu o rozgraniczenie urządzeń o dostępie bezpośrednim (dyski twarde, napędy DVD) od urządzeń o dostępie sekwencyjnym (napędy taśmowe).
Requires Mount – określa, czy przed wykonaniem operacji na urządzeniu potrzeba wykonać dodatkową komendę montowania. Użyty tu dysk jest dyskiem montowanym przy starcie systemu, więc nie ma potrzeby włączenia tej funkcjonalności. Dla dysków wyjmowalnych powinno się włączyć tą dyrektywę oraz określić dodatkowe dyrektywy określające komendę montowania, komendę odmontowania, punkt montowania itp.
Always Open – dyrektywa ta ma znaczenie dla urządzeń taśm magnetycznych. Informuje ona demona magazynowania o tym, czy ma "trzymać" urządzenie cały czas, czy też ma je odmontować, gdy nie korzysta z niego żadne zadanie. W drugim przypadku po wykonaniu każdego zadania Bacula przewija taśmę na początek, a następnie ustawia taśmę na miejscu zakończenia danych i zwalnia urządzenie. Taka operacja jest dość kosztowna dla napędu z faktu, że powoduje szybsze zużycie taśmy (niepotrzebna duża ilość przejść taśmy). Z tego powodu zalecane jest ustawienie dyrektywy na 'yes' dla napędów taśmowych. Dla urządzeń plikowych dyrektywa ta jest ignorowana.
Przedstawiony sposób konfiguracji napędu taśm magnetycznych nie objął w tym przykładzie użycia takiej funkcjonalności jak spooling. Jest to bardzo przydatna opcja dla napędów taśmowych, dzięki której można znacznie przedłużyć trwałość taśmy poprzez dostarczanie do napędu danych stałym strumieniem. Osobiście mocno zalecam użycie spoolingu w przypadku używania napędu taśmowego. Więcej informacji o tym zagadnieniu znajduje się np. w dokumentacji Bacula.
Ostatnim zasobem do skonfigurowania dla demona magazynowania jest zasób Messages. Jego dyrektywy charakteryzują wpisy dzienników, jakie będą raportowane do serwisu zarządcy.
Messages {
Name = hardstar-sd-messages
Director = darkstar-dir = all
}
Użyte dyrektywy oznaczają kolejno:
Name – nazwa zasobu. Używana jest na wewnętrzne potrzeby demona i nie zostaje przekazana nigdzie na zewnątrz.
Director – widać tu nieco nietypową składnię dyrektywy (dwa znaki równości). Określa się tu dwie wartości: nazwę zarządcy do którego dyrektywa się tyczy oraz poziom logowania. Wartość 'all' oznacza, że raportowane będą wszystkie zmiany i statusy podczas pracy demona magazynowania. Zainteresowanych manipulacją poziomami logowania zachęcam do odwiedzenia dokumentacji Bacula.
Uruchomienie demona magazynowania
Wystartowanie demona sprowadza się do wywołania jednej komendy. Oto jej składnia:
/lokalizacja/plik_binarny_demona -v -c /lokalizacja/plik_konfiguracyjny_demona.conf
gdzie przełącznik -v uaktywnia tryb "gadatliwy" a w przełączniku -c potrzeba podać lokalizację pliku konfiguracyjnego usługi.
W bardzo podobny sposób uruchamia się pozostałe serwisy (zarządcy i klienta), warto więc zapamiętać tą komendę.
Opisana powyżej instalacja umiejscowiła demona w lokalizacji /usr/local/bacula. Komenda startowa przedstawia się więc następująco:
root@hardstar# /usr/local/bacula/sbin/bacula-sd -v -c /usr/local/bacula/etc/bacula-sd.conf
Pozostaje jeszcze sprawdzić, czy w systemie pojawił się proces bacula-sd:
root@hardstar# ps ax | grep bacula-sd
27439 ? Ssl 0:00 /usr/local/bacula/sbin/bacula-sd -v -c /usr/local/bacula/etc/bacula-sd.conf
oraz czy serwis nasłuchuje na odpowiednim interfejsie sieciowym:
root@hardstar# netstat -atn | grep '10.0.0.3'
tcp 0 0 10.0.0.3:9103 0.0.0.0:* LISTEN
Instalacja klienta w systemie GNU/Linux
Instalacja klienta na komputerze o nazwie "freestar" może przedstawiać się następująco:
root@freestar# tar zxf ./bacula-5.0.2.tar.gz
root@freestar# cd ./bacula-5.0.2
root@freestar# ./configure --prefix=/usr/local/bacula \
--disable-build-dird \
--disable-build-stored \
--enable-client-only \
--with-scriptdir=/usr/local/bacula/scripts
Użyte przełączniki oznaczają:
--prefix=[katalog] – określa lokalizację, gdzie zainstalowany ma być klient.
--disable-build-dird – wyłącza kompilację zarządcy ponieważ na tym komputerze będzie pracować tylko klient.
--disable-build-stored – wyłącza kompilację demona magazynowania ponieważ na tym komputerze będzie pracować tylko klient.
--enable-client-only – ustawia źródła tak, aby skompilowany został sam program klienta.
--with-scriptdir=[katalog] – wskazuje lokalizację na skrypty Bacula m.in. skrypt startowy klienta.
Podobnie jak w przypadku w/w komponentów kompilacja i instalacja zostanie wykonana po wydaniu komend:
root@freestar# make
root@freestar# make install
Konfiguracja klienta w systemie GNU/Linux
Plik konfiguracyjny klienta to bacula-fd.conf i i znaleźć go można na komputerze o nazwie "freestar" w lokalizacji:
/usr/local/bacula/etc/bacula-fd.conf
Umieszcza się w nim trzy typy zasobów:
- Client – główne ustawienia klienta. Nazwa stosowana zamiennie dla tego typu zasobu to "FileDaemon".
- Director – ustawienie zarządcy, który jest uprawniony do korzystania z klienta
- Messages – poziom logowania klienta
Zasób FileDemon (czy też Client) zawiera ogólne opcje programu klienta.
FileDaemon {
Name = freestar-fd
FD Address = 10.0.0.5
FD Port = 9102
Working Directory = /usr/local/bacula/var/bacula/working
PID Directory = /var/run
Maximum Concurrent Jobs = 1
}
Name – nazwa klienta. Nie ma specjalnego wymogu, aby nazwa ta była powiązana z nazwą klienta podawaną w pliku konfiguracyjnym zarządcy. Aby jednak móc łatwo zidentyfikować klienta z raportów zarządcy (przy założeniu, że taką samą nazwę nada się klientowi w pliku konfiguracyjnym zarządcy), przyjąłem konwencję nazewnictwa klientów w ich plikach konfiguracyjnych jako nazwa_komputera-fd. W tym wypadku jest to freestar-fd, gdzie suffix "fd" to skrót od File Daemon.
FD Address – adres IP. Podaje się tu adres IP interfejsu sieciowego, na którym działać ma klient. Adresem komputera "freestar" jest 10.0.0.5 i taki adres IP został użyty w tej dyrektywie.
FD Port – numer portu. Na tym porcie będzie nasłuchiwał klient. Domyślnym portem dla klientów Bacula jest port o numerze 9102.
Working Directory – lokalizacja. Wartość tej dyrektywy wskazuje na katalog, którego będzie używał klient do własnych potrzeb.
PID Directory – lokalizacja. Dyrektywa ta informuje klienta, gdzie podczas startu ma zapisać swój plik z otrzymanym identyfikatorem procesu.
Maximum Concurrent Jobs – ilość zadań. W tym miejscu jest możliwość podania ilości zadań, jakie jednocześnie może wykonywać klient. Każde nowe zadanie, które wykracza poza zadany tu limit zadań, będzie czekało w kolejce do czasu, aż klient będzie mógł je wykonać.
Aby zarządca mógł skomunikować się z klientem potrzebne jest wprowadzenie zasobu o nazwie Director, który informuje klienta o tym, jaki zarządca jest uprawniony do skorzystania z usług klienta.
Director {
Name = darkstar-dir
Password = "haslo do klienta freestar"
}
Name – nazwa zarządcy uprawnionego do używania klienta. Musi ona odpowiadać nazwie nadanej zarządcy w jego pliku konfiguracyjnym.
Password – hasło, którym serwis zarządcy będzie autoryzował się do klienta. Musi ono być takie same, jak hasło podane w zasobie klienta wpisanym w pliku konfiguracyjnym zarządcy.
Zasób Messages zawiera informacje o tym, jakie raporty będą przesyłane do serwisu zarządcy.
Messages {
Name = freestar-fd-messages
Director = darkstar-dir = all, !skipped, !restored
}
Name – nazwa zasobu.
Director – nazwa zarządcy oraz poziom raportowania. Podana tu nazwa zarządcy musi być taka sama jak nazwa nadana zarządcy w jego pliku konfiguracyjnym. Poziom logowania mówi o tym, jakiego typu informacje będą przekazywane do zarządcy.
Uruchomienie klienta w systemie GNU/Linux
Klienta można uruchomić poprzez wpisanie komendy:
root@freestar# /usr/local/bacula/sbin/bacula-fd -v -c /usr/local/bacula/etc/bacula-fd.conf
Aby sprawdzić czy klient działa można użyć komendy:
root@freestar# ps ax | grep bacula-fd
23673 ? Ssl 0:00 /usr/local/bacula/sbin/bacula-fd -v -c /usr/local/bacula/etc/bacula-fd.conf
Do sprawdzenia, czy klient nasłuchuje na odpowiednim porcie użyję komendy:
root@freestar# netstat -atn | grep '10.0.0.5'
tcp 0 0 10.0.0.5:9102 0.0.0.0:* LISTEN
Instalacja klienta w systemie Windows
W celu przeprowadzenia instalacji klienta w systemie Windows potrzeba zaopatrzyć się w plik instalatora, który jest do pobrania w projekcie Bacula na SourceForge.net. Po uruchomieniu programu instalatora, można powziąć następujące kroki:
Rysunek 3: Instalacja wraz z podaniem ustawień do pliku konfiguracyjnego klienta.
Wybór typu instalacji "Custom" pozwoli na wstępne skonfigurowanie klienta z poziomu instalatora.
Rysunek 4: Instalacja samego tylko klienta (bez narzędzi administracyjnych i dokumentacji)
W kroku wybierania komponentów do zainstalowania wybrałem tylko serwis klienta (File Service). Pozostałe dwie opcje – Consoles i Documentation – nie są potrzebne w założonej konfiguracji i z tego powodu nie będą tu omawiane.
Rysunek 5: Konfiguracja klienta.
Kolejne okno udostępnia pola, przy pomocy których można skonfigurować klienta. Pola te to:
Name – nazwa klienta,
Port – odpowiada numerowi portu, na którym klient będzie nasłuchiwać
Max Jobs – jest to odpowiednik dyrektywy Maximum Concurrent Jobs wymienionej już w opisywanej instalacji. Dla przypomnienia dodam, że jest to maksymalna ilość zadań, jaką klient jest w stanie jednocześnie wykonywać.
Password – hasło, przy pomocy którego zarządca będzie mógł przeprowadzić autoryzację z klientem. Takie samo hasło podaje się w definicji klienta w pliku konfiguracyjnym zarządcy.
Install as service – określa, czy klient ma pracować jako automatycznie uruchamiany przy starcie serwis, czy też użytkownik sam będzie uruchamiać klienta.
Start after install – określa, czy klient ma zostać uruchomiony po zakończeniu instalacji. W tym przykładzie pole to jest odznaczone, ponieważ potrzeba będzie zmodyfikować jeszcze plik konfiguracyjny klienta przed jego wystartowaniem. Wynika to z pewnego błędu w instalatorze, który jest opisany poniżej (Rysunek 7).
Rysunek 6: Podanie nazwy zarządcy.
DIR Name – nazwa zarządcy uprawnionego do korzystania z klienta.
Rysunek 7: Błąd podczas instalacji klienta.
Rysunek 7 pokazuje błąd, z jakim mogą spotkać się użytkownicy Bacula 5.0.2 podczas instalacji w systemie Windows. Z tego właśnie powodu, nie została zaznaczona opcja startu klienta zaraz po instalacji. W tym miejscu należy kliknąć przycisk "OK" i dokończyć instalację. Następnie potrzeba wyedytować plik konfiguracyjny klienta. Przy założeniu, że użytkownik zainstalował klienta w domyślnej lokalizacji, plik konfiguracyjny znajduje się w:
LITERA_PARTYCJI:/Program Files/Bacula/bacula-fd.conf
Trzeba usunąć stamtąd następujące linie:
#
# Restricted Director, used by tray-monitor to get the
# status of the file daemon
#
Director {
Name = @monitor_name@
Password = "@monitor_password@"
Monitor = yes
}
Po zapisaniu pliku konfiguracyjnego, można już uruchomić klienta poprzez managera zarządzania komputerem (Rysunek 8).
Rysunek 8: Ręczne uruchomienie serwisu klienta.
Uruchomienie klienta można zauważyć po nowej ikonie w tacce systemowej:
Po kliknięciu w nią pojawi się okno ze statusem klienta (Rysunek 9). Po wykonaniu zadania na kliencie będzie tam można podejrzeć jego status.
Rysunek 9: Podgląd statusu klienta.
Instalacja zarządcy
Podstawowa konfiguracja źródeł zarządcy przedstawia się następująco:
root@darkstar# tar zxf ./bacula-5.0.2.tar.gz
root@darkstar# cd ./bacula-5.0.2
root@darkstar# ./configure --prefix=/usr/local/bacula \
--disable-build-stored \
--with-scriptdir=/usr/local/bacula/scripts \
--with-postgresql=/usr
gdzie przełączniki oznaczają:
--prefix=[katalog] – określa lokalizację, gdzie zainstalowane mają być komponenty zarządcy. Tutaj przyjęto lokalizację /usr/local/bacula, lecz nic nie stoi na przeszkodzie wskazać inną lokalizację.
--disable-build-stored – wyłącza kompilację demona magazynowania. Na komputerze o nazwie "darkstar" nie będzie on potrzebny.
--with-scriptdir=[katalog] – wskazuje lokalizację na skrypty Bacula m.in. do tworzenia struktury bazy danych czy do startowania usług.
--with-postgresql=[katalog] – wskazanie miejsca, gdzie zainstalowany jest serwer PostgreSQL, przy czym znaczenie mają pliki nagłówkowe PostgreSQL, które zostaną wykorzystane podczas kompilacji.
Jeśli konfiguracja źródeł przebiegła bez błędów, to można przeprowadzić kompilację.
root@darkstar# make
Jeśli kompilacja powiodła się, można przejść do instalacji poprzez komendę:
root@darkstar# make install
Stworzenie i uruchomienie bazy danych
Jak już zostało wspomniane, Bacula w swej pracy do składowania różnego typu informacji używa relacyjnej bazy danych. Założenia instalacyjne (patrz Rysunek 2) wskazują, że serwer baz danych będzie działał na komputerze o nazwie "darkstar" tym samym, na którym został zainstalowany serwis zarządcy. W opisywanym przykładzie będzie to serwer PostgreSQL i zakładam, że jest on już zainstalowany ma komputerze "darkstar". Aby przygotować bazę danych do pracy z Bacula konieczne jest wykonanie poniżej opisanych kroków. Zakładam, że baza danych Bacula będzie zlokalizowana w:
/var/baza-bacula
Pierwszym krokiem jest utworzenie katalogu na bazę danych:
root@darkstar# mkdir /var/baza-bacula
oraz nadanie mu praw właściciela postgres i grupy postgres:
root@darkstar# chown postgres:postgres /var/baza-bacula
Następnie potrzeba nadać prawa właściciela postgres i grupy postgres skryptom serwisu zarządcy, które służą do stworzenia bazy danych (skrypt create_postgresql_database), stworzenia w niej tabel (skrypt make_postgresql_tables) oraz utworzenia użytkownika bazy danych, z poziomu którego Bacula będzie korzystać z bazy danych (skrypt grant_postgresql_privileges). Są to skrypty powłoki systemowej zawierające odpowiednie komendy SQL. Nadanie praw wykonujemy poprzez komendy:
root@darkstar# cd /usr/local/bacula/scripts
root@darkstar# chown postgres:postgres ./create_postgresql_database
root@darkstar# chown postgres:postgres ./make_postgresql_tables
root@darkstar# chown postgres:postgres ./grant_postgresql_privileges
Kolejnym krokiem jest stworzenie szablonu baz danych potrzebnych do uruchomienia serwera PostgreSQL. W tym celu potrzeba przełączyć się na użytkownika postgres:
root@darkstar# su postgres
i wydać komendę:
postgres@darkstar$ initdb /var/baza-bacula/
Po tych czynnościach można już uruchomić serwer baz danych poprzez komendę:
postgres@darkstar$ pg_ctl -D /var/baza-bacula/ -l /var/log/postgresql.log start
mając na uwadze, że plik logów /var/log/postgresql.log powinien istnieć w systemie i użytkownik postgres powinien mieć możliwość zapisu do niego.
Po uruchomienia serwera PostgreSQL można już stworzyć bazę danych Bacula uruchamiając skrypty w następujący sposób:
postgres@darkstar$ cd /usr/local/bacula/scripts
postgres@darkstar$ ./create_postgresql_database
Creation of bacula database succeeded.
postgres@darkstar$ ./make_postgresql_tables
Creation of Bacula PostgreSQL tables succeeded.
postgres@darkstar$ ./grant_postgresql_privileges
Privileges for user bacula granted on database bacula.
Domyślnym użytkownikiem bazy danych "bacula" jest użytkownik o nazwie "bacula". Pozostaje jeszcze zmienić hasło temu użytkownikowi, ponieważ funkcjonuje on z pustym hasłem. Będąc zalogowanym dalej na koncie użytkownika "postgres" należy wydać komendy:
postgres@darkstar$ psql -d bacula
bacula=# alter user bacula with password 'HasloDlaBacula';
Kończąc ten rozdział chciałbym wyjaśnić, że starałem się jak najkrócej opisać sposób na uruchomienie serwera bazodanowego, bez zgłębiania samych zagadnień związanych z funkcjonowaniem PostgreSQL. Ma to na celu nie nakierowywanie czytelnika ani na powyższe rozwiązanie, ani na wybór PostgreSQL. Użytkownik może do tego celu użyć np. serwera baz danych MySQL.
Konfiguracja zarządcy
Plik konfiguracyjny zarządcy bacula-dir.conf jest najbardziej rozbudowany spośród wszystkich plików konfiguracyjnych programów Bacula i to w nim najczęściej dokonuje się zmian. Podzielić można go na zasoby globalne oraz na te związane z zadaniami (np. backup, przywracanie danych). Zasoby zarządcy to:
- Director – główna konfiguracja zarządcy,
- Catalog – parametry połączenia z bazą danych,
- Messages – sposób zapisywania dzienników (w tym powiadomienia na e-mail),
- Job – zadanie (backup, restore, weryfikacja, migracja, kopiowanie i inne),
- FileSet – opcje zadania (listy dołączeń, listy wykluczeń, sygnatury plików, kompresja programowa i inne),
- Storage – ustawienia dostępnych urządzeń archiwizujących,
- Client – definicja klientów,
- Pool – pula woluminów,
- Schedule – harmonogram zadań.
Plik z konfiguracją zarządcy znajduje się w lokalizacji:
/usr/local/bacula/etc/bacula-dir.conf
Zasób Director zawiera podstawowe i ogólne ustawienia serwisu potrzebne do jego uruchomienia oraz działania.
Director {
Name = darkstar-dir
Password = "haslo do zarzadcy"
DIR Address = 10.0.0.2
DIR Port = 9101
Working Directory = /usr/local/bacula/var/bacula/working
PID Directory = /var/run
Query File = /usr/local/bacula/scripts/query.sql
Messages = DirMessages
Maximum Concurrent Jobs = 5
}
Użyte dyrektywy oznaczają:
Name – nazwa zarządcy. Zarządca używa jej do przedstawiania się podczas połączenia zarówno z demonem magazynowania jak i z serwisami klientów. Podczas konfiguracji demona magazynowania użyliśmy już tej nazwy dwukrotnie: w zasobie Director oraz Messages (patrz podrozdział: Konfiguracja demona magazynowania). Nazwa ta została użyta również w konfiguracji klientów.
Password – hasło, którego używają programy łączące się bezpośrednio z zarządcą (np. tekstowa konsola Bacula lub któreś z graficznych narzędzi administracyjnych).
DIR Address – adres IP interfejsu sieciowego, na którym pracować będzie zarządca. Patrząc na schemat prezentujący topologię opisywanej konfiguracji (Rysunek 2), będzie to adres komputera "darkstar" czyli 10.0.0.2.
DIR Port – numer portu, na którym nasłuchiwać będzie zarządca. Domyślnym portem komunikacyjnym zarządcy jest port 9101 i taki właśnie port został tu podany. Jeśli użytkownik zechciałby zmienić port nasłuchiwania zarządcy, to może to zrobić w tej dyrektywie.
Working Directory – katalog przeznaczony do przechowywania plików tworzonych przez zarządcę podczas pracy (np. pliki statusów).
PID Directory – lokalizacja katalogu, w którym tworzony będzie plik PID. Podobnie jak w konfiguracji demona magazynowania wybrałem do tego celu katalog systemowy "/var/run".
Query File – lokalizacja pliku z zapytaniami SQL. Podczas instalacji zarządcy, wraz z plikami binarnymi został zainstalowany pusty plik o nazwie "query.sql" przeznaczony do przechowywania zapytań SQL użytkownika. W ramach podstawowej instalacji Bacula proponuję użyć przykładowych zapytań SQL dostępnych w pliku "sample-query.sql" znajdującym się w katalogu źródeł w podkatalogu nazwie "examples”. Można tego dokonać poprzez skopiowanie pliku z katalogu źródeł do lokalizacji plików zarządcy np. w poniższy sposób.
cp /LOKALIZACJA_ZRODEL/bacula-5.0.2/examples/sample-query.sql /usr/local/bacula/scripts/query.sql
Plik z zapytaniami SQL posiada określoną składnię, której tu nie opiszę, lecz powiem tylko, że zawiera on zestaw zapytań mogących ułatwić pracę w konsoli Bacula, np. poprzez wybieranie z bazy przydatnych dla użytkownika danych. Osobiście najbardziej w tym rozwiązaniu podoba mi się to, że plik można dopasowywać do własnych potrzeb poprzez modyfikację istniejących zapytań SQL czy też poprzez dopisanie nowych zapytań. Menu za pomocą którego można używać tego sposobu wybierania rekordów z bazy danych dostępne jest po wpisaniu w konsoli Bacula komendy "query".
Rysunek 10: Domyślna lista zapytań do bazy danych dostępna poprzez komendę "query" wydawaną w tekstowej konsoli Bacula.
Messages – nazwa zasobu Messages, który określa sposób raportowania do dziennika zarządcy. Dotyczy to statusów zdarzeń nie związanych z uruchomionymi zadaniami. Do zasobów zadań jest możliwość przypisania osobnego sposobu raportowania zdefiniowanego w innym zasobie Messages.
Maximum Concurrent Jobs – ilość zadań, które jednocześnie może realizować zarządca. Taka dyrektywa występowała już przy okazji konfigurowania demona magazynowania, lecz tam dotyczyła ilości zadań, które jednocześnie mógł obsłużyć demon. W tym miejscu limit ilości zadań dotyczy całego serwisu zarządcy.
Kolejnym zasobem do skonfigurowania jest zasób Catalog. Jego wartości odnoszą się do bazy danych wykorzystywanej do pracy z Bacula.
Catalog {
Name = "Baza danych Bacula"
DB Name = bacula
DB Address = 127.0.0.1
DB Port = 5432
User = bacula
Password = HasloDlaBacula
}
gdzie użyte dyrektywy oznaczają:
Name – nazwa zasobu. Używana jest w zasobach Client (opisanych poniżej) aby poinformować zarządcę o tym, do jakiej bazy danych składować ma informacje od określonych klientów.
DB Name – nazwa bazy danych SQL. Domyślną nazwą jest "bacula" i taką pozostawię w tym przykładzie.
DB Address – IP interfejsu, na którym działa serwer baz danych Baculi.
DB Port – numer portu, na którym nasłuchuje serwer baz danych.
User – użytkownik bazy danych Bacula. Używane przez zarządcę do autoryzacji z bazą danych.
Password – hasło do bazy danych Bacula. Używane przez zarządcę do autoryzacji z bazą danych.
Zasób Messages dotyczy raportowania przez zarządcę o zachodzących zdarzeniach i określa co, gdzie i w jaki sposób zostanie zaraportowanie.
Messages {
Name = DirMessages
Console = all, !skipped, !saved
Append = "/var/log/bacula.log" = all, !skipped !saved
}
gdzie użyte dyrektywy oznaczają:
Name – nazwa zasobu. W tym przykładzie nazwa to DirMessages i odpowiada ona nazwie, która została podana w opisanym wyżej zasobie Director w pliku konfiguracyjnym zarządcy. Oznacza to, że zarządca będzie używał tej konfiguracji do raportowania. Jest to minimalna konfiguracja wysyłania statusów do pliku /var/log/bacula.log (tutaj pełniącego rolę pliku logów Bacula) oraz bezpośrednio na konsolę Baculi. Warto zaznajomić się z tematem raportowania w dokumentacji Bacula, gdyż możliwości tej funkcjonalności są obszerne. Podam tutaj choćby możliwość wysyłania raportów na e-mail przy użyciu narzędzia Bacula o nazwie bsmtp lub jakiegokolwiek innego programu potrafiącego wysyłać wiadomości e-mail.
Console – ustawienie wyświetlania statusów i zdarzeń w konsoli Baculi. Wartość "all" odpowiada pełnemu raportowaniu wszystkiego. Następujące po niej wartości "!skipped" oraz "!saved" oznaczają kolejno: wyłączenie z logowania plików zapisanych w liście wykluczeń i wykluczenie z logowania plików zapisywanych na woluminy.
Append – ustawienie zapisywania statusów i raportów z wszystkich usług do pliku /var/log/bacula.log. Wartości "all", "!skipped", "!saved" mają te same znaczenie co opisane powyżej wartości w dyrektywie Console.
Zasób Storage w znacznej mierze przeznaczony jest do zdefiniowania urządzeń, z których korzystać będzie zarządca oraz do podania wartości potrzebnych do komunikacji z demonem magazynowania, który obsługuje te urządzenia. W zależności od tego z ilu urządzeń ma korzystać zarządca, tyle zasobów Storage potrzeba zdefiniować.
Storage {
Name = Dysk
Address = 10.0.0.3
SD Port = 9103
Password = "haslo do demona magazynowania"
Device = "Urzadzenie Plikowe"
Media Type = File
Maximum Concurrent Jobs = 1
}
Storage {
Name = Tasma
Address = 10.0.0.3
SD Port = 9103
Password = "haslo do demona magazynowania"
Device = "Naped tasmowy"
Media Type = SLR7
Maximum Concurrent Jobs = 1
}
Użyte dyrektywy oznaczają:
Name – nazwa urządzenia. Ta nazwa będzie używana przy tworzeniu zadań (np. backupu) w zasobie Job. Będzie ona również widziana w konsoli Baculi.
Address – adres IP komputera z demonem magazynowania, który obsługuje definiowane urządzenie. W opisywanym przykładzie będzie to komputer "hardstar", którego IP to 10.0.0.3.
SD Port – numer portu komunikacyjnego na komputerze demona magazynowania, do którego łączyć będzie się zarządca. Jest to ten sam port, który został podany przy konfiguracji demona magazynowania.
Password – hasło, którego użyje zarządca przy autoryzacji do demona magazynowania. Jest to to samo hasło, które zostało zapisane w pliku konfiguracyjnym demona magazynowania.
Device – nazwa urządzenia. Nazwa powinna odpowiadać nazwie urządzenia z pliku konfiguracyjnego demona magazynowania.
Media Type – typ obsługiwanych woluminów przez urządzenie. Powinien on odpowiadać typowi określonemu dla urządzenia z pliku konfiguracyjnego demona magazynowania.
Maximum Concurrent Jobs – ilość zadań, które jednocześnie może realizować urządzenie. Jest to kolejny poziom, na którym jest możliwość limitowania jednocześnie uruchomionych zadań. Wartość 1 oznacza, że urządzenie może wykonywać w tym samym czasie tylko jedno zadanie.
Kolejnym zasobem do skonfigurowania jest zasób Client. Zawarte w nim wartości dotyczą danych autoryzacji z poszczególnymi klientami oraz cech charakterystycznych dla klienta na poziomie zarządcy.
Client {
Name = freestar-fd
Address = 10.0.0.5
FD Port = 9102
Catalog = "Baza danych Bacula"
Password = "haslo do klienta freestar"
AutoPrune = no
}
Client {
Name = easystar-fd
Address = 10.0.0.6
FD Port = 9102
Catalog = "Baza danych Bacula"
Password = "haslo do klienta easystar"
AutoPrune = no
}
Użyte dyrektywy oznaczają kolejno:
Name – nazwa klienta. Nie musi ona odpowiadać nazwie zapisanej w pliku konfiguracyjnym klienta, lecz jednakowe nazewnictwo po obydwu stronach (klienta i zarządcy) może zapobiec możliwemu pomyleniu klientów w dalszej konfiguracji.
Address – adres IP komputera klienta. Zgodnie ze schematem z Rysunku 2 komputery o nazwach "freestar" i "easystar" mają ustawione IP odpowiednio 10.0.0.5 i 10.0.0.6.
FD Port – numer portu na komputerze klienta, na którym nasłuchuje klient. Na obydwu skonfigurowanych klientach jest to port 9102.
Catalog – nazwa zasobu Catalog z pliku konfiguracyjnego zarządcy. Dyrektywa ta mówi zarządcy o tym, jakiej bazy danych użyć dla składowania danych otrzymywanych od klienta.
Password - hasło, którego użyje zarządca podczas autoryzacji do klienta. Jest to to samo hasło, które zostało zapisane w pliku konfiguracyjnym klienta.
AutoPrune – włącza/wyłącza automatyczne uruchamianie operacji prune, której zadaniem jest wyczyszczenie z bazy danych przestarzałych rekordów dla zarchiwizowanych plików i dla wykonanych backupów. Jeśli dyrektywa ustawiona jest na "yes" to po każdym wykonanym przez klienta zadaniu nastąpi próba wyczyszczenia przestarzałych rekordów. Domyślnie ustawionym czasem, po którym rekordy plików i zadań zostaną uznane za przestarzałe jest czas 60 dni dla plików oraz 180 dni dla zadań. Funkcjonalność ta ma uchronić użytkownika przed nadmiernym rozrastaniem się bazy danych oraz zapewnić dostępność rekordów plików i zadań przez określony czas. W sytuacji częstego archiwizowania dużej ilości plików (liczonej w setkach tysięcy czy milionach) baza danych może osiągnąć niepokojący rozmiar. Dzieje się tak za sprawą, że dla każdego archiwizowanego pliku zostaje utworzony w bazie danych osobny wpis. Przy backupie miliona plików w bazie danych przybędzie milion rekordów. Osobiście nie jestem zwolennikiem tego sposobu na kontrolę zajętości bazy danych i bardziej w tym celu polecałbym zastosowanie recyklingu wolumenów. W opisywanym przykładzie dyrektywa została więc wyłączona.
Pule woluminów reprezentowane są przez zasób Pool. Głównym zadaniem puli woluminów jest grupowanie woluminów w poszczególne grupy, które mogą być wykorzystane do określonych zadań (np. pula z woluminami do backupów przyrostowych czy też pula do backupów pełnych). Przy tworzeniu woluminu podaje się pulę, do której wolumin ma trafić. Podczas tej operacji woluminowi zostają nadane cechy charakterystyczne dla danej puli jak choćby zdefiniowane limity nałożone na wolumin (np. maksymalny rozmiar, czas zdolności woluminu do zapisywania danych, zdolność do recyklingu itp.).
Pool {
Name = "Pliki Full"
Pool Type = Backup
Recycle = yes
Auto Prune = yes
Volume Retention = 120 days
Maximum Volume Bytes = 500 MB
Storage = Dysk
}
Pool {
Name = "Tasma Full"
Pool Type = Backup
Recycle = no
Auto Prune = no
Storage = Tasma
}
Użyte dyrektywy oznaczają kolejno:
Name – nazwa puli woluminów. Będzie ona widoczna w konsoli Baculi oraz będzie można się nią posługiwać przy konfiguracji np. backupów w celu wskazania, z jakiej puli woluminy będą używane.
Pool Type – przeznaczenie puli woluminów. Dyrektywa ta jest obowiązkowa dla zasobu Pool, lecz do tej pory jedyną możliwą jej wartością jest "Backup". Dzieje się tak, ponieważ jak dotąd tylko taka wartość została zaimplementowana.
Recycle – włącza/wyłącza zdolność woluminów do recyklingu. Jeśli dyrektywa ustawiona na "yes" oznacza to, że każdemu nowo tworzonemu woluminowi w puli woluminów będzie nadawana zdolność do recyklingu (do ponownego użycia).
Auto Prune – działanie tej dyrektywy jest zbliżone do działania opisanej wyżej dyrektywy o tej samej nazwie w zasobie Client z tą różnicą, że w przypadku załączonej dyrektywy, okres czasu decydujący o przedawnieniu danych woluminów w bazie danych zliczany jest od momentu oznaczenia woluminu statusem Full lub Used a czyszczone są w bazie danych rekordy plików, zadań i woluminów. Po takiej operacji wolumin jest gotowy do ponownego użycia.
Volume Retention – czas zachowania danych na woluminie. Liczony jest od chwili oznaczenia woluminu statusem Full lub Used. Po jego upłynięciu dane na woluminie zostają uznane za przedawnione i możliwy jest na nim do wykonania proces recyklingu.
Maximum Volume Bytes – określa maksymalny rozmiar woluminu.
Storage – nazwa urządzenia. Dyrektywa ta nie jest konieczna do występowania w zasobie Pool, lecz uważam, że to dobra praktyka, gdyż w jednej puli woluminów powinny znajdować się woluminy jednego typu (ten sam Media Type) obsługiwane przez konkretne urządzenie. Drugim plusem umieszczenia tu tej dyrektywy jest to, że przy definicji zadania (zasób Job) nie trzeba pamiętać które urządzenie ma woluminy w której puli taśm, ale po prostu podaje się jedynie nazwę puli taśm. Wartością tej dyrektywy jest nazwa zasobu Storage, który odnosi się do żądanego przez użytkownika urządzenia.
Kolejny zasób – FileSet – zawiera informacje o tym, co ma zostać zarchiwizowane i w jaki sposób. W zakres ustawień tego zasobu wchodzą listy dołączeń (Include) oraz listy wykluczeń (Exclude). Zakładam tutaj, że jedna kopia zapasowa zostanie wykonana z katalogów:
/home/stefan/multimedia
/home/marian/media
znajdujących się na komputerze o nazwie "freestar". Druga kopia zostanie wykonana z następującej lokalizacji komputerze "easystar":
C:/Documents and settings/Abram/Moje dokumenty
Odpowiada temu konfiguracja:
FileSet {
Name = "Katalogi multimedia"
Include {
Options {
Signature = MD5
}
File = /home/stefan/multimedia
File = /home/marian/media
}
}
FileSet {
Name = "Dokumenty Abrama"
Include {
Options {
Signature = MD5
}
File = "c:/Documents and settings/Abram/Moje dokumenty"
}
}
gdzie dyrektywy oznaczają kolejno:
Name – nazwa zasobu.
Include – podzasób zasobu FileSet. W nim zawiera się lokalizacje, które mają być archiwizowane.
Options – opcje podzasobu Include.
Signature – sposób tworzenia sygnatur kopii zapasowych. W tym przykładzie do tego celu zostanie użyty algorytm MD5. Jest tu też możliwość skorzystania z bardziej dokładnego algorytmu SHA, lecz trzeba mieć na uwadze, że tworzenie sygnatur przy pomocy SHA wymaga skompilowania Bacula z obsługą ssl (biblioteki openssl) i zużywa więcej mocy procesora niż użycie MD5.
File – lokalizacje podlegające archiwizacji. W tym przykładzie backup wykona się z katalogów /home/stefan/multimedia oraz /home/marian/media wraz z ich całą zawartością (komputer "freestar") oraz katalog c:/Documents and settings/Abram/Moje dokumenty wraz całą zawartością (komputer "easystar").
Ważnym z punktu widzenia automatyzacji Bacula jest konfiguracja harmonogramu zadań. Odpowiednio dopasowany harmonogram wykonywania zadań może znacznie usprawnić proces archiwizacji odciążając tym samym użytkownika z potrzeby uruchamiania zadań manualnie.
Schedule {
Name = "Cykl tygodniowy"
Run = Full mon-fri at 22:30
}
Użyte dyrektywy oznaczają kolejno:
Name – nazwa harmonogramu zadań.
Run – określenie kiedy i z jakimi parametrami zadanie ma zostać wystartowane. W tym przykładzie każde zadanie wykorzystujące ten harmonogram będzie wykonywać się jako kopia pełna i uruchamiać będzie się automatycznie o godzinie 22:30 od poniedziałku do piątku.
Ostatnim opisanym tu zasobem jest zasób Job czyli inaczej mówiąc zasób zadań realizowanych przez Bacula. Jak łatwo zauważyć wykorzystuje on większość z opisanych wyżej zasobów (Client, Pool, Schedule, Messages oraz FileSet). Przy pomocy zasobu Job można zdefiniować zadanie backupu, przywracania danych, weryfikacji i innych typów zadań. Zawiera on odniesienia do wszystkiego co potrzeba aby takie zadanie przeprowadzić. Poniżej przedstawiono dwa zadania (obydwa to backup). Pierwszy backup wykona się z danych zawartych na kliencie "freestar-fd", drugie natomiast wykona się z danych klienta "easystar-fd"
Job {
Name = Multimedia
Type = Backup
Level = Full
Client = freestar-fd
Pool = "Pliki Full"
Schedule = "Cykl tygodniowy"
Messages = DirMessages
FileSet = "Katalogi multimedia"
}
Job {
Name = "Pliki Abrama"
Type = Backup
Level = Full
Client = easystar-fd
Pool = "Tasma Full"
Schedule = "Cykl tygodniowy"
Messages = DirMessages
FileSet = "Dokumenty Abrama"
}
Użyte dyrektywy oznaczają kolejno:
Name – nazwa zasobu zadania. Ta nazwa będzie widoczna w konsoli Bacula w liście dostępnych zadań do wykonania.
Type – określa typ zadania. Możliwe wartości do ustawienia to:
- Backup
- Restore
- Verify
- Admin
Wartość tej dyrektywy decyduje o przeznaczeniu zadania. W powyższym przykładzie są to zadania typu backup czyli innymi słowy kopie zapasowe. Jeśli w to miejsce zostanie wpisana wartość "Restore", to zadanie będzie wykonywało operację przywracania danych.
Level – poziom zadania. Dyrektywa dotyczy zadań typu Backup oraz Verify. Dla backupu określa się tu jego poziom. Dla kopii pełnej będzie to wartość "Full", dla kopii przyrostowej będzie to "Incremental" a dla kopii różnicowej wartością będzie "Differental".
Niech czytelnik nie ma mi za złe, że pominę temat zadań typu Verify oraz Admin. Otwierają one tematy znacznie wykraczające poza podstawową konfigurację Bacula. Użytkowników zainteresowanych tym tematem odsyłam do dokumentacji Bacula.
Client – nazwa zasobu klienta, który zostanie użyty w realizacji zadania.
Pool – nazwa zasobu puli woluminów, która zostanie użyta w zadaniu.
Schedule – nazwa zasobu harmonogramu zadań. Na tej podstawie Bacula uruchomi zadanie o czasie określonym w zasobie Schedule.
Messages – nazwa zasobu Messages wykorzystanego do backupu. Inaczej mówiąc jest to wybór sposobu raportowania danego backupu. W tym artykule dla uproszczenia wykorzystałem jeden zasób Messages zarówno do raportowania komunikatów dotyczących zarządcy jak i komunikatów związanych z działaniem zadań backupu.
FileSet – nazwa zasobu FileSet. Jeśli zadaniem jest backup, to dyrektywa ta dostarcza do zdania informacje o tym, co zostanie zarchiwizowane.
Uruchomienie zarządcy
Uruchomienie zarządcy może wyglądać następująco:
root@darkstar# /usr/local/bacula/sbin/bacula-dir -v -c /usr/local/bacula/etc/bacula-dir.conf
O zależnościach słów kilka
Na Rysunku 11 znajduje się cała przedstawiona do tej pory konfiguracja wraz z zaznaczonymi zależnościami pomiędzy poszczególnymi dyrektywami i serwisami. Znajduje się tam konfiguracja: zarządcy (kolor czcionki: czerwony), demona magazynowania (kolor czcionki: niebieski) oraz konfiguracje klientów (kolor czcionki: zielony).
Rysunek 11: Schemat zależności konfiguracji serwisów Bacula.
Instalacja konsoli administracyjnej
Nieodłącznym narzędziem administracyjnym oprogramowania Bacula jest jej tekstowa konsola. Można uruchomić ją na komputerze "hardstar", "darkstar" czy też "freestar" ponieważ jest ona instalowana domyślnie wraz z przekompilowanymi usługami. Na komputerze "easystar" z systemem Windows również jest taka możliwość pod warunkiem zaznaczenia opcji konsoli podczas instalacji klienta. Na Rysunku 2 komputer z którego użytkownik będzie uruchamiał konsolę celowo nie ma nadanej nazwy, aby zaznaczyć, że może to być dowolny komputer z systemem operacyjnym obsługującym Bacula.
Instalacja tekstowej konsoli może przebiegać np. w ten sam sposób co opisana w artykule kompilacja klienta w systemie GNU/Linux. Zakładam, że właśnie tą drogę wybrał użytkownik.
Konfiguracja konsoli administracyjnej
Plik konfiguracyjny konsoli Bacula to bconsole.conf i przy lokalizacji komponentu Bacula w /usr/local/bacula, plik ten można znaleźć w katalogu:
/usr/local/bacula/etc/bconsole.conf
W najprostszej konfiguracji może on składać się z jednego zasobu:
Director {
Name = darkstar-dir
Address = 10.0.0.2
DIR Port = 9101
Password = "haslo do zarzadcy"
}
Użyte dyrektywy oznaczają kolejno:
Name – nazwa zarządcy.
Address – adres IP komputera zarządcy, do którego konsola będzie podłączona.
DIR Port – numer portu, na którym pracuje zarządca i na który łączyć będzie się konsola.
Password – hasło zarządcy zdefiniowane w jego pliku konfiguracyjnym w zasobie Director.
Administracja Bacula
Konsolę uruchamia się w poniższy sposób (przy założeniu, że zainstalowana jest w lokalizacji /usr/local/bacula).
/usr/local/bacula/sbin/bconsole -c /usr/local/bacula/etc/bconsole.conf
W pliku konfiguracyjnym zarządcy zostały skonfigurowane dwa zadania backupowe (zasoby Job) o nazwach "Multimedia" i "Pliki Abrama". Pierwszy zostanie wykonany z danych znajdujących się na komputerze "freestar" i zapisany na woluminie plikowym. Drugi natomiast zarchiwizuje dane z komputera "easystar" i zapisze dane na taśmie magnetycznej streamera.
Przed przystąpieniem do wykonania backupu o nazwie "Multimedia", potrzebne będzie stworzenie woluminu na urządzeniu o nazwie "Dysk". Wolumin ten zostanie umieszczony w puli woluminów o nazwie "Pliki Full". Operację tą prezentuje poniższy listing.
*label pool="Pliki Full" storage=Dysk
Enter new Volume name: vol-plik-full-1
Connecting to Storage daemon Dysk at 10.0.0.3:9103 ...
Sending label command for Volume "vol-plik-full-1" Slot 0 ...
3000 OK label. VolBytes=206 DVD=0 Volume="vol-plik-full-1" Device="Urzadzenie Plikowe" (/mnt/storage)
Catalog record for Volume "vol-plik-full-1", Slot 0 successfully created.
Requesting to mount Urzadzenie Plikowe ...
3906 File device "Urzadzenie Plikowe" (/mnt/storage) is always mounted.
Gwiazdka przed poleceniem "label" jest znakiem zachęty tekstowej konsoli Bacula, a nie fragmentem komendy. Uwaga ta dotyczy wszystkich prezentowanych komend w konsoli Bacula.
Backup o nazwie "Multimedia" uruchomić można poprzez komendę "run".
*run job=Multimedia
Run Backup job
JobName: Multimedia
Level: Full
Client: freestar-fd
FileSet: Katalogi multimedia
Pool: Pliki Full (From Job resource)
Storage: Dysk (From Pool resource)
When: 2010-06-05 01:08:44
Priority: 10
OK to run? (yes/mod/no): yes
Job queued. JobId=1
Poniżej znajduje się wydruk statusu pomyślnie zakończonego backupu "Multimedia".
05-Jun 01:09 darkstar-dir JobId 1: Start Backup JobId 1, Job=Multimedia.2010-06-05_01.09.18_04
05-Jun 01:09 darkstar-dir JobId 1: Using Device "Urzadzenie#Plikowe"
05-Jun 03:09 hardstar-sd JobId 1: Wrote label to prelabeled Volume "vol-plik-full-1" on device "Urzadzenie Plikowe" (/mnt/storage)
05-Jun 03:09 hardstar-sd JobId 1: Job write elapsed time = 00:00:04, Transfer rate = 56.87 M Bytes/second
05-Jun 01:09 darkstar-dir JobId 1: Bacula darkstar-dir 5.0.2 (28Apr10): 05-Jun-2010 01:09:24
Build OS: i686-pc-linux-gnu slackware Slackware 13.0.0.0.0
JobId: 1
Job: Multimedia.2010-06-05_01.09.18_04
Backup Level: Full
Client: "freestar-fd" 5.0.2 (28Apr10) i686-pc-linux-gnu,debian,5.0.4
FileSet: "Katalogi multimedia" 2010-06-05 01:09:18
Pool: "Pliki Full" (From Job resource)
Catalog: "Baza danych Bacula" (From Client resource)
Storage: "Dysk" (From Pool resource)
Scheduled time: 05-Jun-2010 01:08:44
Start time: 05-Jun-2010 01:09:20
End time: 05-Jun-2010 01:09:24
Elapsed time: 4 secs
Priority: 10
FD Files Written: 92
SD Files Written: 92
FD Bytes Written: 227,478,206 (227.4 MB)
SD Bytes Written: 227,489,627 (227.4 MB)
Rate: 56869.6 KB/s
Software Compression: None
VSS: no
Encryption: no
Accurate: no
Volume name(s): vol-plik-full-1
Volume Session Id: 1
Volume Session Time: 1275687279
Last Volume Bytes: 227,660,995 (227.6 MB)
Non-fatal FD errors: 0
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK
Do wykonania backupu "Pliki Abrama" potrzeba nadać etykietę taśmie magnetycznej, którą to operację przedstawia poniższy listing. Taśma będzie składowana w puli woluminów "Tasma Full".
*label pool="Tasma Full" storage=Tasma
Enter new Volume name: vol-tasma-full-1
Connecting to Storage daemon Tasma at 10.0.0.3:9103 ...
Sending label command for Volume "vol-tasma-full-1" Slot 0 ...
3000 OK label. VolBytes=64512 DVD=0 Volume="vol-tasma-full-1" Device="Naped tasmowy" (/dev/nst0)
Catalog record for Volume "vol-tasma-full-1", Slot 0 successfully created.
Requesting to mount Naped tasmowy ...
3001 Device "Naped tasmowy" (/dev/nst0) is mounted with Volume "vol-tasma-full-1"
Uruchomienie backupu "Pliki Abrama":
*run job="Pliki Abrama"
Run Backup job
JobName: Pliki Abrama
Level: Full
Client: easystar-fd
FileSet: Dokumenty Abrama
Pool: Tasma Full (From Job resource)
Storage: Tasma (From Pool resource)
When: 2010-06-05 09:37:09
Priority: 10
OK to run? (yes/mod/no): yes
Job queued. JobId=2
Poprawny status wykonanego backupu o nazwie "Pliki Abrama" wygląda jak poniżej.
05-Jun 09:37 darkstar-dir JobId 2: Start Backup JobId 2, Job=Pliki_Abrama.2010-06-05_09.37.21_03
05-Jun 09:37 darkstar-dir JobId 2: Using Device "Naped tasmowy"
05-Jun 11:37 hardstar-sd JobId 2: Wrote label to prelabeled Volume "vol-tasma-full-1" on device "Naped tasmowy" (/dev/nst0)
05-Jun 11:37 easystar-fd JobId 2: Generate VSS snapshots. Driver="VSS WinXP", Drive(s)="C"
05-Jun 11:38 easystar-fd JobId 2: VSS Writer (BackupComplete): "Microsoft Writer (Service State)", State: 0x1 (VSS_WS_STABLE)
05-Jun 11:38 easystar-fd JobId 2: VSS Writer (BackupComplete): "Microsoft Writer (Bootable State)", State: 0x1 (VSS_WS_STABLE)
05-Jun 11:38 easystar-fd JobId 2: VSS Writer (BackupComplete): "WMI Writer", State: 0x1 (VSS_WS_STABLE)
05-Jun 11:38 easystar-fd JobId 2: VSS Writer (BackupComplete): "MSDEWriter", State: 0x1 (VSS_WS_STABLE)
05-Jun 11:38 hardstar-sd JobId 2: Job write elapsed time = 00:00:27, Transfer rate = 1.119 M Bytes/second
05-Jun 09:38 darkstar-dir JobId 2: Bacula darkstar-dir 5.0.2 (28Apr10): 05-Jun-2010 09:38:24
Build OS: i686-pc-linux-gnu slackware Slackware 13.0.0.0.0
JobId: 2
Job: Pliki_Abrama.2010-06-05_09.37.21_03
Backup Level: Full
Client: "easystar-fd" 5.0.2 (28Apr10) Linux,Cross-compile,Win32
FileSet: "Dokumenty Abrama" 2010-06-05 09:16:06
Pool: "Tasma Full" (From Job resource)
Catalog: "Baza danych Bacula" (From Client resource)
Storage: "Tasma" (From Pool resource)
Scheduled time: 05-Jun-2010 09:37:09
Start time: 05-Jun-2010 09:37:24
End time: 05-Jun-2010 09:38:24
Elapsed time: 1 min
Priority: 10
FD Files Written: 28
SD Files Written: 28
FD Bytes Written: 30,233,927 (30.23 MB)
SD Bytes Written: 30,239,264 (30.23 MB)
Rate: 503.9 KB/s
Software Compression: None
VSS: yes
Encryption: no
Accurate: no
Volume name(s): vol-tasma-full-1
Volume Session Id: 1
Volume Session Time: 1275727652
Last Volume Bytes: 30,385,152 (30.38 MB)
Non-fatal FD errors: 0
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK
Podsumowanie
W artykule starałem się przedstawić podstawową instalację i konfigurację serwisów Bacula używając do tego prostych rozwiązań, a omijając tzw. "tematy rzeka" lub sygnalizując tylko o ich istnieniu, jak choćby recykling woluminów. Zagadnienia "wodotrysków" typu dopełnianie poleceń w konsoli Bacula czy cała gama graficznych narzędzi administracyjnych nie zostały omówione wcale.
Użyte hasła w konfiguracji poszczególnych serwisów mają za zadanie ułatwić czytelnikowi zrozumienie tego, do czego dane hasło jest wykorzystywane np. "haslo do klienta freestar". Osobiście zalecam używanie znacznie trudniejszych haseł.
Na zakończenie chciałbym zachęcić czytelników do studiowania dokumentacji Bacula, którą można znaleźć na oficjalnej witrynie Bacula pod adresem http://bacula.org. To naprawdę solidne źródło wiedzy, dzięki któremu czytelnik – jeśli ma to w zamiarze – będzie mógł zbudować i rozwinąć swą konfigurację Bacula.