Backup i disaster recovery za bazu podataka od desetaka TB

Question

IT Interview Practice · Accepted Answer

**Kombinirajte periodičke snapshote s kontinuiranim WAL arhiviranjem za point-in-time recovery, replicirajte izvan lokacije/preko regija i dokažite to redovitim vježbama vraćanja prema eksplicitnim RPO/RTO ciljevima.** Backup koji nikada niste vratili je nada, ne plan.

## Arhitektura

```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
```

## Kako funkcionira

- **Snapshoti** su puna kopija volumena/clustera (npr. dnevni EBS snapshot ili `pg_basebackup`). Oni su baza *iz koje* vraćate — ali vraćanje samo do sinoć gubi dan upisa.
- **WAL / binlog arhiviranje** kontinuirano streama svaku promjenu od zadnjeg snapshota u object store. Vraćanje = snapshot + replay WAL-a do bilo koje odabrane sekunde. To je **PITR (point-in-time recovery)** — vratite na 10:32:04, trenutak prije lošeg `DELETE`.
- **Izvan lokacije / preko regija.** Backup u istoj regiji kao baza umire s regijom. Replicirajte u drugu regiju (S3 cross-region replikacija) tako da regionalni prekid ili ransomware ne odnese oboje.
- **Vježbe vraćanja.** Periodički vratite u testno okruženje, izmjerite koliko je trajalo (**RTO**) i koliko biste podataka izgubili (**RPO**) i usporedite checksum s produkcijom.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = koliko podataka si možete priuštiti izgubiti. WAL arhiviranje svakih 5 min → RPO ≈ 5 min. Sinkroni replika → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = koliko brzo morate biti natrag. Vraćanje 20 TB iz S3 može trajati satima; warm standby replika reže RTO na minute.

## Perspektiva intervjua

Ispitivač ispituje znate li da **snapshoti sami nisu dovoljni** (gubitak podataka između njih), možete li **definirati RPO/RTO u brojevima** i **testirate li vraćanja**. Odlični odgovori naglašavaju da netestirani backupi otkažu točno kad zatrebaju i biraju strategiju iz *poslovnog* RPO/RTO, ne iz udobnosti. Zamka: pretpostaviti da je read replika backup — replikacija vjerno kopira i `DROP TABLE`.

## Kompromisi i neuspjesi

- **Trošak vs RTO.** Warm cross-region standby daje minute RTO-a ali udvostručuje infrastrukturni trošak; cold S3 vraćanje je jeftino ali sporo. Kupite sloj koji posao stvarno treba.
- **Opterećenje backupa.** Snapshotiranje vruće 20 TB baze dodaje I/O; uzmite snapshote iz replike.
- **Tiha korupcija.** WAL može arhivirati korumpiranu stranicu; periodički full-restore + checksum to hvata.
- **Zadržavanje i usklađenost.** Držite dovoljno povijesti (npr. 35 dana PITR + mjesečne arhive) za pravne potrebe; Glacier za jeftino dugoročno.
- **Kada ne:** sićušna baza je u redu s noćnim `pg_dump` u S3 — puni WAL + cross-region standby je pretjerivanje dok se gubitak podataka ne mjeri stvarnim novcem.

Arhitektura

Kako funkcionira

RPO vs RTO

Perspektiva intervjua

Kompromisi i neuspjesi

Povezana pitanja