النسخ الاحتياطي والتعافي من الكوارث (backup & DR) لقاعدة بيانات بعشرات التيرابايت

Question

IT Interview Practice · Accepted Answer

**اجمع بين اللقطات الدورية (snapshots) وأرشفة WAL المستمرّة للتعافي إلى نقطة زمنية (point-in-time recovery)، وانسخ خارج الموقع/عبر المناطق، وأثبِته بتدريبات استعادة منتظمة مقابل أهداف RPO/RTO صريحة.** نسخة احتياطية لم تستعِدها قط هي أملٌ لا خطّة.

## البنية المعمارية

```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)** نسخة كاملة من الحجم/العنقود (مثلاً لقطة EBS يومية أو `pg_basebackup`). هي الأساس الذي تستعيد *منه* — لكن الاستعادة إلى الليلة الماضية فقط تفقد يوماً من الكتابات.
- **أرشفة WAL / binlog** تدفّق كل تغيير منذ آخر لقطة إلى مخزن الكائنات باستمرار. الاستعادة = لقطة + إعادة تشغيل WAL حتى أي ثانية مختارة. هذا هو **PITR (التعافي إلى نقطة زمنية)** — التعافي إلى 10:32:04، اللحظة قبل عملية `DELETE` سيّئة.
- **خارج الموقع / عبر المناطق.** نسخة احتياطية في نفس منطقة قاعدة البيانات تموت مع المنطقة. انسخ إلى منطقة ثانية (نسخ S3 عبر المناطق) كي لا يُسقِط انقطاع إقليمي أو فدية (ransomware) الاثنين معاً.
- **تدريبات الاستعادة.** استعِد دورياً في بيئة تجريبية، وقِس كم استغرق (**RTO**) وكم بيانات كنت ستفقد (**RPO**)، وتحقّق بمجموع اختباري (checksum) مقابل الإنتاج.

## RPO مقابل RTO

- **RPO (هدف نقطة التعافي)** = كم بيانات تستطيع تحمّل خسارتها. أرشفة WAL كل 5 دقائق ← RPO ≈ 5 دقائق. replica متزامن ← RPO ≈ 0.
- **RTO (هدف زمن التعافي)** = كم بسرعة يجب أن تعود. استعادة 20 تيرابايت من S3 قد تستغرق ساعات؛ replica احتياطي دافئ (warm standby) يقلّص RTO إلى دقائق.

## منظور المقابلة

يتحرّى المُحاور معرفتك أن **اللقطات وحدها لا تكفي** (فقدان بيانات بينها)، وقدرتك على **تعريف RPO/RTO بالأرقام**، وما إذا كنت **تختبر الاستعادات**. الإجابات الرائعة تشدّد أن النسخ غير المُختبرة تفشل تحديداً عند الحاجة، وتختار استراتيجية من RPO/RTO *العمل* لا من الراحة. فخّ: افتراض أن read replica نسخة احتياطية — فالنسخ ينسخ `DROP TABLE` بأمانة أيضاً.

## المقايضات والأعطال

- **التكلفة مقابل RTO.** replica احتياطي دافئ عبر المناطق يعطي RTO بالدقائق لكنه يضاعف تكلفة البنية؛ استعادة S3 الباردة رخيصة لكن بطيئة. اشترِ الطبقة التي يحتاجها العمل فعلاً.
- **حمل النسخ.** أخذ لقطة لقاعدة بيانات ساخنة بحجم 20 تيرابايت يضيف I/O؛ خُذ اللقطات من replica.
- **الفساد الصامت.** قد يؤرشف WAL صفحة فاسدة؛ استعادة كاملة دورية + مجموع اختباري تلتقطها.
- **الاحتفاظ والامتثال.** أبقِ تاريخاً كافياً (مثلاً 35 يوماً PITR + أرشيفات شهرية) للحاجات القانونية؛ Glacier للمدى الطويل الرخيص.
- **متى لا:** قاعدة بيانات صغيرة تكفيها `pg_dump` ليلية إلى S3 — WAL كامل + احتياطي عبر المناطق مبالغة حتى يُقاس فقدان البيانات بمال حقيقي.

البنية المعمارية

كيفية العمل

RPO مقابل RTO

منظور المقابلة

المقايضات والأعطال

أسئلة ذات صلة