Blog JSystems - uwalniamy wiedzę!
Blog JSystems - uwalniamy wiedzę!
PostgreSQL
pgBackRest - backup i odtwarzanie klasy enterprise
pg_dump i ręcznym kopiowaniem plików przestają wystarczać, gdy baza rośnie: pełny backup trwa godzinami, a odtwarzania nikt nigdy nie przetestował.pgBackRest to dojrzałe, otwarte narzędzie do backupu PostgreSQL, które ogarnia to, na czym własne skrypty się wykładają: kopie przyrostowe i różnicowe, równoległość, kompresję, weryfikację integralności i odtwarzanie do punktu w czasie. Pokażemy, jak myśleć o backupie klasy enterprise i jak go poprawnie uruchomić.
Objawy narastają wraz z bazą. Nocny pg_dump zaczyna nie mieścić się w oknie serwisowym i obciąża produkcję. Pełna kopia fizyczna zajmuje coraz więcej miejsca, bo trzymasz wiele pełnych zrzutów bez przyrostów. Nie masz jak odtworzyć bazy do stanu sprzed konkretnej pomyłkowej operacji, bo trzymasz tylko snapshot z północy. A gdy przychodzi realna awaria, okazuje się, że nikt nigdy nie sprawdził, czy backup w ogóle da się odtworzyć - i dopiero wtedy wychodzi, że pliki są niekompletne albo WAL-e nie były archiwizowane. To klasyczny moment, w którym administrator przechodzi na dedykowane narzędzie.
Backup PostgreSQL składa się z dwóch elementów: bazowej kopii plików danych oraz ciągu plików WAL, które pozwalają domknąć spójny stan i przewinąć bazę w czasie. Własne skrypty zwykle robią tylko pierwszą część, i to bez weryfikacji. Brakuje im archiwizacji WAL, więc odtworzenie do punktu w czasie jest niemożliwe. Brakuje sum kontrolnych, więc cicho zepsuty plik w kopii nie zostanie wykryty aż do awarii. Brakuje równoległości i przyrostów, więc kopie są wolne i zajmują masę miejsca. pgBackRest rozwiązuje to systemowo: przejmuje archiwizację WAL przez parametr archive_command, trzyma spójne repozytorium z pełnymi, różnicowymi i przyrostowymi kopiami, liczy sumy kontrolne i potrafi odtworzyć klaster do wskazanego czasu lub transakcji.
/etc/pgbackrest/pgbackrest.conf: zdefiniuj tzw. stanzę (nazwę klastra), ścieżkę do repozytorium, ścieżkę do katalogu danych oraz włącz kompresję i sensowną retencję pełnych kopii.postgresql.conf: ustaw archive_mode = on i archive_command na wywołanie pgbackrest --stanza=twoja archive-push %p, po czym przeładuj konfigurację.pgbackrest --stanza=twoja stanza-create i sprawdź poprawność środowiska przez pgbackrest --stanza=twoja check.pgbackrest --stanza=twoja --type=full backup. Kolejne rób jako różnicowe (--type=diff) lub przyrostowe (--type=incr), żeby oszczędzać czas i miejsce.pgbackrest --stanza=twoja restore, a dla punktu w czasie dodaj typ odtwarzania po czasie i docelowy moment. To najważniejszy krok - backup bez sprawdzonego restore nie istnieje.Sprawdź listę kopii i ich stan poleceniem pgbackrest --stanza=twoja info - zobaczysz typy kopii, ich rozmiar, zakres WAL i czasy. Regularnie uruchamiaj pgbackrest --stanza=twoja check, żeby potwierdzić, że archiwizacja WAL działa i repozytorium jest osiągalne. Najmocniejszy dowód to pełne odtworzenie na maszynie testowej: po restore wystartuj serwer, poczekaj aż zakończy odtwarzanie WAL, a potem porównaj liczności kluczowych tabel z produkcją. Jeśli odtworzenie do punktu w czasie zatrzymuje się dokładnie tam, gdzie chcesz, i dane się zgadzają, backup działa naprawdę.
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...