Backup i disaster recovery dla bazy o rozmiarze dziesiątek TB

Question

IT Interview Practice · Accepted Answer

**Połącz okresowe snapshoty z ciągłym archiwizowaniem WAL dla point-in-time recovery, replikuj poza siedzibę/między regionami i udowodnij to regularnymi próbami odtwarzania (restore drills) względem jawnych celów RPO/RTO.** Backup, którego nigdy nie odtworzyłeś, to nadzieja, a nie plan.

## Architektura

```text
Primary DB ──snapshot (daily)──▶ Object store (S3) ──cross-region replicate──▶ DR region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (continuous, PITR to any second)
                                          │
                          restore drill ──┴──▶ verified restore ─▶ measure RTO, checksum RPO
```

## Jak to działa

- **Snapshoty** to pełna kopia woluminu/klastra (np. dzienny snapshot EBS lub `pg_basebackup`). To baza, *z której* odtwarzasz — ale odtworzenie tylko do zeszłej nocy traci dzień zapisów.
- **Archiwizowanie WAL / binlog** strumieniuje każdą zmianę od ostatniego snapshotu do object storage ciągle. Odtworzenie = snapshot + odtworzenie WAL do dowolnej wybranej sekundy. To **PITR (point-in-time recovery)** — odzyskaj do 10:32:04, momentu przed złym `DELETE`.
- **Poza siedzibą / między regionami.** Backup w tym samym regionie co DB umiera wraz z regionem. Replikuj do drugiego regionu (S3 cross-region replication), aby regionalna awaria lub ransomware nie zabrały obu.
- **Próby odtwarzania.** Okresowo odtwarzaj do środowiska testowego, mierz, ile to zajęło (**RTO**) i ile danych byś stracił (**RPO**), i sprawdzaj sumę kontrolną względem produkcji.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = ile danych możesz sobie pozwolić stracić. Archiwizowanie WAL co 5 min → RPO ≈ 5 min. Synchroniczna replika → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = jak szybko musisz wrócić. Odtworzenie 20 TB z S3 może zająć godziny; ciepły standby replika skraca RTO do minut.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca sonduje, czy wiesz, że **same snapshoty nie wystarczą** (utrata danych pomiędzy nimi), czy potrafisz **zdefiniować RPO/RTO liczbowo** i czy **testujesz odtwarzanie**. Świetne odpowiedzi podkreślają, że nieprzetestowane backupy zawodzą dokładnie wtedy, gdy są potrzebne, i wybierają strategię z *biznesowego* RPO/RTO, nie z wygody. Pułapka: zakładanie, że read replika to backup — replikacja wiernie kopiuje też `DROP TABLE`.

## Kompromisy i awarie

- **Koszt vs RTO.** Ciepły standby między regionami daje minuty RTO, ale podwaja koszt infrastruktury; zimny restore z S3 jest tani, ale wolny. Kup warstwę, której biznes faktycznie potrzebuje.
- **Obciążenie backupem.** Snapshotowanie gorącej bazy 20 TB dodaje I/O; rób snapshoty z repliki.
- **Cicha korupcja.** WAL może zarchiwizować uszkodzoną stronę; okresowy pełny restore + suma kontrolna to wychwytuje.
- **Retencja i zgodność.** Trzymaj wystarczająco historii (np. 35 dni PITR + miesięczne archiwa) na potrzeby prawne; Glacier na tanie długoterminowe.
- **Kiedy nie:** maleńka baza jest OK z nocnym `pg_dump` do S3 — pełny WAL + standby między regionami to przesada, dopóki utrata danych nie jest liczona w realnych pieniądzach.

Architektura

Jak to działa

RPO vs RTO

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i awarie

Powiązane pytania