Zimny backup i przenoszenie klastra na inny serwer

PostgreSQL

Zimny backup i przenoszenie klastra na inny serwer

W skrócie

Zimny backup (offline, cold backup) to najprostsza metoda kopii zapasowej PostgreSQL: zatrzymujemy serwer i kopiujemy pliki. Brzmi banalnie, ale właśnie na tej banalności najłatwiej się przewrócić - kopiując katalog przy działającym serwerze albo przenosząc go na binaria w innej wersji. Pokażemy, jak zrobić to poprawnie i jak bezpiecznie przenieść cały klaster na inną maszynę.

Jak to wygląda w praktyce

Najczęstszy scenariusz: skopiowałeś katalog danych zwykłym cp -r na działającej bazie, przeniosłeś go na nowy serwer i przy starcie dostajesz błędy o niespójnym stanie WAL, komunikat o "database files are incompatible with server" albo baza wstaje, ale brakuje w niej ostatnich transakcji. Inny wariant: skopiowałeś dane, ale serwer nie chce wystartować, bo katalog należy do innego użytkownika niż lokalny postgres, albo tablespace'y wskazują na ścieżki, których na nowej maszynie nie ma. Zdarza się też, że przeniosłeś dane z PostgreSQL 15 na binaria PostgreSQL 16 i dostajesz odmowę startu, bo format katalogu danych zmienia się między wersjami głównymi.

Dlaczego tak się dzieje

PostgreSQL trzyma dane w plikach, które przy działającym serwerze są nieustannie modyfikowane, a część zmian siedzi jeszcze w buforach w pamięci i w plikach WAL, a nie w plikach tabel. Kopia zrobiona w locie łapie te pliki w różnych momentach, więc dostajesz niespójny obraz, którego serwer nie potrafi bezpiecznie odtworzyć. Dlatego zimny backup wymaga zatrzymanego serwera - dopiero wtedy wszystko jest zrzucone na dysk i spójne. Do tego format wewnętrzny katalogu danych jest przypisany do konkretnej wersji głównej i do architektury. Kopia jeden do jednego działa tylko między tą samą wersją główną (np. 16.x do 16.x) i tą samą architekturą oraz tą samą wielkością bloku. Między wersjami głównymi trzeba użyć pg_upgrade albo logicznego zrzutu, a nie zwykłej kopii plików.

Jak to rozwiązać krok po kroku

1. Sprawdź wersję na obu maszynach: postgres --version (albo pg_config --version). Muszą się zgadzać co do wersji głównej i mieć tę samą architekturę.
2. Zatrzymaj serwer na źródle w sposób kontrolowany: pg_ctl -D /ścieżka/do/data stop -m fast albo przez menedżer usług systemu. Upewnij się, że proces faktycznie zniknął.
3. Zlokalizuj katalog danych (SHOW data_directory; przed zatrzymaniem) oraz wszystkie tablespace'y (zapytaj katalog pg_tablespace lub obejrzyj dowiązania w podkatalogu pg_tblspc). Musisz przenieść też dane tablespace'ów spoza głównego katalogu.
4. Skopiuj cały katalog danych, zachowując uprawnienia i dowiązania, np. tar z zachowaniem atrybutów albo rsync -a. Skopiuj także katalogi tablespace'ów na te same ścieżki na nowej maszynie.
5. Na nowej maszynie ustaw właściciela na użytkownika, pod którym działa PostgreSQL: chown -R postgres:postgres /ścieżka/do/data oraz uprawnienia katalogu danych na 0700 (albo 0750), inaczej serwer odmówi startu.
6. Przejrzyj postgresql.conf i pg_hba.conf pod kątem ścieżek i adresów specyficznych dla starej maszyny. Jeśli tablespace'y muszą trafić w inne miejsce, popraw dowiązania w pg_tblspc.
7. Wystartuj serwer i obserwuj log. Przy zimnym backupie z zatrzymanego serwera odtwarzanie WAL nie jest potrzebne, bo stan był już spójny.

Jak sprawdzić, że zadziałało

Po starcie zajrzyj do logu serwera - powinien pojawić się komunikat o gotowości do przyjmowania połączeń, bez ostrzeżeń o niespójności. Połącz się i sprawdź stan: SELECT pg_is_in_recovery(); powinno zwrócić false dla samodzielnego klastra. Policz kluczowe tabele i porównaj liczby z oryginałem, żeby mieć pewność, że dane są komplet. Sprawdź też, czy tablespace'y są widoczne i zdrowe: \db+ w psql pokaże listę wraz z lokalizacjami. Jeśli wszystko odpowiada źródłu, przeniesienie klastra się udało.

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