Blog JSystems - uwalniamy wiedzę!
Blog JSystems - uwalniamy wiedzę!
PostgreSQL
Barman - centralny backup i recovery dla PostgreSQL
pg_dump nie dają odtwarzania do punktu w czasie ani centralnego zarządzania kopiami wielu serwerów.Gdy baz przybywa, a wymagania dotyczące utraty danych rosną, ręczne skrypty przestają wystarczać. Barman (Backup and Recovery Manager) to sprawdzone narzędzie open source od firmy EnterpriseDB, które centralizuje backupy PostgreSQL i daje odtwarzanie do punktu w czasie. Pokażemy, kiedy warto po nie sięgnąć i jak wygląda pełny cykl.
Masz kilka serwerów PostgreSQL, a backup każdego to osobny skrypt w cronie z pg_dump. Nikt nie wie na pewno, czy wszystkie kopie się wykonały i czy da się je odtworzyć. Gdy ktoś przez pomyłkę usuwa dane o 14:30, okazuje się, że najnowszy backup jest z nocy - tracisz pół dnia pracy, bo dump nie pozwala cofnąć się do 14:29. Do tego brakuje jednego miejsca, w którym widać stan wszystkich kopii, ich rozmiar i retencję. Zarządzanie tym rozłazi się w szwach.
Backup logiczny przez pg_dump to zdjęcie bazy z jednej chwili. Nie ma w nim ciągłego strumienia zmian, więc nie da się odtworzyć stanu między dwoma dumpami. Odtwarzanie do punktu w czasie (PITR) wymaga dwóch rzeczy naraz: kopii bazowej całego katalogu danych oraz archiwum wszystkich segmentów WAL powstałych po tej kopii. Mając jedno i drugie, można odtworzyć kopię bazową, a potem odtwarzać WAL aż do wskazanej minuty.
Barman automatyzuje dokładnie ten schemat. Wykonuje fizyczną kopię bazową (przez pg_basebackup albo rsync), na bieżąco odbiera i przechowuje segmenty WAL z monitorowanych serwerów, pilnuje retencji i weryfikuje spójność kopii. Wszystko z jednego, dedykowanego hosta backupowego, co odciąża serwery bazodanowe i daje jeden punkt kontroli.
barman. To on będzie łączył się do serwerów PostgreSQL i przechowywał kopie, więc daj mu odpowiednio dużo miejsca na dysku.REPLICATION oraz rolę monitorującą. Barman potrzebuje połączenia do bazy oraz kanału do pobierania WAL.streaming z pg_basebackup i strumieniowaniem WAL przez pg_receivewal, bo nie wymaga dostępu SSH do plików.barman check nazwa_serwera. Narzędzie samo zweryfikuje połączenie, uprawnienia i odbiór WAL, wypisując dla każdej pozycji OK lub FAILED z opisem.barman backup nazwa_serwera. Od tej chwili Barman równolegle archiwizuje WAL, więc masz komplet do PITR.barman cron oraz cykliczne barman backup. Retencję ustaw parametrem retention_policy, na przykład na ostatnie 7 dni.barman recover z opcją --target-time odtworzy bazę na wskazany serwer do konkretnej minuty. Odtwarzanie testuj na maszynie zapasowej, nigdy na produkcji.Stan wszystkich kopii podejrzysz poleceniem barman list-backup nazwa_serwera - zobaczysz identyfikatory backupów, ich daty i rozmiary. Kluczowa jest komenda barman check nazwa_serwera: dopóki wszystkie pozycje, w tym WAL archive i backup maximum age, pokazują OK, wiesz że kopie powstają i WAL jest odbierany na bieżąco. Ciągłość archiwum WAL potwierdza barman show-backup, gdzie widać zakres segmentów pokrytych daną kopią. Ostatecznym dowodem jest realne odtworzenie do punktu w czasie na maszynie testowej i sprawdzenie, że dane wyglądają jak w wybranej minucie - dopiero przetestowane odtwarzanie oznacza, że backup naprawdę chroni.
Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL
To szkolenie może być dofinansowane z KFS lub BUR.
★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)
To szkolenie może być dofinansowane z KFS lub BUR.
★★★★★Średnia ocena naszych szkoleń w Google: 5/5
Komentarze (0)
Brak komentarzy...