InnoMarts logo
InnoMarts
Fast websites
← Back to course

Backup, restore i podstawowa konserwacja: ochrona danych PostgreSQL

Backup, restore i podstawowa konserwacja: ochrona danych PostgreSQL

Witaj z powrotem.

W poprzedniej lekcji nauczyłeś się, jak PostgreSQL łączy się z prawdziwymi aplikacjami.

Poznałeś:

Bardzo dobrze.

Teraz twoja baza danych może pracować z prawdziwymi aplikacjami.

To potężne.

Ale moc oznacza odpowiedzialność.

I czasem panikę.

Bo gdy aplikacja zaczyna przechowywać prawdziwe dane, jedno pytanie staje się bardzo ważne:

Co się stanie, jeśli coś pójdzie źle?

Tabela zostanie usunięta.

Serwer się zawiesi.

Zła migracja zostanie uruchomiona.

Programista wpisze DELETE bez WHERE.

Laptop umrze.

Dysk padnie.

Ktoś powie:

Zmieniłem tylko jedną małą rzecz.

Bardzo niebezpieczne zdanie.

Dzisiaj nauczymy się backupów, restore i podstawowej konserwacji.

To nie jest najbardziej glamour część baz danych.

Nikt nie otwiera kursu PostgreSQL i nie mówi:

Nie mogę się doczekać strategii backupów.

Ale backupy są nudne tylko do dnia, w którym ich potrzebujesz.

Wtedy stają się piękne.

Jak spadochron.

Mało ekscytujący podczas normalnego spaceru.

Bardzo ważny podczas spadania.

Czego się nauczysz

W tej lekcji nauczysz się:

Pod koniec tej lekcji zrozumiesz, jak chronić swoje dane PostgreSQL.

Bo tworzenie danych jest dobre.

Używanie danych jest przydatne.

Utrata danych buduje charakter.

Ale spróbujmy uniknąć zbyt dużego budowania charakteru.

Dlaczego backupy są ważne

Backup to kopia twojej bazy danych, której możesz użyć, jeśli coś pójdzie źle.

Prosta idea.

Bardzo ważna.

Bez backupów utrata danych może być trwała.

Przykłady problemów:

Ktoś przypadkowo usuwa wiersze.
Migracja psuje tabele.
Dysk serwera się psuje.
Baza danych zostaje uszkodzona.
Zły command usuwa tabelę.
Deploy idzie źle.
Baza produkcyjna zostaje nadpisana.

Niektóre z tych sytuacji brzmią dramatycznie.

Niektóre brzmią głupio.

W prawdziwym życiu zdarzają się obie.

Komputery zawodzą.

Ludzie zawodzą.

Programiści zawodzą kreatywnie.

Backup daje ci drogę powrotu.

To nie magia.

Ale to nadzieja w formie pliku.

Backup nie jest prawdziwy, dopóki restore nie działa

Bardzo ważna zasada:

Backup, którego nigdy nie testowałeś, jest tylko teorią.

Możesz mieć plik backupu.

Ale czy potrafisz go przywrócić?

Czy zawiera dane, których oczekujesz?

Czy jest kompletny?

Czy nie jest zbyt stary?

Czy wymaga hasła, którego zapomniałeś?

Czy przywraca się do działającej bazy danych?

Jeśli tego nie wiesz, nie masz naprawdę strategii backupu.

Masz talizman szczęścia.

A PostgreSQL nie jest pod wrażeniem talizmanów szczęścia.

Dlatego pamiętaj:

Backup to krok pierwszy.
Test restore to krok drugi.

Oba są ważne.

Przygotowanie bazy demo

Otwórz PostgreSQL:

sudo -iu postgres psql

Utwórz bazę demo:

CREATE DATABASE backup_demo_db;

Połącz się z nią:

\c backup_demo_db

Utwórz tabelę:

CREATE TABLE notes (
  id SERIAL PRIMARY KEY,
  title VARCHAR(150) NOT NULL,
  content TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Wstaw trochę danych:

INSERT INTO notes (title, content)
VALUES
  ('First Note', 'This is the first note.'),
  ('Backup Note', 'This row should survive backup and restore.'),
  ('PostgreSQL Note', 'Databases remember things. Sometimes too well.');

Sprawdź dane:

SELECT * FROM notes;

Teraz mamy małą bazę danych do backupu.

Nie są to bardzo ważne dane.

Ale dobre do praktyki.

Ćwicz na fałszywych danych.

Nie na produkcji.

Produkcja to nie plac zabaw.

Produkcja to miejsce, gdzie małe błędy noszą drogie buty.

Czym jest pg_dump?

pg_dump to narzędzie PostgreSQL, które tworzy backup bazy danych.

Może eksportować:

strukturę tabel
dane
indeksy
constrainty
sekwencje
obiekty bazy danych

Domyślnie nie robi backupu całego serwera PostgreSQL.

Robi backup jednej bazy danych.

Podstawowa idea:

pg_dump czyta bazę danych i zapisuje plik backupu.

pg_dump uruchamiasz z terminala.

Nie wewnątrz psql.

To ważne.

Wewnątrz psql piszesz komendy SQL.

W terminalu uruchamiasz narzędzia takie jak:

pg_dump
psql
createdb
dropdb
pg_restore

Różne miejsca.

Różne narzędzia.

Ta sama bazodanowa przygoda.

Tworzenie prostego backupu SQL

Najpierw wyjdź z psql:

\q

Teraz uruchom to z terminala:

pg_dump -U postgres -d backup_demo_db > backup_demo_db.sql

To tworzy plik:

backup_demo_db.sql

To jest prosty backup SQL.

Zawiera komendy SQL, które mogą odtworzyć strukturę i dane bazy.

Możesz go sprawdzić:

less backup_demo_db.sql

Możesz zobaczyć komendy typu:

CREATE TABLE
COPY
ALTER TABLE
CREATE SEQUENCE

Prosty backup SQL jest czytelny dla człowieka.

To miłe.

Można go przywrócić za pomocą psql.

Proste.

Przydatne.

Bardzo dobre dla początkujących.

Backup z hostem i portem

Czasem trzeba podać host i port:

pg_dump -h localhost -p 5432 -U postgres -d backup_demo_db > backup_demo_db.sql

To oznacza:

-h localhost       połącz się z localhost
-p 5432            użyj portu 5432
-U postgres        połącz się jako użytkownik postgres
-d backup_demo_db  zrób backup tej bazy

Jeśli używasz użytkownika aplikacyjnego, zamień postgres na tego użytkownika.

Przykład:

pg_dump -h localhost -p 5432 -U app_user -d app_db > app_db.sql

Użytkownik musi mieć prawo odczytu bazy danych.

PostgreSQL nie może zrobić backupu tego, czego użytkownik nie może zobaczyć.

Bardzo sprawiedliwe.

Bardzo surowe.

Bardzo PostgreSQL.

Przywracanie prostego backupu SQL

Teraz przywróćmy backup do nowej bazy danych.

Utwórz nową bazę:

createdb -U postgres backup_demo_restore_db

Teraz przywróć:

psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

To czyta plik SQL i wykonuje go w nowej bazie danych.

Teraz połącz się:

psql -U postgres -d backup_demo_restore_db

Sprawdź dane:

SELECT * FROM notes;

Powinieneś zobaczyć wiersze.

Dobrze.

Utworzyłeś backup.

Przywróciłeś go.

Przetestowałeś go.

To właściwa droga.

Backup bez testu restore to teatr pewności.

Test restore to rzeczywistość.

Rzeczywistość ma znaczenie.

Irytujące, ale prawdziwe.

Przykład DROP i restore

Zasymulujmy katastrofę.

Połącz się z przywróconą bazą:

psql -U postgres -d backup_demo_restore_db

Usuń tabelę:

DROP TABLE notes;

Teraz sprawdź:

SELECT * FROM notes;

PostgreSQL będzie narzekał:

relation "notes" does not exist

Bardzo smutne.

Bardzo edukacyjne.

Wyjdź:

\q

Przywróć ponownie:

psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Jeśli tabela już istnieje, możesz dostać błędy, chyba że backup zawiera komendy usuwania.

Dla czystszego ćwiczenia możesz odtworzyć bazę:

dropdb -U postgres backup_demo_restore_db
createdb -U postgres backup_demo_restore_db
psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Potem sprawdź ponownie:

psql -U postgres -d backup_demo_restore_db

SELECT * FROM notes;

Dane wróciły.

To jest magiczne uczucie backupów.

Nie prawdziwa magia.

Coś lepszego.

Przetestowana procedura.

Tworzenie backupu z --clean

Możesz stworzyć backup, który zawiera komendy usuwania istniejących obiektów przed ich ponownym utworzeniem.

Przykład:

pg_dump -U postgres --clean --if-exists -d backup_demo_db > backup_demo_clean.sql

Opcje:

--clean       dodaje komendy DROP
--if-exists   unika błędów, jeśli obiekty nie istnieją

To może ułatwić przywracanie na istniejącą bazę.

Ale uważaj.

Backup z komendami DROP może usuwać istniejące obiekty podczas restore.

Może właśnie tego chcesz.

Albo może to być sposób, w jaki twój dzień staje się bardzo ekscytujący.

Zawsze wiedz, co robi twój plik backupu.

Pliki SQL nie są dekoracją.

One się wykonują.

PostgreSQL słucha.

Wsparcie emocjonalne nie jest dołączone.

Backup w formacie custom

PostgreSQL obsługuje też backupy w formacie custom.

Utwórz taki backup:

pg_dump -U postgres -F c -d backup_demo_db -f backup_demo_db.dump

Tutaj:

-F c              format custom
-f nazwa_pliku    plik wyjściowy

To tworzy:

backup_demo_db.dump

Ten plik nie jest zwykłym czytelnym SQL-em.

Ale jest elastyczny.

Przywraca się go za pomocą pg_restore.

Format custom jest przydatny, bo możesz:

przywracać wybrane tabele
przywracać z większą liczbą opcji
używać równoległego restore w większych przypadkach
wyświetlać zawartość backupu

W wielu prawdziwych projektach format custom jest dobrym wyborem.

Mniej czytelny.

Bardziej potężny.

Jak skompresowana skrzynka narzędziowa dla bazy danych.

Przywracanie backupu custom

Utwórz nową bazę danych:

createdb -U postgres backup_demo_custom_restore_db

Przywróć za pomocą pg_restore:

pg_restore -U postgres -d backup_demo_custom_restore_db backup_demo_db.dump

Teraz połącz się:

psql -U postgres -d backup_demo_custom_restore_db

Sprawdź dane:

SELECT * FROM notes;

Powinieneś zobaczyć dane.

Dobrze.

Teraz znasz oba style:

prosty backup SQL -> restore przez psql
backup custom     -> restore przez pg_restore

Prosta zasada.

Bardzo przydatna.

Prosty SQL vs format custom

Prosty backup SQL:

pg_dump -U postgres -d backup_demo_db > backup_demo_db.sql

Restore:

psql -U postgres -d new_db < backup_demo_db.sql

Dobry do:

prostych backupów
nauki
plików czytelnych dla człowieka
małych baz danych
łatwego sprawdzania

Backup w formacie custom:

pg_dump -U postgres -F c -d backup_demo_db -f backup_demo_db.dump

Restore:

pg_restore -U postgres -d new_db backup_demo_db.dump

Dobry do:

większych baz danych
bardziej elastycznego restore
przywracania wybranych obiektów
workflow bliższego produkcji

Oba są przydatne.

Nie zamieniaj tego w wojnę religijną.

Bazy danych i tak mają wystarczająco dramatu.

Wyświetlanie zawartości backupu custom

Możesz sprawdzić backup custom:

pg_restore -l backup_demo_db.dump

To pokazuje, co znajduje się w backupie.

Możesz zobaczyć tabele, sekwencje, constrainty i sekcje danych.

To przydatne, jeśli chcesz zrozumieć, co zawiera backup.

Bo “mam nadzieję, że tam jest tabela” to nie strategia.

Sprawdź.

Zweryfikuj.

Potem śpij spokojniej.

Może.

Nazwy plików backupu

Używaj jasnych nazw plików.

Źle:

backup.sql
new_backup.sql
backup_final.sql
backup_final_REAL.sql
backup_please_work.sql

Dobrze:

backup_demo_db_2026-05-03.sql
shop_db_2026-05-03_22-30.dump
portfolio_db_before_migration_2026-05-03.dump

Uwzględnij:

nazwę bazy danych
datę
czas, jeśli przydatny
powód, jeśli przydatny

Przykład:

pg_dump -U postgres -F c -d shop_db -f shop_db_2026-05-03.dump

Dobre nazwy oszczędzają mózg.

Złe nazwy tworzą archeologię.

A nikt nie chce wykopywać plików backupu o 2 w nocy.

Kompresowanie prostego backupu SQL

Proste backupy SQL mogą być duże.

Możesz je skompresować:

pg_dump -U postgres -d backup_demo_db | gzip > backup_demo_db.sql.gz

Przywracanie skompresowanego backupu:

gunzip -c backup_demo_db.sql.gz | psql -U postgres -d backup_demo_restore_db

To przydatne do oszczędzania miejsca na dysku.

Ale pamiętaj:

Skompresowane pliki też trzeba testować.

Skompresowany zepsuty backup nadal jest zepsuty.

Tylko mniejszy.

Bardzo efektywny smutek.

Backup przed niebezpiecznymi zmianami

Przed ryzykownymi operacjami stwórz backup.

Przykłady ryzykownych operacji:

duża migracja
usuwanie kolumn
zmiana typów danych
masowy update
masowy delete
przebudowa schematu
deploy na produkcji
import danych zewnętrznych

Przykład backupu:

pg_dump -U postgres -F c -d shop_db -f shop_db_before_migration_2026-05-03.dump

Potem wykonaj niebezpieczną zmianę.

Jeśli coś pójdzie źle, masz punkt powrotu.

To profesjonalne.

To spokojne.

To sposób, żeby nie robić historii bazy danych w złym znaczeniu.

Niebezpieczny przykład DELETE

To jest niebezpieczne:

DELETE FROM customers;

Usuwa wszystkie wiersze z customers.

Może miałeś na myśli:

DELETE FROM customers
WHERE id = 5;

Mała różnica.

Ogromny rezultat.

Przed wykonywaniem niebezpiecznych komend używaj transakcji, kiedy to możliwe:

BEGIN;

Wykonaj komendę:

DELETE FROM customers
WHERE id = 5;

Sprawdź:

SELECT * FROM customers;

Jeśli jest dobrze:

COMMIT;

Jeśli jest źle:

ROLLBACK;

Transakcje mogą uratować cię przed niektórymi błędami.

Backupy mogą uratować cię przed większymi błędami.

Oba są przydatne.

Jak pasy bezpieczeństwa i poduszki powietrzne.

Nie wybieraj tylko jednego, bo czujesz się odważny.

Podstawowa strategia backupów

Prosta strategia backupu powinna odpowiadać na pytania:

Jak często robimy backup?
Gdzie przechowujemy backupy?
Jak długo je trzymamy?
Kto ma dostęp do backupów?
Jak robimy restore?
Czy testowaliśmy restore?

Dla małego projektu możesz robić:

backup codzienny
trzymać ostatnie 7 backupów dziennych
trzymać backup tygodniowy przez 1 miesiąc
przechowywać backupy poza serwerem
regularnie testować restore

Dla poważniejszych projektów potrzebny jest mocniejszy plan.

Ale nawet prosty przetestowany plan jest dużo lepszy niż:

Myślę, że provider serwera coś ma.

Może ma.

Może nie.

Może to kosztuje dodatkowo.

Może nigdy nie zostało włączone.

Może przywraca cały serwer, ale nie tę jedną bazę, której potrzebujesz.

Sprawdź.

Nie zakładaj.

Założenie jest kuzynem katastrofy.

Przechowywanie backupów w bezpiecznym miejscu

Jeśli baza danych i backup są na tym samym serwerze, a serwer padnie, możesz stracić oba.

Źle.

Lepsze miejsca na backupy:

inny serwer
zewnętrzny storage
bezpieczny cloud storage
szyfrowany storage backupów
kopia offline dla ważnych danych

Minimum to unikanie sytuacji, w której jedyny backup leży obok oryginalnej bazy.

To jak trzymanie zapasowego klucza do domu w płonącym domu.

Technicznie zapasowy.

Praktycznie niezbyt pomocny.

Ochrona plików backupu

Backupy zawierają dane.

Czasem dane wrażliwe.

To oznacza, że pliki backupu muszą być chronione.

Zasady:

nie wystawiaj backupów publicznie
ogranicz dostęp
używaj mocnych uprawnień
rozważ szyfrowanie
bezpiecznie usuwaj stare backupy
nie wysyłaj dumpów bazy mailem bezmyślnie

Backup bazy danych może być tak samo wrażliwy jak działająca baza.

Czasem bardziej.

Bo ludzie zapominają, że istnieje.

Atakujący nie zapominają.

Bardzo niegrzeczne z ich strony.

Ale prawdziwe.

Podstawowa konserwacja: VACUUM

PostgreSQL używa systemu, w którym zaktualizowane i usunięte wiersze zostawiają stare wersje wierszy.

To część sposobu, w jaki PostgreSQL obsługuje współbieżność.

Bardzo sprytne.

Ale oznacza to, że PostgreSQL potrzebuje sprzątania.

To sprzątanie nazywa się:

VACUUM

Uruchom:

VACUUM;

To czyści martwe wiersze w aktualnej bazie danych.

Większość instalacji PostgreSQL ma włączony autovacuum.

Autovacuum działa automatycznie.

Dobrze.

Bo ręczne pamiętanie o wszystkim to sposób, w jaki ludzie przegrywają.

Mimo to warto wiedzieć, co robi VACUUM.

Pomaga PostgreSQL utrzymywać tabele w dobrym stanie.

Jak sprzątanie warsztatu.

Nie glamour.

Bardzo potrzebne.

VACUUM ANALYZE

Możesz uruchomić:

VACUUM ANALYZE;

To robi dwie rzeczy:

VACUUM czyści martwe wersje wierszy.
ANALYZE aktualizuje statystyki planera.

Statystyki planera pomagają PostgreSQL wybierać dobre plany zapytań.

Jeśli statystyki są nieaktualne, PostgreSQL może podejmować złe decyzje.

Na przykład użyć złego indeksu.

Albo skanować za dużo.

Albo ogólnie zachowywać się jak zagubiony księgowy.

ANALYZE pomaga PostgreSQL lepiej rozumieć dane.

Baza z aktualnymi statystykami to szczęśliwsza baza.

Prawdopodobnie.

PostgreSQL się nie uśmiecha.

Ale wydajność może się poprawić.

Samo ANALYZE

Możesz uruchomić:

ANALYZE;

To aktualizuje statystyki bez vacuum.

Możesz też analizować jedną tabelę:

ANALYZE products;

To przydatne po dużych zmianach danych.

Przykład:

zaimportowano wiele wierszy
usunięto wiele wierszy
zaktualizowano wiele wierszy
zmienił się rozkład danych

PostgreSQL używa statystyk, żeby decydować, jak wykonać zapytania.

Złe statystyki mogą dawać złe plany.

Złe plany dają wolne zapytania.

Wolne zapytania dają smutnych programistów.

Łańcuch jest jasny.

REINDEX

Indeksy czasem mogą się rozrosnąć albo wymagać przebudowy.

PostgreSQL ma:

REINDEX

Przykład:

REINDEX DATABASE backup_demo_db;

Albo jeden indeks:

REINDEX INDEX index_name;

Albo jedną tabelę:

REINDEX TABLE table_name;

Nie uruchamiaj REINDEX losowo co pięć minut.

To nie mycie zębów.

Używaj go wtedy, gdy jest potrzebny.

Dla początkujących wystarczy wiedzieć:

REINDEX przebudowuje indeksy.

W prawdziwej konserwacji trzeba rozumieć, dlaczego to robisz.

Ślepa konserwacja nadal jest ślepa.

Nawet jeśli nosi poważny kapelusz.

Sprawdzanie rozmiaru bazy danych

Możesz sprawdzić rozmiar bazy danych:

SELECT pg_size_pretty(pg_database_size('backup_demo_db'));

Sprawdź rozmiary tabel:

SELECT
  relname AS table_name,
  pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

To pomaga zrozumieć, co zajmuje miejsce.

Czasem największa tabela jest oczekiwana.

Czasem to tabela logów, której nikt nie sprzątał przez trzy lata.

Bazy danych zbierają historię.

Czasem zbyt dużo historii.

Jak szuflada pełna starych kabli.

Sprawdzanie aktywnych połączeń

Możesz zobaczyć aktywne połączenia:

SELECT
  pid,
  usename,
  datname,
  state,
  query
FROM pg_stat_activity;

To pokazuje, kto jest połączony i co robi.

Przydatne do debugowania.

Może aplikacja ma za dużo połączeń.

Może zapytanie się zawiesiło.

Może ktoś otworzył psql i poszedł na obiad.

PostgreSQL wie.

PostgreSQL pamięta.

PostgreSQL ocenia w ciszy.

Znajdowanie wolnych zapytań

PostgreSQL może logować wolne zapytania, jeśli jest tak skonfigurowany.

Typowe ustawienie to:

log_min_duration_statement

Przykładowa idea:

loguj zapytania wolniejsze niż 1000 ms

Zwykle konfiguruje się to w plikach konfiguracyjnych PostgreSQL.

Dla początkujących ważna idea brzmi:

Wolne zapytania trzeba obserwować, a nie zgadywać.

Używaj narzędzi takich jak:

EXPLAIN ANALYZE
logi
monitoring
pg_stat_statements

pg_stat_statements to rozszerzenie, które pomaga śledzić wydajność zapytań.

To bardziej zaawansowane.

Ale dobrze wiedzieć, że istnieje.

Praca nad wydajnością bez obserwacji to astrologia baz danych.

A astrologii baz danych już nie ufamy.

Checklist backupów i konserwacji

Prosta checklist:

Twórz regularne backupy.
Przechowuj backupy poza serwerem bazy danych.
Chroń pliki backupów.
Testuj restore.
Rób backup przed migracjami.
Używaj użytkowników aplikacyjnych.
Aktualizuj PostgreSQL.
Monitoruj miejsce na dysku.
Obserwuj wolne zapytania.
Pozwól działać autovacuum.
Uruchamiaj ANALYZE po dużych importach, jeśli trzeba.
Dokumentuj kroki restore.

Dokumentacja ma znaczenie.

Procedura restore nie powinna żyć tylko w twojej głowie.

Zwłaszcza jeśli twoja głowa jest zmęczona.

Albo na wakacjach.

Albo pije kawę, gdy produkcja płonie.

Zapisz kroki.

Przyszły ty zasługuje na litość.

Typowe błędy z backupami

Nigdy nie testować restore

To największy błąd.

Sam plik backupu nie wystarczy.

Musisz wiedzieć, że da się go przywrócić.

Testuj restore na innej bazie danych.

Przykład:

createdb -U postgres restore_test_db
pg_restore -U postgres -d restore_test_db shop_db_2026-05-03.dump

Potem sprawdź dane.

Ufaj, ale sprawdzaj.

A właściwie przy backupach:

Nie ufaj.
Sprawdzaj.

Trzymanie backupów tylko na tym samym serwerze

Jeśli serwer padnie, możesz stracić bazę i backup razem.

Źle.

Przechowuj kopie gdzie indziej.

Backup powinien przetrwać awarię oryginalnej maszyny.

O to właśnie chodzi.

Robienie backupów zbyt rzadko

Jeśli robisz backup raz w miesiącu, możesz stracić miesiąc danych.

Może to akceptowalne dla zabawkowego projektu.

Nieakceptowalne dla prawdziwego sklepu.

Wybierz częstotliwość backupów na podstawie tego, ile danych możesz stracić.

To pytanie ma poważną nazwę:

Recovery Point Objective

Prosta wersja:

Jaka utrata danych jest akceptowalna?

Jeśli odpowiedź brzmi “prawie żadna”, potrzebujesz poważnej strategii.

Nie wiedzieć, ile trwa restore

Backup może istnieć.

Ale restore może trwać.

Dla małych baz może to być kilka sekund.

Dla ogromnych baz może to być kilka godzin.

Jeśli aplikacja nie działa, czas restore ma znaczenie.

To pytanie ma inną poważną nazwę:

Recovery Time Objective

Prosta wersja:

Jak długo system może być offline?

Tutaj ludzie biznesu nagle zaczynają bardzo interesować się bazami danych.

Ciekawe, jak to działa.

Robienie backupu złej bazy danych

Klasyczny błąd.

Myślisz, że zrobiłeś backup produkcji.

A naprawdę zrobiłeś backup lokalnego developmentu.

Backup zawiera trzech testowych użytkowników i produkt nazwany “banana”.

Sprawdź:

SELECT current_database();

Sprawdź nazwy plików backupu.

Sprawdź wynik restore.

Nie zakładaj.

Praktyka

Utwórz backup backup_demo_db:

pg_dump -U postgres -d backup_demo_db > backup_demo_db.sql

Utwórz bazę do restore:

createdb -U postgres backup_demo_restore_db

Przywróć:

psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Sprawdź:

psql -U postgres -d backup_demo_restore_db

SELECT * FROM notes;

Utwórz backup custom:

pg_dump -U postgres -F c -d backup_demo_db -f backup_demo_db.dump

Utwórz kolejną bazę do restore:

createdb -U postgres backup_demo_custom_restore_db

Przywróć:

pg_restore -U postgres -d backup_demo_custom_restore_db backup_demo_db.dump

Sprawdź:

psql -U postgres -d backup_demo_custom_restore_db

SELECT * FROM notes;

Uruchom konserwację:

VACUUM ANALYZE;

Sprawdź rozmiar bazy danych:

SELECT pg_size_pretty(pg_database_size(current_database()));

To praktyczne.

To nie glamour.

To przydatne.

Jak dobry śrubokręt.

Znowu.

Bazy danych lubią śrubokręty.

Metaforycznie.

Mini wyzwanie

Stwórz plan backupu dla małej bazy bloga.

Załóż:

nazwa bazy: blog_app_db
dane zmieniają się codziennie
blog jest mały
utrata więcej niż jednego dnia danych jest zła
deploy robisz co tydzień

Napisz prosty plan backupu:

Częstotliwość backupu:
Format backupu:
Lokalizacja backupu:
Retencja:
Częstotliwość testu restore:
Backup przed migracjami:
Kto ma dostęp do backupów:

Przykładowa odpowiedź:

Częstotliwość backupu: codziennie
Format backupu: format custom przez pg_dump -F c
Lokalizacja backupu: zewnętrzny bezpieczny storage
Retencja: trzymać backupy dzienne przez 7 dni i tygodniowe przez 1 miesiąc
Częstotliwość testu restore: raz w miesiącu
Backup przed migracjami: zawsze
Kto ma dostęp do backupów: tylko administrator

Teraz utwórz komendę backupu:

pg_dump -U postgres -F c -d blog_app_db -f blog_app_db_2026-05-03.dump

Utwórz komendę testowego restore:

createdb -U postgres blog_app_restore_test_db
pg_restore -U postgres -d blog_app_restore_test_db blog_app_db_2026-05-03.dump

Potem napisz zapytanie kontrolne:

SELECT COUNT(*) FROM posts;

Tak zaczynasz myśleć jak ktoś odpowiedzialny za dane.

Trochę straszne.

Bardzo przydatne.

Bardzo dorosłe.

Podsumowanie

Dzisiaj nauczyłeś się:

Ta lekcja jest ekstremalnie ważna.

Może nie efektowna.

Ale ważna.

Programista, który umie tworzyć tabele, jest przydatny.

Programista, który umie odpytywać dane, jest lepszy.

Programista, który umie chronić i przywracać dane, jest dużo bardziej godny zaufania.

Bo prawdziwe projekty nie polegają tylko na budowaniu.

Polega też na przetrwaniu błędów.

A backupy są jednym z najlepszych sposobów na przetrwanie.

Podsumowanie kursu

Dotarłeś do końca tego kursu PostgreSQL.

Nauczyłeś się:

To dużo.

Nie nauczyłeś się tylko komend.

Nauczyłeś się myśleć o danych.

To ma znaczenie.

Bo aplikacje przychodzą i odchodzą.

Frameworki się zmieniają.

Trendy frontendowe zmieniają się co piętnaście minut.

Ale dane zostają ważne.

PostgreSQL to poważne narzędzie.

Teraz wiesz wystarczająco dużo, żeby zacząć używać go poważnie.

Ostrożnie.

Praktycznie.

I z backupami.

Zawsze z backupami.

Ostatnie słowa

PostgreSQL nie zawsze będzie łatwy.

Czasem będzie narzekał.

Czasem odrzuci twoje zapytanie.

Czasem powie:

syntax error at or near...

a ty będziesz patrzeć na jeden przecinek przez dziesięć minut.

To normalne.

Uczysz się prawdziwego narzędzia.

Potężnego narzędzia.

Narzędzia używanego w prawdziwych aplikacjach, prawdziwych firmach, prawdziwych API, prawdziwych dashboardach i prawdziwych systemach, gdzie dane mają znaczenie.

Ćwicz dalej.

Twórz małe projekty.

Psuj rzeczy.

Przywracaj je.

Pisz zapytania.

Używaj EXPLAIN ANALYZE.

Rób backupy.

Testuj backupy.

Szanuj dane.

I pamiętaj:

Przeglądarki zapominają.
Bazy danych pamiętają.
Backupy wybaczają.

Bardzo PostgreSQL.

Bardzo praktycznie.

Bardzo dobrze.