آپ AWS پر ڈزاسٹر ریکوری کے بارے میں کیسے سوچتے ہیں؟

Question

Accepted Answer

**Disaster recovery (DR)** کسی بڑی ناکامی یا ڈزاسٹر کے بعد سسٹمز اور ڈیٹا کو بحال کرنے کی منصوبہ بندی ہے۔ AWS مختلف trade-offs کے ساتھ DR حکمت عملیں فراہم کرتا ہے **recovery speed**، **ڈیٹا loss**، اور **cost** کے درمیان — RTO اور RPO اہداف سے متعین کیا جاتا ہے۔

## اہم تصورات: RTO اور RPO

```text
RTO (Recovery Time Objective) → how QUICKLY you must recover (acceptable downtime)
RPO (Recovery Point Objective) → how much DATA LOSS is acceptable (recover to how
  recent a point — e.g. "at most 5 minutes of data lost")
→ Lower RTO/RPO (faster recovery, less data loss) = higher cost/complexity.
  Define these based on business needs; they drive the DR strategy choice.
```

## DR حکمت عملیں (cost بمقابلہ recovery-speed trade-off)

```text
1. BACKUP & RESTORE → back up data (to S3, snapshots); restore after a disaster
   → cheapest; slowest recovery (hours); higher RPO. For tolerant workloads.
2. PILOT LIGHT → core systems (e.g. database, replicated) kept minimal/ready;
   scale up the rest on disaster → moderate cost, faster recovery
3. WARM STANDBY → a scaled-down but RUNNING copy in another region; scale up on failover
   → higher cost, fast recovery (minutes)
4. MULTI-SITE ACTIVE-ACTIVE → full running copies in multiple regions serving traffic
   → highest cost/complexity; near-zero RTO/RPO. For the most critical systems.
```

## عملی DR طریقے

```text
✓ Regular, tested BACKUPS (automated; cross-region copies; verify they restore!)
✓ Cross-REGION strategy for region-level disasters (DR often = another region)
✓ INFRASTRUCTURE AS CODE → recreate environments quickly/reliably
✓ TEST DR plans regularly (a plan never tested may fail when needed)
✓ Automate failover where possible; document runbooks
→ Match the strategy to the workload's RTO/RPO and budget.
```

## اہم ہے کیوں

Disaster recovery کو سمجھنا سینئر سطح کے علم میں اہم ہے کیونکہ **بڑی ناکامیوں سے بحالی business-critical سسٹمز کے لیے ضروری ہے**، اور AWS DR میں اہم trade-offs شامل ہیں، تو یہ لچکدار سسٹمز ڈیزائن کرنے میں قیمتی ہے۔

DR اس حقیقت کو حل کرتا ہے کہ بڑی ڈزاسٹرز ہو سکتی ہیں (region failures، ڈیٹا corruption، سنگین غلطیاں)، اور **business-critical سسٹمز بحال ہونے کے قابل ہونے چاہیئں** — DR منصوبہ بندی کو ضروری بناتے ہوئے ان سسٹمز کے لیے جہاں downtime یا ڈیٹا loss کے سنگین نتائج ہیں۔

**RTO اور RPO** کو سمجھنا بنیادی ہے: یہ اہداف (آپ کو کتنی جلدی بحال کرنا ہے، اور کتنا ڈیٹا loss قابلِ قبول ہے) **DR حکمت عملی کو متعین کرتے ہیں** اور business needs کی بنیاد پر متعین ہونے چاہیئں — واضح کرتے ہوئے کہ DR ایک جیسا نہیں ہے بلکہ ایک شعوری توازن ہے۔

**DR حکمت عملیں** اور ان کی **cost-vs-recovery-speed trade-offs** کو سمجھنا — backup & restore (سب سے سستا، سب سے سست)، pilot light (core سسٹمز تیار)، warm standby (scaled-down چلتی ہوئی کاپی، تیز بحالی)، اور multi-site active-active (مکمل چلتی ہوئی کاپیاں، قریب صفر RTO/RPO لیکن سب سے زیادہ cost) — مناسب حکمت عملی کا انتخاب کرنے کے لیے اہم علم ہے: زیادہ مطالبہ کنندہ recovery objectives کی زیادہ قیمت ہے، تو حکمت عملی workload کی اہمیت اور budget سے میل کھانی چاہیے۔

**عملی DR طریقوں** کو سمجھنا (منظم طریقے سے آزمائی ہوئی backups، region-level ڈزاسٹرز کے لیے cross-region حکمت عملی، بہت تیزی سے ماحول کی تخلیق نو کے لیے Infrastructure as Code، اور سب سے اہم **DR منصوبوں کی جانچ کریں** کیونکہ آزمائی ہوئی منصوبے اکثر جب ضروری ہوں تو ناکام ہوتے ہیں) بالغ operational نظم و ضبط کو ظاہر کرتا ہے۔

کیونکہ critical سسٹمز سے بحالی ضروری ہے اور DR اصل trade-offs (recovery speed، ڈیٹا loss، cost) میں شامل ہے جو business needs سے میل کھانے چاہیئں، اور کیونکہ RTO/RPO، DR حکمت عملیں، اور عملی طریقوں کو سمجھنا مناسب بحالی کی صلاحیتوں کو ڈیزائن کرنے میں سہولت دیتا ہے، AWS پر disaster recovery کو سمجھنا سینئر سطح کے علم میں اہم ہے لچکدار سسٹمز بنانے کے لیے — business کے لیے اہم workloads کو چلانے کا ایک اہم پہلو، senior roles کے لیے متوقع risk-management اور resilience-planning بالغ پن کو ظاہر کرتے ہوئے جو ایسے سسٹمز کی ذمہ داری لیتے ہیں جہاں failures اور ڈیٹا loss کے سنگین نتائج ہیں۔