Atsarginės kopijos ir avarinis atkūrimas dešimčių TB duomenų bazei

Question

IT Interview Practice · Accepted Answer

**Derinkite periodines momentines nuotraukas (snapshots) su nuolatiniu WAL archyvavimu point-in-time recovery, replikuokite už objekto ribų / per regionus ir įrodykite tai reguliariais atkūrimo pratimais pagal aiškius RPO/RTO tikslus.** Atsarginė kopija, kurios niekada neatkūrėte, yra viltis, o ne planas.

## Architektūra

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

## Kaip tai veikia

- **Snapshots** yra pilna tomo/klasterio kopija (pvz. dieninis EBS snapshot arba `pg_basebackup`). Tai bazė, iš kurios atkuriate — bet atkūrimas tik iki praėjusios nakties praranda dienos įrašymus.
- **WAL / binlog archyvavimas** nuolat perduoda kiekvieną pokytį nuo paskutinio snapshot į objektų saugyklą. Atkūrimas = snapshot + WAL pakartojimas iki bet kurios pasirinktos sekundės. Tai **PITR (point-in-time recovery)** — atkurti iki 10:32:04, akimirkos prieš blogą `DELETE`.
- **Už objekto ribų / per regionus.** Atsarginė kopija tame pačiame regione kaip DB žūva su regionu. Replikuokite į antrą regioną (S3 cross-region replication), kad regiono gedimas ar ransomware nepaimtų abiejų.
- **Atkūrimo pratimai.** Periodiškai atkurkite į juodraštinę aplinką, išmatuokite, kiek užtruko (**RTO**) ir kiek duomenų būtumėte praradę (**RPO**), ir sutikrinkite checksum su prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = kiek duomenų galite sau leisti prarasti. WAL archyvavimas kas 5 min → RPO ≈ 5 min. Sinchroninė replika → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = kaip greitai turite grįžti. 20TB atkūrimas iš S3 gali užtrukti valandas; šilta standby replika sumažina RTO iki minučių.

## Interviu perspektyva

Interviuotojas tiria, ar žinote, kad **vien snapshots neužtenka** (duomenų praradimas tarp jų), ar galite **apibrėžti RPO/RTO skaičiais** ir ar **testuojate atkūrimus**. Puikūs atsakymai pabrėžia, kad neišbandytos atsarginės kopijos žlunga būtent kai reikia, ir renkasi strategiją iš *verslo* RPO/RTO, ne iš patogumo. Spąstai: laikyti read replica atsargine kopija — replikacija ištikimai nukopijuoja ir `DROP TABLE`.

## Kompromisai ir gedimai

- **Kaina vs RTO.** Šilta cross-region standby suteikia minučių RTO, bet dvigubina infrastruktūros kainą; šaltas S3 atkūrimas pigus, bet lėtas. Pirkite pakopą, kurios verslui iš tikrųjų reikia.
- **Atsarginės kopijos apkrova.** Karštos 20TB DB snapshot prideda I/O; darykite snapshots iš replikos.
- **Tylus sugadinimas.** WAL gali archyvuoti sugadintą puslapį; periodinis pilnas atkūrimas + checksum tai pagauna.
- **Saugojimas ir atitiktis.** Laikykite pakankamai istorijos (pvz. 35 dienos PITR + mėnesiniai archyvai) teisiniams poreikiams; Glacier pigiam ilgalaikiam saugojimui.
- **Kada ne:** mažytė DB tinka su naktiniu `pg_dump` į S3 — pilnas WAL + cross-region standby yra perteklius, kol duomenų praradimas nematuojamas realiais pinigais.

Architektūra

Kaip tai veikia

RPO vs RTO

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai