Onlarca TB'lık bir veritabanı için backup & disaster recovery

Question

IT Interview Practice · Accepted Answer

**Point-in-time recovery için periyodik snapshot'ları sürekli WAL archiving ile birleştirin, offsite/cross-region replicate edin ve açık RPO/RTO hedeflerine karşı düzenli restore tatbikatlarıyla kanıtlayın.** Asla restore etmediğiniz bir backup bir plan değil, bir umuttur.

## Mimari

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

## Nasıl çalışır

- **Snapshot'lar** volume/cluster'ın tam bir kopyasıdır (örn. günlük EBS snapshot veya `pg_basebackup`). Onlar restore *ettiğiniz* temeldir — ancak yalnızca dün geceye restore etmek bir günlük yazmayı kaybeder.
- **WAL / binlog archiving**, son snapshot'tan bu yana her değişikliği object store'a sürekli stream'ler. Restore = snapshot + seçilen herhangi bir saniyeye kadar WAL replay. Bu **PITR (point-in-time recovery)**'dir — kötü bir `DELETE`'ten önceki an olan 10:32:04'e kurtarın.
- **Offsite / cross-region.** DB ile aynı region'daki bir backup, region ile birlikte ölür. İkinci bir region'a replicate edin (S3 cross-region replication), böylece bölgesel bir kesinti veya ransomware ikisini birden almaz.
- **Restore tatbikatları.** Periyodik olarak bir scratch ortamına restore edin, ne kadar sürdüğünü (**RTO**) ve ne kadar veri kaybedeceğinizi (**RPO**) ölçün ve prod'a karşı checksum yapın.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = kaybetmeyi göze alabileceğiniz veri miktarı. Her 5 dakikada bir WAL archiving → RPO ≈ 5 dk. Synchronous replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = ne kadar hızlı geri dönmeniz gerektiği. S3'ten 20TB restore etmek saatler alabilir; sıcak bir standby replica RTO'yu dakikalara indirir.

## Mülakat perspektifi

Mülakatı yapan kişi, **yalnızca snapshot'ların yeterli olmadığını** (aralarındaki veri kaybı) bilip bilmediğinizi, **RPO/RTO'yu rakamlarla tanımlayıp** tanımlayamadığınızı ve **restore'ları test edip** etmediğinizi yoklar. Harika cevaplar, test edilmemiş backup'ların tam ihtiyaç anında başarısız olduğunu vurgular ve stratejiyi kolaylıktan değil, *işletme* RPO/RTO'sundan seçer. Bir tuzak: bir read replica'nın backup olduğunu varsaymak — replication bir `DROP TABLE`'ı da sadakatle kopyalar.

## Ödünleşimler & hata

- **Maliyet vs RTO.** Sıcak bir cross-region standby dakikalarca RTO verir ama infra maliyetini ikiye katlar; cold S3 restore ucuz ama yavaştır. İşletmenin gerçekten ihtiyaç duyduğu tier'ı satın alın.
- **Backup yükü.** Hot bir 20TB DB'yi snapshot'lamak I/O ekler; snapshot'ları bir replica'dan alın.
- **Sessiz corruption.** WAL bozuk bir page'i archive edebilir; periyodik full-restore + checksum bunu yakalar.
- **Retention & compliance.** Yasal ihtiyaçlar için yeterli geçmiş tutun (örn. 35 gün PITR + aylık arşivler); ucuz uzun vadeli için Glacier.
- **Ne zaman yapılmamalı:** minik bir DB, S3'e gecelik `pg_dump` ile iyidir — full WAL + cross-region standby, veri kaybı gerçek parayla ölçülene kadar aşırıya kaçmaktır.

Mimari

Nasıl çalışır

RPO vs RTO

Mülakat perspektifi

Ödünleşimler & hata

İlgili sorular