Varmuuskopiointi ja katastrofipalautus kymmenien TB:n tietokannalle

Question

IT Interview Practice · Accepted Answer

**Yhdistä ajoittaiset snapshotit jatkuvaan WAL-arkistointiin point-in-time-palautusta varten, replikoi offsite/cross-region ja todista se säännöllisillä restore-harjoituksilla eksplisiittisiä RPO/RTO-tavoitteita vasten.** Varmuuskopio, jota et ole koskaan palauttanut, on toivo, ei suunnitelma.

## Arkkitehtuuri

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

## Miten se toimii

- **Snapshotit** ovat täysi kopio levystä/klusterista (esim. päivittäinen EBS-snapshot tai `pg_basebackup`). Ne ovat pohja, josta palautat — mutta palauttaminen vain viime yöhön menettää päivän kirjoitukset.
- **WAL / binlog -arkistointi** striimaa jokaisen muutoksen viimeisestä snapshotista object storeen jatkuvasti. Palautus = snapshot + WAL:n toisto mihin tahansa valittuun sekuntiin. Tämä on **PITR (point-in-time recovery)** — palautus hetkeen 10:32:04, hetki ennen huonoa `DELETE`:ä.
- **Offsite / cross-region.** Samalla alueella kuin DB oleva varmuuskopio kuolee alueen mukana. Replikoi toiselle alueelle (S3 cross-region replication), jottei alueellinen katko tai kiristyshaittaohjelma vie molempia.
- **Restore-harjoitukset.** Palauta ajoittain scratch-ympäristöön, mittaa kuinka kauan se kesti (**RTO**) ja kuinka paljon dataa menettäisit (**RPO**), ja checksummaa tuotantoa vasten.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = kuinka paljon dataa sinulla on varaa menettää. WAL-arkistointi 5 min välein → RPO ≈ 5 min. Synkroninen replika → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = kuinka nopeasti sinun on oltava takaisin. 20 TB:n palauttaminen S3:sta voi kestää tunteja; lämmin standby-replika leikkaa RTO:n minuutteihin.

## Haastattelunäkökulma

Haastattelija tutkii, tiedätkö että **pelkät snapshotit eivät riitä** (datamenetys niiden välillä), osaatko **määritellä RPO/RTO:n numeroina** ja **testaatko palautukset**. Loistavat vastaukset korostavat, että testaamattomat varmuuskopiot epäonnistuvat juuri silloin kun niitä tarvitaan, ja valitsevat strategian *liiketoiminnan* RPO/RTO:sta, ei mukavuudesta. Ansa: read replikan olettaminen varmuuskopioksi — replikointi kopioi uskollisesti myös `DROP TABLE`:n.

## Kompromissit ja virhetilanteet

- **Kustannus vs RTO.** Lämmin cross-region-standby antaa minuuttien RTO:n mutta tuplaa infrakustannuksen; kylmä S3-restore on halpa mutta hidas. Osta se taso, jonka liiketoiminta oikeasti tarvitsee.
- **Varmuuskopiointikuorma.** Kuuman 20 TB DB:n snapshottaus lisää I/O:ta; ota snapshotit replikasta.
- **Hiljainen korruptio.** WAL voi arkistoida korruptoituneen sivun; ajoittainen full-restore + checksum saa sen kiinni.
- **Retentio & compliance.** Pidä tarpeeksi historiaa (esim. 35 päivää PITR + kuukausittaiset arkistot) laillisiin tarpeisiin; Glacier halpaan pitkäaikaissäilytykseen.
- **Milloin ei:** pieni DB pärjää yöllisellä `pg_dump`:lla S3:een — täysi WAL + cross-region-standby on ylimitoitusta, kunnes datamenetys mitataan oikeissa rahoissa.

Arkkitehtuuri

Miten se toimii

RPO vs RTO

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset