Blog JSystems - uwalniamy wiedzę!

Szukaj

PostgreSQL

pgBackRest - backup i odtwarzanie klasy enterprise

W skrócie

  • Skrypty z 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ł.
  • Domowe rozwiązania nie mają kopii przyrostowych, weryfikacji sum kontrolnych, równoległości ani prostego odtwarzania do punktu w czasie, więc przy realnej awarii okazuje się, że backup jest bezużyteczny.
  • Wdróż pgBackRest: skonfiguruj repozytorium i archiwizację WAL, rób pełne oraz przyrostowe i różnicowe kopie, i regularnie testuj odtwarzanie, w tym do wskazanego momentu.

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ć.

Jak to wygląda w praktyce

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.

Dlaczego tak się dzieje

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.

Jak to rozwiązać krok po kroku

  1. Zainstaluj pgBackRest z pakietów repozytorium PGDG i przygotuj miejsce na repozytorium kopii (osobny dysk lub przestrzeń zdalna). Trzymanie kopii na tym samym dysku co dane mija się z celem.
  2. Utwórz plik /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.
  3. Włącz archiwizację WAL w postgresql.conf: ustaw archive_mode = on i archive_command na wywołanie pgbackrest --stanza=twoja archive-push %p, po czym przeładuj konfigurację.
  4. Zainicjuj stanzę poleceniem pgbackrest --stanza=twoja stanza-create i sprawdź poprawność środowiska przez pgbackrest --stanza=twoja check.
  5. Wykonaj pierwszą pełną kopię: pgbackrest --stanza=twoja --type=full backup. Kolejne rób jako różnicowe (--type=diff) lub przyrostowe (--type=incr), żeby oszczędzać czas i miejsce.
  6. Ustaw harmonogram (np. cron): rzadka pełna kopia, częstsze różnicowe i jeszcze częstsze przyrostowe, plus retencję pilnującą liczby trzymanych kopii.
  7. Przećwicz odtwarzanie na osobnej maszynie: 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.

Jak sprawdzić, że zadziałało

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

Szkolenie Administracja, replikacja i tuning baz danych 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

Szkolenie Zaawansowana administracja PostgreSQL - HA, DR, monitoring, skalowanie

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

Najczęściej zadawane pytania

Czym pgBackRest różni się od zwykłego pg_dump?
pg_dump robi logiczny zrzut zawartości bazy i świetnie nadaje się do mniejszych baz oraz przenoszenia danych między wersjami, ale nie ma kopii przyrostowych, archiwizacji WAL ani odtwarzania do punktu w czasie. pgBackRest to fizyczny backup klasy enterprise: robi pełne, różnicowe i przyrostowe kopie plików danych, przejmuje archiwizację WAL, liczy sumy kontrolne, działa równolegle i potrafi odtworzyć klaster do wskazanego momentu. Przy dużych, produkcyjnych bazach pgBackRest skaluje się znacznie lepiej.
Jaka jest różnica między kopią różnicową a przyrostową w pgBackRest?
Kopia różnicowa (typ diff) zawiera wszystkie zmiany od ostatniej pełnej kopii, więc rośnie z czasem, ale odtwarzanie wymaga tylko pełnej plus jednej różnicowej. Kopia przyrostowa (typ incr) zawiera zmiany od ostatniej dowolnej kopii, więc jest najmniejsza i najszybsza, ale odtwarzanie wymaga pełnej i całego łańcucha przyrostów. Typowa strategia to rzadka pełna kopia, częstsze różnicowe i najczęstsze przyrostowe, co równoważy czas backupu, zajętość miejsca i czas odtwarzania.
Czy pgBackRest potrafi odtworzyć bazę do konkretnego momentu w czasie?
Tak, pod warunkiem że działa archiwizacja WAL. pgBackRest przejmuje ją przez parametr archive_command wywołujący archive-push, dzięki czemu ma komplet segmentów WAL między kopiami. Przy odtwarzaniu wskazujesz typ odtwarzania po czasie i docelowy moment, a pgBackRest odtwarza bazową kopię i przewija WAL dokładnie do tego punktu. To pozwala cofnąć bazę tuż przed pomyłkową operacją, na przykład przypadkowym usunięciem danych.
Gdzie powinno leżeć repozytorium kopii pgBackRest?
Nie na tym samym dysku co katalog danych bazy. Trzymanie kopii obok danych mija się z celem, bo awaria dysku zabiera jednocześnie bazę i backup. Umieść repozytorium na osobnym dysku, a najlepiej na innym serwerze lub w przestrzeni zdalnej. pgBackRest wspiera repozytoria zdalne i kompresję, więc kopie można trzymać poza produkcyjną maszyną. Kluczowe jest też regularne testowanie odtwarzania na osobnym hoście, bo backup bez sprawdzonego restore nie istnieje.

Komentarze (0)

Musisz być zalogowany by móc dodać komentarz. Zaloguj się przez Google

Brak komentarzy...