Dalszy ciąg opisu rozszeszenia do oprogramowania Bacula umożliwiającego pełne wykonywanie kopii zapasowych bazy danych PostgreSQL w trybie on-line z wykorzystaniem PITR. Rozszerzenie - plugin - jest już na końcowym etapie testów i poprawiania napotkanych błędów. Lada moment powinna być dostępna wersja finalna.

Rozszerzenie składa się z trzech plików wykonywalnych (dwa programy narzędziowe i jeden plik pluginu) oraz przykładowego pliku konfiguracyjnego wykorzystywanego zarówno przez programy narzędziowe jak i plugin. Dodatkowo do poprawnego działania programów narzędziowych jak i samego pluginu wymagana jest biblioteka kliencka libpq. Plik konfiguracyjny składa się z serii parametrów konfiguracyjnych opisanych jako "parametr" = "wartość" po jednym parametrze w każdym wierszu. Znak '#' oznacza początek komentarza. Dowolne spacje występujące w nazwach parametrów lub komentarzach są usuwane za wyjątkiem wartości opisanych pomiędzy znakami cudzysłowów ("). Przykładowy plik konfiguracyjny:

#
# Config file for pgsql plugin
#
PGDATA = <pg.data.cluster.path>
PGHOST = <path.to.sockets.directory>
PGPORT = <socket.'port'>
CATDB = <catalog.db.name>
CATDBHOST = <catalog.db.host>
CATDBPORT = <catalog.db.port>
CATUSER = <catalog.db.user>
CATPASSWD = <catalog.db.password>
ARCHDEST = <destination.of.archived.wal's.path>
ARCHCLIENT = <name.of.archived.client>
DIRNAME = <director.name>
DIRHOST = <director.address>
DIRPORT = <director.service.port>
DIRPASSWD = <director.connection.password>

Poszczególne parametry definiują lokalizację produkcyjnej bazy danych (PGDATA, PGHOST, PGPORT), bazy katalogowej (CATDB, CATDBHOST, CATDBPORT, CATUSER, CATPASSWD), lokalizacji dla plików archiwalnych WAL (ARCHDEST, ARCHCLIENT) oraz namiary na Bacula Director (DIRNAME, DIRHOST, DIRPORT, DIRPASSWD) które wykorzystywane są podczas procesu odtwarzania bazy danych. Parametry definiujące lokalizację produkcyjnej bazy danych powinny umożliwiać administracyjne podłączenie pluginu do instancji bazy danych w celu wykonania procedur  zprzełączenia bazodanowych logów transakcyjnych oraz procedur backupowych. Baza katalogowa w tym przypadku to dowolna baza danych PostgreSQL inna od bazy produkcyjnej w której przechowywane są informacje dotyczące wykonywania backupów bazy danych i logów transakcyjnych.

Instalacja pluginu ogranicza się do wgrania plików wykonywalnych i konfiguracyjnych do odpowiednich miejsc danej instancji środowiska Bacula Enterprise lub Bacula Community. Plik wtyczki o nazwie pgsql-fd.so wgrywamy do katalogu zdefiniowanego w sekcji FileDaemon jako lokalizacja pluginów za pomocą dyrektywy:

	Plugin Directory = <plugin.directory>

Załadowanie pluginu nastąpi automatycznie po zrestartowaniu File Daemona co zostanie odnotowane poprzez stosowny komunikat uruchomieniowy.

Przystępujemy teraz do konfiguracji backupowanych zasobów. W tym celu definiujemy sekcje Fileset w konfiguracji Directora zgodnie z poniższym schematem. Pierwszy zestaw przeznaczony jest do wykonywania backupów logów transakcyjnych (WAL), drugi do backupu plików bazodanowych.

Fileset {
  Name = "pgsql-archset"
       Include {
          Plugin = "pgsql:/config.directory/pgsql.conf:wal"
       }
}

Fileset {
  Name = "pgsql-dbset"
       Include {
          Plugin = "pgsql:/config.directory/pgsql.conf:db"
       }
}

Oba zestawy wykorzystują wspomniany wcześniej plik konfiguracyjny pgsql.conf przekazywany jako drugi parametr dyrektywy Plugin. Jako ostatni parametr tej dyrektywy wskazywany jest tryb działania pluginu. Dopuszczalne sa tutaj dwie możliwości: "wal" oraz "db". Powyższe definicje zestawów plików do backupu powinny pojawić się jako parametry zadań backupowych. Tutaj generalną zasadą powinno być częste wykonywanie zadań backupowych plików logów (WAL), np. co 1H, 2H lub 4H. Częstość wykonywania tych zadań zdefiniuje nam możliwy do osiągnięcia parametr RPO dla naszego środowiska.

Zanim uruchomimy nasze piewsze zadanie backupowe bazy danych powinniśmy także ją poprawnie skonfigurować do tych celów. Wymagane będzie uruchomienie archiwizacji plików logów, co realizuje się poprzez edycję parametrów bazy danych zgodnie z poniższym schematem:

# - Archiving -
archive_mode = on   # allows archiving to be done
                    # (change requires restart)
# command to use to archive a logfile segment
archive_command = 'pgsql-archlog -c pgsql.conf %f %p'

Program pgsql-archlog jest narzędziem współpracującym z naszym pluginem poprzez bazę katalogową. Program ten do swojej pracy wykorzystuje ten sam plik konfiguracyjny pgsql.conf co sama wtyczka. Do uruchomienia skonfigurowanego właśnie mechanizmu archiwizacji logów wymagany będzie restart bazy danych. Poprawnie działanie archiwizacji zaobserwujemy w logach z działania bazy danych poprzez wpisy typu:

2010-11-11 23:05:12 CET INFO:  pgsql-archlog:  WAL archiving successfull!

Z każdym takim wpisem lokalizacja wskazana w ARCHDEST powinna powiększać się o kolejne pliki WAL. To oznacza że powinniśmy rozpocząć cykliczne zadania backupowe plików logów transakcyjnych. Jak mamy już poprawnie uruchomione backupy logów możemy uruchomić backupy plików bazodanowych za pomocą pluginu. Po poprawnym wykonaniu zadań backupowych naszej bazy danych w bazie katalogowej Bacula powinny pojawić się następujące katalogi odzwierciedlające backupowaną bazę danych:

	Aby przywrócić, wprowadź wybrane identyfikatory JobId oddzielone przecinkami: 447
Wybrałeś następujące JobId: 447

Tworzenie drzewa katalogów dla JobId: 447 ...  ++++++++++++++++++++++++++++++++++++++++++++++++
681 plików wstawionych do drzewa.

You are now entering file selection mode where you add (mark) and
remove (unmark) files to be restored. No files are initially added, unless
you used the "all" keyword on the command line.
Enter "done" to leave this mode.

cwd is: /
$ ls
pgsqldb:radekk-test/
pgsqltbs:radekk-test/
$

O tym w jaki sposób będziemy odtwarzać naszą bazę danych opiszę następnym razem.