दहा TB च्या database साठी Backup आणि disaster recovery

Question

IT Interview Practice · Accepted Answer

**periodic snapshots ला point-in-time recovery साठी continuous WAL archiving सोबत combine करा, offsite/cross-region replicate करा, आणि explicit RPO/RTO targets विरुद्ध नियमित restore drills ने ते सिद्ध करा.** तुम्ही कधीही restore न केलेला backup एक आशा आहे, योजना नाही.

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

```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`). तुम्ही ज्या *पासून* restore करता तो base ते आहेत — पण फक्त कालच्या रात्रीपर्यंत restore केल्याने एक दिवसाचे writes हरवतात.
- **WAL / binlog archiving** शेवटच्या snapshot नंतरचा प्रत्येक बदल object store ला सतत stream करते. Restore = snapshot + WAL कोणत्याही निवडलेल्या सेकंदापर्यंत replay. हे **PITR (point-in-time recovery)** आहे — एका वाईट `DELETE` च्या आधीच्या क्षणी 10:32:04 पर्यंत recover करा.
- **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 vs RTO

- **RPO (Recovery Point Objective)** = तुम्ही किती data गमावू शकता. दर 5 मिनिटाला WAL archiving → RPO ≈ 5 min. Synchronous replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = तुम्हाला किती लवकर परत यायचे. S3 मधून 20TB restore करण्यास तास लागू शकतात; एक warm standby replica RTO मिनिटांपर्यंत कमी करते.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा तुम्हाला **फक्त snapshots पुरेसे नाहीत** (त्यांच्यामधील data loss) हे माहीत आहे का, तुम्ही **RPO/RTO संख्येत परिभाषित** करू शकता का, आणि तुम्ही **restores test करता** का हे तपासतो. उत्तम उत्तरे जोर देतात की untested backups नेमके गरजेच्या वेळी अपयशी होतात, आणि strategy *business* RPO/RTO मधून निवडतात, सोयीतून नाही. एक सापळा: read replica हा backup आहे असे गृहीत धरणे — replication एक `DROP TABLE` देखील प्रामाणिकपणे copy करते.

## तडजोडी आणि अपयश

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

आर्किटेक्चर

कसे कार्य करते

RPO vs RTO

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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