دسیوں TB کے database کے لیے backup اور disaster recovery

Question

IT Interview Practice · Accepted Answer

**point-in-time recovery کے لیے وقفے وقفے سے snapshots کو مسلسل WAL archiving کے ساتھ ملائیں، offsite/cross-region replicate کریں، اور اسے واضح RPO/RTO اہداف کے خلاف باقاعدہ 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 ہیں (مثلاً روزانہ EBS snapshot یا `pg_basebackup`)۔ یہ وہ base ہیں جس *سے* آپ restore کرتے ہیں — مگر صرف کل رات تک restore کرنے سے ایک دن کی writes کھو جاتی ہیں۔
- **WAL / binlog archiving** آخری snapshot کے بعد سے ہر تبدیلی مسلسل object store میں stream کرتی ہے۔ Restore = snapshot + کسی بھی چنے گئے سیکنڈ تک 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**) اور آپ کتنا ڈیٹا کھو دیتے (**RPO**)، اور prod کے خلاف checksum کریں۔

## RPO بمقابلہ RTO

- **RPO (Recovery Point Objective)** = آپ کتنا ڈیٹا کھونے کے متحمل ہو سکتے ہیں۔ ہر 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 کرتی ہے۔

## توازن اور ناکامی

- **لاگت بمقابلہ RTO۔** ایک warm cross-region standby منٹوں کا RTO دیتا ہے مگر infra لاگت دوگنی کرتا ہے؛ cold S3 restore سستا مگر سست ہے۔ وہ tier خریدیں جس کی business کو واقعی ضرورت ہے۔
- **Backup load۔** ایک hot 20TB DB کا snapshot لینا I/O بڑھاتا ہے؛ snapshots ایک replica سے لیں۔
- **خاموش corruption۔** WAL ایک corrupt page archive کر سکتا ہے؛ وقفے وقفے سے full-restore + checksum اسے پکڑتا ہے۔
- **Retention اور compliance۔** قانونی ضروریات کے لیے کافی تاریخ رکھیں (مثلاً 35 دن PITR + ماہانہ archives)؛ سستے طویل مدتی کے لیے Glacier۔
- **کب نہیں:** ایک چھوٹا DB S3 پر رات کے `pg_dump` سے ٹھیک ہے — full WAL + cross-region standby تب تک زیادہ ہے جب تک data loss اصل پیسے میں نہ ماپا جائے۔

فن تعمیر

یہ کیسے کام کرتا ہے

RPO بمقابلہ RTO

انٹرویو کا نقطۂ نظر

توازن اور ناکامی

متعلقہ سوالات