pg_dump vs pg_dumpall - co wybrać i czym się różnią

PostgreSQL

pg_dump vs pg_dumpall - co wybrać i czym się różnią

W skrócie

To pytanie pada za każdym razem, gdy ktoś pierwszy raz konfiguruje backup PostgreSQL. Wyjaśnimy Ci dokładnie, co każde z narzędzi obejmuje, a czego nie, i podamy sprawdzony schemat, który nie zostawi Cię bez ról po odtworzeniu.

Jak to wygląda w praktyce

Typowy scenariusz: ktoś zrobił backup przez pg_dump, odtworzył bazę na nowym serwerze i nagle okazuje się, że nie ma użytkowników, nie ma haseł, a GRANT-y wskazują na role, które nie istnieją - odtwarzanie sypie błędami "role does not exist". Odwrotnie bywa też, że ktoś użył pg_dumpall na ogromnym klastrze i dostał jeden gigantyczny plik SQL, którego nie da się wygodnie skompresować ani odtworzyć wybiórczo. Oba problemy wynikają z niezrozumienia zakresu narzędzi. Dobrze dobrany schemat backupu rozwiązuje je raz na zawsze.

Dlaczego tak się dzieje

W PostgreSQL część obiektów jest globalna dla całego klastra: role (użytkownicy i grupy), hasła, przestrzenie tabel i uprawnienia na poziomie klastra. Reszta - schematy, tabele, dane, funkcje - należy do konkretnej bazy. pg_dump działa na jednej bazie i celowo nie zrzuca obiektów globalnych, bo nie jest to jego zadanie. pg_dumpall ogarnia cały klaster naraz i jako jedyny potrafi zrzucić role, ale ma ograniczenie: produkuje wyłącznie zwykły skrypt SQL, bez formatu custom, bez wbudowanej kompresji i bez selektywnego odtwarzania. Dlatego samo pg_dump gubi role, a samo pg_dumpall jest niewygodne przy większych i wielobazowych instalacjach.

Jak to rozwiązać krok po kroku

1. Zrzuć obiekty globalne (role, hasła, tablespace) osobno: pg_dumpall --globals-only -f globalne.sql. To ten plik odtwarza użytkowników i uprawnienia na nowym serwerze.
2. Zrzuć każdą bazę z osobna formatem custom, który daje kompresję i elastyczne odtwarzanie: pg_dump -Fc -f baza.dump nazwa_bazy. Format -Fc pozwala potem odtwarzać wybrane obiekty i zrównoleglać przywracanie.
3. Przy odtwarzaniu najpierw wgraj role: psql -f globalne.sql na docelowym klastrze. Dzięki temu GRANT-y w dumpie bazy będą miały do czego się odwołać.
4. Odtwórz bazę z pliku custom narzędziem pg_restore: pg_restore -d nazwa_bazy baza.dump. Dla dużych baz dodaj zrównoleglenie: -j 4 (cztery wątki).
5. Jeśli świadomie chcesz zrzucić WSZYSTKO jednym poleceniem (mały klaster, prosta migracja), użyj po prostu pg_dumpall -f caly_klaster.sql - dostaniesz role i wszystkie bazy w jednym skrypcie, który odtworzysz przez psql -f caly_klaster.sql.
6. Wybierz świadomie: wiele baz, duże rozmiary, potrzeba kompresji i selektywnego restore - schemat globals-only + pg_dump -Fc per baza. Jeden mały klaster, migracja "wszystko na raz" - samo pg_dumpall.
7. Zadbaj o spójność: uruchamiaj backup rolą z prawem odczytu wszystkich obiektów (zwykle superuser), a plik z hasłami traktuj jak dane wrażliwe.

Jak sprawdzić, że zadziałało

Najlepszy test to odtworzenie backupu na czystej instancji i porównanie. Po wgraniu globalne.sql sprawdź, czy role są na miejscu: SELECT rolname FROM pg_roles ORDER BY 1; - lista powinna zgadzać się z serwerem źródłowym. Po pg_restore policz obiekty w bazie: liczbę tabel (SELECT count(*) FROM information_schema.tables WHERE table_schema NOT IN ('pg_catalog','information_schema');) i porównaj z oryginałem. Zerknij do logu odtwarzania - nie powinno tam być błędów "role does not exist". Jeśli takie się pojawiają, to znak, że pominąłeś krok z --globals-only i role trzeba wgrać przed dumpem bazy.

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