Jak backupować tylko wybrane tabele lub schemat

PostgreSQL

Jak backupować tylko wybrane tabele lub schemat

W skrócie

Nie zawsze trzeba backupować wszystko. Przy migracji pojedynczej tabeli, kopii schematu na test albo szybkim zabezpieczeniu przed ryzykowną zmianą, selektywny pg_dump jest szybki i wygodny. Pokażemy Ci, jak precyzyjnie wybrać, co ma trafić do kopii.

Jak to wygląda w praktyce

Masz bazę na kilkadziesiąt czy kilkaset gigabajtów, a przed ryzykownym ALTER albo migracją danych chcesz zabezpieczyć tylko jedną tabelę - albo skopiować schemat raporty na środowisko testowe. Robienie pełnego dumpa całej bazy byłoby marnotrawstwem: trwa długo, zajmuje mnóstwo miejsca i zawiera dane, których w ogóle nie potrzebujesz. Bywa też odwrotnie - chcesz zrzucić prawie wszystko, ale pominąć jedną gigantyczną tabelę z logami. W obu przypadkach potrzebujesz precyzyjnego wyboru zakresu, a nie kopii "wszystkiego albo niczego".

Dlaczego tak się dzieje

pg_dump domyślnie zrzuca wszystkie obiekty z danej bazy, bo taki jest jego bezpieczny domyślny cel - kompletna kopia. Twórcy narzędzia przewidzieli jednak selektywność i dodali przełączniki filtrujące: -t (tylko wskazane tabele), -n (tylko wskazane schematy) oraz ich odpowiedniki wykluczające -T i -N. Wzorce wspierają znaki wieloznaczne, więc można zrzucić np. wszystkie tabele o nazwie zaczynającej się od arch_. Ważne, by rozumieć jedną pułapkę: zrzut samej tabelki z -t nie musi zawierać obiektów, od których ta tabela zależy (typów, sekwencji spoza tej tabeli, kluczy obcych do innych tabel) - dlatego selektywny backup świetnie nadaje się do przenoszenia danych, ale nie zawsze jest samowystarczalny do pełnego odtworzenia w izolacji.

Jak to rozwiązać krok po kroku

1. Zrzuć jedną tabelę: pg_dump -Fc -t public.klienci -f klienci.dump nazwa_bazy. Podawaj nazwę ze schematem (schemat.tabela), żeby uniknąć niejednoznaczności.
2. Zrzuć kilka tabel naraz - powtórz przełącznik: pg_dump -Fc -t public.klienci -t public.zamowienia -f wybrane.dump nazwa_bazy. Możesz też użyć wzorca, np. -t 'public.arch_*'.
3. Zrzuć cały schemat: pg_dump -Fc -n raporty -f raporty.dump nazwa_bazy. To weźmie wszystkie tabele, widoki i funkcje z tego schematu.
4. Wyklucz to, czego nie chcesz. Cała baza bez ciężkiej tabeli logów: pg_dump -Fc -T public.logi -f bez_logow.dump nazwa_bazy. Analogicznie -N pomija wskazany schemat.
5. Sam schemat bez danych (przydatne do testów struktury): dodaj --schema-only. Same dane bez definicji: --data-only. Łącz to swobodnie z -t i -n.
6. Odtwórz wybiórczo z pliku custom: pg_restore -d docelowa klienci.dump. Jeśli tabela zależy od obiektów spoza dumpa (np. klucz obcy), zadbaj, by istniały na docelowym serwerze przed odtworzeniem, albo odtwarzaj po strukturze nadrzędnej.
7. Pamiętaj o zależnościach: jeśli selektywny backup ma służyć do pełnego odtworzenia gdzie indziej, dorzuć potrzebne schematy i tabele nadrzędne, żeby więzy integralności miały do czego się odwołać.

Jak sprawdzić, że zadziałało

Najszybszy dowód, że backup zawiera dokładnie to, co chciałeś, daje podgląd zawartości dumpa custom: pg_restore -l plik.dump wypisze listę obiektów w kopii - sprawdź, czy są tam tylko wybrane tabele lub schematy i nic więcej. Po odtworzeniu na docelowej bazie policz rekordy w przeniesionej tabeli (SELECT count(*) FROM ...) i porównaj z oryginałem, a przy schemacie zweryfikuj liczbę tabel (\dt raporty.* w psql). Jeśli odtwarzanie zgłasza brak obiektu nadrzędnego lub roli, to znak, że selektywny dump nie zawierał zależności - dorzuć je do zakresu albo wgraj wcześniej ręcznie.

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