Zapraszam do lektury kolejnej, czwartej już części cyklu artykułów opisujących wdrożenie oprogramowania Bacula w środowisku dużego dostawcy hostingowego. W części tej przedstawione zostaną szczegóły oprogramowania Bacula, a w szczególności polityki backupowe i zarządzanie klientami. Zapraszam.

Część IV

Ten artykuł da wam lepszy wgląd w naszą obecną konfigurację oprogramowania Bacula i w związane z tym metodologie. Ważne jest dla nas zredukowanie czasu poświęcanego na konfigurację do absolutnego minimum, podczas gdy wciąż jesteśmy zdolni do utrzymania wysokiego poziomu elastyczności (konfiguracji Baculi¹). Dopracowaliśmy więc taki sposób planowania, który będąc ekstremalnie prosty, daje wymaganą elastyczność. Tu zdradzę nasz mały sekret: odpowiedzią na pytanie jak to osiągnąć, jest parametr konfiguracyjny Baculi „Max Full Interval”. Standardowo jedyny poziom backupu który uruchamiamy to poziom przyrostowy (incremental¹). Pierwsze zadanie które uruchamia klient to zawsze backup pełny (full¹). Kiedy wygaśnie czas określony przez „Max Full Interval” Bacula automatycznie przestawia następny backup przyrostowy na pełen backup. Zmiana harmonogramu pełnego backupu sprowadza się więc do uruchomienia pełnego backupu w określonym dniu, a parametr „Max Full Interval” zajmie się resztą. Sprytnie, co?

Dla każdego klienta utrzymujemy po jednym pliku konfiguracyjnym. Ten jeden plik zawiera wszystko to co jest potrzebne. Wszystkie pliki konfiguracyjne są przechowywane w wyznaczonym specjalnie na ten cel katalogu na Dyrektorze, który „zarządza” klientem. Pliki są uwzględniane przez Dyrektora podczas startu lub operacji przeładowania. Potrzebujemy zdeaktywować klienta? Po prostu zmieniamy nazwę pliku konfiguracyjnego i wykonujemy polecenie „reload” z konsoli tekstowej bconsole. Takie podejście sprowadza się jeszcze do wykorzystania wzorców. Mamy zakodowany pewien prosty mechanizm tworzenia wzorców, który wyszukuje i zamienia kilka z określonych tagów a następnie zapisuje plik jako %CLIENT_IP%.conf. Przechowywanie unikalnych dla każdego klienta danych np. w bazie MySQL jest wyjątkowo proste. Dane te można następnie wykorzystać wstawiając do wzorca pliku konfiguracyjnego,  a to sprawia że zadanie automatycznego przekonfigurowania większej liczby klientów jest równie proste.

Wszystko w naszej konfiguracji odnosi się do określonego adresu IP klienta, gdyż to pozwala nam porozumiewać się z bazą CRM, systemem bilingowym, itp. za pomocą tego unikalnego identyfikatora.

Planowanie i Zadania

Raz w tygodniu wykonujemy pełen backup każdego klienta; backupy przyrostowe wykonywane są pomiędzy nimi. Głównym powodem takiego podejścia jest sytuacja już zastana: nasza stara platforma wykonywania kopii zapasowych robiła to w ten sposób, a my próbowaliśmy przenieść możliwie jak najwięcej z istniejących metodologii do Baculi, po to by uniknąć możliwych opóźnień i nieporozumień podczas migracji.

Zdefiniowaliśmy 2 plany:

Schedule {
   Name = “Regular“
   Run = Incremental mon-sun at 02:00
}

Schedule {
   Name = “Late“
   Run = Incremental mon-sun at 03:00
}

Wszyscy klienci - poza kilkoma specjalnymi przypadkami - wykorzystują jeden z powyższych planów. Głównym powodem, dla którego powstał plan “Late” było umożliwienie by określone maszyny z systemem Windows, wykonały aktualizację i restart zanim zostanie uruchomiony backup.

Oto jak mniej więcej jest zadeklarowane nasze zadanie:

Job {
   Name = %CLIENT_IP%
   Client = %CLIENT_IP%
   Type = Backup
   Schedule = Regular
   FileSet = %CLIENT_IP%
   Max Full Interval = 6 days
   Pool = %CLIENT_IP%
   Messages = Standard
   Write Bootstrap = “/var/bacula/working/%CLIENT_IP%.bsr“
}

Pule i Wolumeny

Każdy klient ma swóje własne urządzenie puli i wolumenu. Każde zadanie trzymane jest na osobnym wolumenie. Każde urządzenie składujące wskazuje do osobnego dla każdego klienta systemu plików ZFS.

To umożliwia nam łatwą kontrolę nad czasami retencji, ilością wolumenów rezerwowych, politykami czyszczącymi, itd dla każdego z klientów osobno.

Pool {
   Name = %CLIENT_IP%
   Storage = %CLIENT_IP%
   Pool Type = Backup
   Recycle = yes
   Recycle Oldest Volume = yes
   AutoPrune = yes
   Volume Retention = 14 days
   Maximum Volume Jobs = 1
   Maximum Volumes = 16
   Label Format = “${Pool}-${JobId}-vol“
}

Chcesz ustawić dłuższy czas retencji dla pewnego klienta? Zmień parametry Volume Retention i Maximum Volumes, wykonaj przeładowanie z konsoli bconsole i sprawa załatwiona.

Utrzymywanie przez nasz relacji „jedno-zadanie-na-wolumen” ma kilka zalet względem podejścia „jeden-wolumen-na-klienta”; w przypadku awarii łatwiej jest wtedy wykorzystać polecenia Baculi bscan i bextract. Testy porównawcze ewidentnie wykazały też krótsze czasy zarówno wykonania operacji backupu jak i operacji odzyskania dla modelu który wybraliśmy.

Storage {
   Name = %CLIENT_IP%
   Address = sd03.xxxxxx.dk
   SDPort = 9103
   Password = “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx“
   Device = %CLIENT_IP%
   Media Type = %CLIENT_IP%
}

Jak wspomniałem wcześniej mamy model jedno urządzenie na jednego klienta. Były dyskusje dotyczące tego podejścia, jednak więcej niż 6 miesięcy wykorzystania produkcyjnego oraz ogrom testów nie wykazały żadnych problemów. Testy wydajnościowe pokazały jasno, że uruchomienie 100 konkurencyjnych zadań na 100 osobnych urządzeniach jest wydajniejsze niż uruchomienie 100 zadań na na jednym lub kilku współdzielonych urządzeniach. Jedyną niedogodnością tego podejścia jest konieczność dodania konfiguracji urządzenia do naszych Serwerów Składowania (Storage Daemons), ale to jest również proste poprzez zautomatyzowany sposób wypełniania szablonu.

Firma Bac­ula Systems bardzo nam pomogła przy wypracowaniu szczegółów naszej konfiguracji, wyrazy uznania dla Arno i Kerna :)

To już wszystko odnośnie konfiguracji Baculi. Najbliższy artykuł będzie dotyczył monitorowania oraz integracji Baculi ze środowiskiem w naszej firmie. Kolejny zaś, omówi brakujące części naszej układanki.

źródło: https://myunix.dk/2010/12/12/large-scale-disk-to-disk-backups-using-bacula-part-iv/

¹⁾ dopisek tłumacza