Jak wykonać kopię zapasową i odzyskać PostgreSQL?

Question

Accepted Answer

PostgreSQL oferuje kilka metod **kopii zapasowej** — logiczne kopie zapasowe (`pg_dump`) i fizyczne kopie zapasowe (base backup + WAL dla **odzyskiwania do punktu w czasie**). Solidna strategia tworzenia kopii zapasowych i odzyskiwania jest niezbędna do ochrony przed utratą danych, a co najważniejsze, **kopie zapasowe muszą być testowane**.

## Logiczne kopie zapasowe — pg_dump

```bash
# pg_dump — dumps a database as SQL (or a custom archive) — portable, flexible
pg_dump -U user -d mydb -F c -f backup.dump      # custom format (compressed, flexible restore)
pg_dump -U user -d mydb > backup.sql              # plain SQL
pg_dumpall > all.sql                              # ALL databases + roles

# restore
pg_restore -U user -d mydb backup.dump            # from custom format
psql -U user -d mydb -f backup.sql                # from plain SQL
```

`pg_dump` tworzy logiczną kopię zapasową (SQL lub archiwum) bazy danych — przenośną (przywracalną do różnych wersji/serwerów), dobrą dla mniejszych baz danych, migracji i selektywnych kopii zapasowych. Ale jest to migawka point-in-time (bez ciągłego odzyskiwania).

## Fizyczne kopie zapasowe + Odzyskiwanie do punktu w czasie (PITR)

```text
For larger/critical databases: a BASE BACKUP (a copy of the data files) + continuous
archiving of the WAL (write-ahead log) → enables POINT-IN-TIME RECOVERY:
  ✓ Restore the base backup, then REPLAY WAL up to ANY point in time
  ✓ Recover to JUST BEFORE a disaster (e.g. an accidental DROP TABLE at 2:47pm)
→ Tools: pg_basebackup, WAL archiving, and tools like pgBackRest / Barman automate this.
```

**PITR** jest potężne: poprzez ciągłe archiwizowanie WAL, możesz odzyskać do dowolnego momentu — nie tylko ostatniej kopii zapasowej — co jest niezbędne do minimalizowania utraty danych w przypadku awarii.

## Podstawy strategii tworzenia kopii zapasowych

```text
✓ Regular, AUTOMATED backups (scheduled, not manual/forgotten)
✓ Store backups OFF the database server (and offsite / cloud) — survive hardware failure
✓ Retention policy (keep daily/weekly/monthly as needed)
✓ Combine: periodic base backups + continuous WAL for PITR (critical data)
✓ Backups from a REPLICA to avoid loading the primary
```

## Najważniejsza zasada: TESTUJ swoje kopie zapasowe

```text
⚠️ A backup you've never restored is NOT a reliable backup.
UNTESTED backups fail when you need them most (corrupt, incomplete, wrong process).
→ Regularly TEST restores to verify they actually work and you know the procedure.
```

## Dlaczego to ważne

Tworzenie kopii zapasowych i odzyskiwanie jest **krytycznym** zagadnieniem dla odpowiedzialnej obsługi PostgreSQL — ochrona przed utratą danych (z powodu awarii sprzętu, uszkodzenia, przypadkowego usunięcia, katastrof) jest jedną z najważniejszych odpowiedzialności każdej produkcyjnej bazy danych, dlatego zrozumienie strategii tworzenia kopii zapasowych jest niezbędne dla wiedzy na poziomie senior.

Zrozumienie metod jest konieczne: **`pg_dump`** (logiczne kopie zapasowe — przenośne zrzuty SQL/archiwum, dobre dla mniejszych baz danych, migracji i selektywnych/między-wersyjnych kopii zapasowych, ale tylko migawki point-in-time) i **fizyczne kopie zapasowe z odzyskiwaniem do punktu w czasie (PITR)** (base backup + ciągłe archiwizowanie WAL, umożliwiające odzyskanie do *dowolnego* momentu — co jest potężne do minimalizowania utraty danych, takie jak odzyskanie tuż przed przypadkowym `DROP TABLE`, niezbędne dla krytycznych danych).

Znajomość **podstaw strategii** (regularne automatyczne kopie zapasowe, przechowywanie ich poza serwerem i poza biurem, polityki przechowywania, łączenie base backupów z WAL dla PITR na danych krytycznych, tworzenie kopii zapasowych z replik) jest ważną wiedzą operacyjną.

Najkrytyczniej, zrozumienie, że **kopie zapasowe muszą być testowane** — nietestowana kopia zapasowa jest zawodna i często zawodzi dokładnie w momencie, gdy jest potrzebna (uszkodzenie, niekompletne dane, nieznawy proces przywracania) — jest najważniejszą, często zapomnianą zasadą: regularne testowanie przywracania to to, co sprawia, że strategia tworzenia kopii zapasowych jest naprawdę godna zaufania.

Ponieważ utrata danych może być katastrofalna (a odzyskiwanie jest możliwe tylko z działającymi kopiami zapasowymi), i ponieważ właściwa strategia (odpowiednie metody tworzenia kopii zapasowych, PITR dla minimalnej utraty, przechowywanie poza biurem i co najważniejsze *testowane* przywracanie) jest tym, co chroni dane organizacji, zrozumienie tworzenia kopii zapasowych i odzyskiwania PostgreSQL jest krytycznym zagadnieniem na poziomie senior dla odpowiedzialnej obsługi baz danych — odpowiedzialność wysoko stawkowa, gdzie różnica między testowaną strategią a nietestowaną może być różnicą między odzyskaniem danych z katastrofy a trwałą utratą danych, czyniąc to niezbędnym i często istotnym tematem dla każdego, kto obsługuje produkcyjne bazy danych.