W tym artykule przejdziesz przez pełny proces tworzenia i odzyskiwania danych w PostgreSQL: od pg_dump i pg_restore, przez pg_basebackup i archiwizację WAL, aż po odtwarzanie punktu w czasie (PITR). Zrozumiesz różnicę między backupem logicznym i fizycznym, jak dobrać strategię pod RPO/RTO i jak automatyzować całość, żeby nie skończyć na improwizowanym restore o trzeciej w nocy.

Backup i odzyskiwanie danych w PostgreSQL

Dlaczego backup to nie opcja, tylko obowiązek

Awaria dysku, błąd człowieka, skrypt DDL w złym środowisku, ransomware – to codzienność. Backup PostgreSQL ogranicza skutki zdarzeń i pozwala osiągnąć docelowe RPO/RTO. RPO definiuje maksymalną akceptowalną utratę danych (np. 5 minut), a RTO – czas odtwarzania (np. 30 minut). Te liczby wyznaczają dobór narzędzi i częstotliwość kopii.

Kopie zapasowe PostgreSQL występują w dwóch głównych formach: logiczne (pg_dump/pg_restore) i fizyczne (pg_basebackup + archiwizacja WAL dla PITR PostgreSQL). Logiczne są proste i przenośne, fizyczne dają punkt przywracania w czasie oraz krótsze RTO przy dużych zbiorach. Niezależnie od metody, realną gwarancją są tylko regularne testy przywracania.

Jeśli zaczynasz z PostgreSQL, najpierw poprawnie zainstaluj i skonfiguruj serwer, a dopiero potem projektuj backupy: PostgreSQL: wprowadzenie, instalacja i pierwsza baza danych.

Narzędzia pg_dump i pg_restore

pg_dump tworzy logiczną kopię jednej bazy. Formaty: plain SQL (łatwy do odtworzenia psql), custom -Fc i directory -Fd (kompresja, selektywne odtwarzanie, równoległość). pg_dump nie zapisuje WAL, nie umożliwia przyrostów; każdy dump jest pełny. Globalne obiekty (role, tablespace) zabezpiecz pg_dumpall -g.

pg_restore służy do odtwarzania formatów -Fc/-Fd. Pozwala filtrować obiekty, używać -j do równoległego odtwarzania i wymuszać kolejność. W scenariuszach CI/CD -Fc/-Fd przyspiesza odtwarzanie względem plain SQL. Dla bezpieczeństwa odtwarzaj na pustej bazie z odpowiednimi właścicielami i schematami.

Pamiętaj o rolach i uprawnieniach. Przy odtwarzaniu brakująca rola zablokuje proces, dlatego zabezpieczaj i odtwarzaj też globalne metadane: Użytkownicy, role i uprawnienia w PostgreSQL.

Tworzenie pełnej i przyrostowej kopii bazy

Pełny backup logiczny: okresowo uruchamiaj pg_dump -Fc dla każdej krytycznej bazy i przechowuj kopie poza hostem. Dla dużych baz używaj -Fd z -j, aby skrócić czas. To proste w użyciu i dobre do migracji między wersjami.

Pełny backup fizyczny: pg_basebackup tworzy spójny obraz całego klastra (wszystkie bazy) i może dołączyć WAL (-X stream). W połączeniu z archiwizacją WAL uzyskujesz PITR PostgreSQL, czyli możliwość odtwarzania do wybranego punktu w czasie. PostgreSQL nie ma natywnego „przyrostowego dumpa”; przyrost realizuje się przez ciągłe archiwizowanie WAL. Warto użyć slotu replikacji, by kontrolować retencję WAL.

SQL
Kopiuj
1
2
-- Zapewnij utrzymanie WAL dla archiwizacji/backupów fizycznych:
SELECT pg_create_physical_replication_slot('bkp_slot');

Automatyzacja kopii zapasowych

Harmonogram backupów dostosuj do RPO/RTO: np. pg_dump -Fc co noc, pg_basebackup co tydzień, a WAL archiwizuj ciągle (archive_mode=on, archive_command). W cronie typowo: pełny dump o 02:00, czyszczenie retencji co noc, weryfikacja checksum i raport z wielkości kopii. Trzymaj kopie w niezależnej lokalizacji (offsite/obiektowe storage).

Monitoruj strumień WAL (wielkość, opóźnienia), wolne miejsce i sukces archiwizacji. Po zakończeniu dumpa warto wymusić rotację WAL, aby nie czekać na naturalny rollover i mieć spójny punkt przywracania.

SQL
Kopiuj
1
2
-- Wymuś rotację WAL po wykonaniu dumpa (ułatwia archiwizację):
SELECT pg_switch_wal();

Odtwarzanie danych i testy przywracania

Odtwarzanie danych PostgreSQL z pg_dump: utwórz rolę właściciela, stwórz pustą bazę, odtwórz pg_restore -C/-d postgres lub -d nowa_baza. Weryfikuj logi na błędy DDL/ACL. Dla formatów -Fd użyj -j, aby skrócić RTO. Po odtworzeniu uruchom sanity checks (liczebności, sumy kontrolne aplikacyjne).

PITR PostgreSQL: zatrzymaj usługę, przywróć katalog z base backupu, skonfiguruj restore_command do pobierania WAL, utwórz recovery.signal i ustaw recovery_target_time lub recovery_target_lsn (w postgresql.conf/auto.conf). Uruchom serwer i obserwuj replay WAL. Gdy osiągnie punkt przywracania, serwer przejdzie do trybu produkcyjnego. Regularnie ćwicz odtwarzanie na środowisku testowym, mierz RTO i weryfikuj, że osiągasz wymagane RPO.

SQL
Kopiuj
1
2
3
-- Weryfikacja statusu po starcie instancji testowej:
SELECT pg_is_in_recovery()    AS in_recovery,
       pg_last_wal_replay_lsn() AS last_replay_lsn;

Jeśli Twoje transakcje mają specyficzne wymagania spójności, rozumienie izolacji pomoże interpretować stan po odtworzeniu: Transakcje i poziomy izolacji w SQL.

Strategie backupu w środowisku produkcyjnym

Dla większości systemów łącz logikę i fizykę: codzienny pg_dump -Fc (łatwa migracja, szybkie odtwarzanie pojedynczych obiektów) + ciągła archiwizacja WAL i okresowy pg_basebackup pod PITR. Replikacja strumieniowa z hot standby obniża RTO dla awarii węzła, ale nie zastępuje kopii zapasowych (propaguje błędy logiczne). Zdefiniuj retencję kopii i WAL na podstawie regulacji i kosztów przechowywania.

Projektuj pod RPO/RTO, stosuj zasadę 3-2-1, szyfruj kopie (na poziomie narzędzia, storage lub systemu plików) i regularnie testuj przywracanie. Przy dużych wolumenach i partycjach rozważ selektywne dumpy po schematach/tabelach oraz backup fizyczny na poziomie klastra; więcej o podziale danych: Partycjonowanie i sharding w PostgreSQL: podstawy.