दसियों TB के database के लिए backup और disaster recovery

Question

IT Interview Practice · Accepted Answer

**point-in-time recovery के लिए periodic snapshots को continuous WAL archiving के साथ मिलाएं, offsite/cross-region replicate करें, और स्पष्ट RPO/RTO targets के विरुद्ध नियमित restore drills से इसे साबित करें।** एक backup जिसे आपने कभी restore नहीं किया वह एक उम्मीद है, योजना नहीं।

## आर्किटेक्चर

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

## यह कैसे काम करता है

- **Snapshots** volume/cluster की एक पूरी copy हैं (जैसे daily EBS snapshot या `pg_basebackup`)। ये वह base हैं जिससे आप restore करते हैं — पर केवल कल रात तक restore करना एक दिन के writes खो देता है।
- **WAL / binlog archiving** अंतिम snapshot के बाद हर change को लगातार object store में stream करता है। Restore = snapshot + किसी भी चुने हुए second तक WAL replay। यह **PITR (point-in-time recovery)** है — 10:32:04 तक recover करें, एक खराब `DELETE` से ठीक पहले का क्षण।
- **Offsite / cross-region.** DB के समान region में एक backup region के साथ मर जाता है। एक दूसरे region में replicate करें (S3 cross-region replication) ताकि एक regional outage या ransomware दोनों को न ले जाए।
- **Restore drills.** समय-समय पर एक scratch environment में restore करें, नापें इसमें कितना समय लगा (**RTO**) और आपने कितना data खोया होता (**RPO**), और prod के विरुद्ध checksum करें।

## RPO बनाम RTO

- **RPO (Recovery Point Objective)** = आप कितना data खोना बर्दाश्त कर सकते हैं। हर 5 min WAL archiving → RPO ≈ 5 min। Synchronous replica → RPO ≈ 0।
- **RTO (Recovery Time Objective)** = आपको कितनी जल्दी वापस आना होगा। S3 से 20TB restore करने में घंटे लग सकते हैं; एक warm standby replica RTO को minutes तक काट देता है।

## इंटरव्यू का नज़रिया

Interviewer परखता है कि क्या आप जानते हैं **अकेले snapshots पर्याप्त नहीं** (उनके बीच data loss), क्या आप **RPO/RTO को numbers में define** कर सकते हैं, और क्या आप **restores test** करते हैं। बढ़िया जवाब ज़ोर देते हैं कि untested backups ठीक तब fail होते हैं जब ज़रूरत हो, और एक strategy *business* RPO/RTO से चुनते हैं, सुविधा से नहीं। एक जाल: एक read replica को backup मानना — replication एक `DROP TABLE` को भी वफ़ादारी से copy करता है।

## ट्रेड-ऑफ़ और failure

- **Cost बनाम RTO.** एक warm cross-region standby minutes का RTO देता है पर infra cost दोगुना करता है; cold S3 restore सस्ता पर धीमा है। वह tier खरीदें जो business को वास्तव में चाहिए।
- **Backup load.** एक hot 20TB DB को snapshot करना I/O जोड़ता है; snapshots एक replica से लें।
- **Silent corruption.** WAL एक corrupt page archive कर सकता है; periodic full-restore + checksum इसे पकड़ता है।
- **Retention और compliance.** legal ज़रूरतों के लिए पर्याप्त history रखें (जैसे 35 दिन PITR + monthly archives); सस्ते long-term के लिए Glacier।
- **कब नहीं:** एक छोटा DB nightly `pg_dump` से S3 तक ठीक है — full WAL + cross-region standby तब तक overkill है जब तक data loss असली पैसे में न नापा जाए।

आर्किटेक्चर

यह कैसे काम करता है

RPO बनाम RTO

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure

संबंधित प्रश्न