كيفية بناء خطة للتعافي من الكوارث (RTO وRPO)

ما هي خطة التعافي من الكوارث فعليًا

خطة التعافي من الكوارث (DR) هي الإجراء الموثَّق والمختبَر الذي يتبعه فريقك لاستعادة أنظمة تقنية المعلومات والبيانات بعد انقطاع — خادم متعطل، أو برمجية فدية، أو قاعدة بيانات محذوفة، أو مركز بيانات غمرته المياه، أو فشل في منطقة سحابية. وهي ليست نفس النسخ الاحتياطي؛ فالنسخة الاحتياطية مجرد نسخة من البيانات، أما خطة التعافي فهي دليل العمل الذي يحوّل تلك النسخة من جديد إلى عمل يعمل فعليًا.

يرتكز كل خطة تعافٍ على رقمين: RTO وRPO. اضبط هذين الرقمين بشكل صحيح وستكتب بقية الخطة نفسها بنفسها تقريبًا.

RTO مقابل RPO: الرقمان اللذان يهمّان

• هدف وقت الاستعادة (RTO) هو أقصى مدة مقبولة لتوقف نظام ما قبل أن يسبب ضررًا جسيمًا. فإذا كان لمتجرك الإلكتروني هدف وقت استعادة قدره ساعتان، فيجب أن تكتمل الاستعادة خلال ساعتين من الحادث.
• هدف نقطة الاستعادة (RPO) هو أقصى كمية مقبولة من البيانات، مقاسة بالزمن، يمكنك تحمّل فقدانها. هدف نقطة استعادة قدره 15 دقيقة يعني أن نسخك الاحتياطية (أو النسخ المتماثل) يجب ألّا يتجاوز عمرها 15 دقيقة، فتفقد في أسوأ الأحوال 15 دقيقة من العمل.

وللتذكّر ببساطة: RTO ينظر إلى الأمام ("كم سيستغرق رجوعنا؟") وRPO ينظر إلى الخلف ("كم من البيانات الحديثة يمكن أن نفقد؟").

تشديد الأهداف يكلّف أكثر، لذا حدّدها لكل حِمل عمل على حدة، لا لكل شيء دفعة واحدة.

الخطوة 1: أجرِ تحليلًا لتأثير الأعمال (BIA)

أدرج كل نظام واسأل: ماذا يحدث للعمل في كل ساعة يتوقف فيها هذا النظام، وما حجم فقدان البيانات الذي يمكن تحمّله؟ ثم رتّب أحمال العمل في مستويات.

كن صادقًا. هدف وقت استعادة قدره 5 دقائق لمدونة تسويقية هدر للمال؛ وهدف نقطة استعادة قدره 24 ساعة لدفتر مدفوعات خطأ قد يُنهي العمل.

الخطوة 2: اختر استراتيجية استعادة لكل مستوى

طابِق كل مستوى مع بنية معمارية:

• النسخ والاستعادة (الأرخص، الأبطأ): نسخ احتياطية مجدوَلة إلى التخزين الكائني؛ وإعادة البناء عند الطلب. مناسبة للمستوى 3 وكثير من أحمال المستوى 2.
• الضوء الإرشادي / الاحتياطي الدافئ: نسخة مصغّرة من البيئة تظل تعمل في موقع ثانٍ، ويتم توسيعها أثناء تجاوز الفشل. مناسبة للمستوى 1 بهدف وقت استعادة معتدل.
• الاحتياطي الساخن / النشط-النشط: نسخة طبق الأصل تعمل بالكامل وتتولّى المهمة شبه فورًا. الأعلى تكلفة؛ احفظها لأنظمة المستوى 1 التي لا تُقبل فيها دقائق التوقف.

بالنسبة للمؤسسات السعودية، تأكّد أيضًا من المكان الفعلي لكل نسخة. فبموجب نظام حماية البيانات الشخصية وإرشادات الهيئة الوطنية للأمن السيبراني، يبقيك الاحتفاظ بالنسخ الأساسية ونسخ التعافي على بنية سحابية داخل المملكة في الجانب الصحيح من متطلبات إقامة البيانات، ويجنّبك مراجعات النقل عبر الحدود.

الخطوة 3: طبّق قاعدة النسخ الاحتياطي 3-2-1

أيًّا كان المستوى، صمّم النسخ الاحتياطية حول قاعدة 3-2-1 المُثبَتة:

• 3 نسخ من بياناتك (1 أساسية + 2 احتياطية)
• 2 نوعان مختلفان من الوسائط أو التخزين
• 1 نسخة خارج الموقع (منطقة أو مزوّد مختلف)

وثمة نسخة محدّثة، 3-2-1-1-0، تضيف 1 نسخة غير قابلة للتغيير/غير متصلة (تحمي من برمجيات الفدية) و0 أخطاء يتم التحقق منها عند الاستعادة. عدم القابلية للتغيير مهم: فبرمجيات الفدية باتت تستهدف النسخ الاحتياطية أولًا.

وفيما يلي نسخة احتياطية موثوقة ومشفّرة ومُزال منها التكرار لقاعدة بيانات ومجلد تطبيق باستخدام restic إلى تخزين كائني متوافق مع S3:

# تثبيت restic (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y restic

# توجيه restic إلى دلو التخزين الكائني الخاص بك
export RESTIC_REPOSITORY="s3:https://s3.example.com/dr-backups"
export AWS_ACCESS_KEY_ID="<access-key>"
export AWS_SECRET_ACCESS_KEY="<secret-key>"
export RESTIC_PASSWORD="<strong-repo-passphrase>"   # احفظها بأمان وخارج الخادم

# لمرة واحدة: تهيئة المستودع المشفّر
restic init

# تفريغ قاعدة البيانات، ثم نسخ التفريغ + ملفات التطبيق احتياطيًا
mysqldump --single-transaction --routines --triggers \
  -u backup -p"$DB_PASS" appdb > /var/backups/appdb.sql

restic backup /var/backups/appdb.sql /srv/app --tag nightly

# فرض سياسة الاحتفاظ (يبقي التخزين وهدف نقطة الاستعادة منطقيين)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

يجب أن يلبّي تكرار النسخ الاحتياطي هدف نقطة الاستعادة لديك. فإذا كان الهدف ساعة واحدة، جدوِل المهمة كل ساعة عبر cron وتأكّد من اكتمال كل تشغيل داخل الساعة بهامش مريح:

# /etc/cron.d/dr-backup — نسخ احتياطي كل ساعة عند الدقيقة 5
5 * * * * root /usr/local/bin/dr-backup.sh >> /var/log/dr-backup.log 2>&1

ولأهداف نقطة استعادة أكثر تشددًا على قواعد البيانات، استخدم طرقًا مستمرة — شحن سجل MySQL/MariaDB الثنائي (binary-log) أو أرشفة سجل PostgreSQL المسبق للكتابة (WAL) / النسخ المتماثل المتدفق — بدلًا من الاعتماد على اللقطات وحدها.

الخطوة 4: اكتب دليل تشغيل الاستعادة

نسخة احتياطية لا يستطيع أحد استعادتها تحت الضغط عديمة القيمة. وثّق خطوات الاستعادة الدقيقة كدليل تشغيل يمكن لأي شخص مناوب اتباعه:

1. أعلن عن الحادث وأبلغ منسّق التعافي من الكوارث.
2. وفّر بنية الاستعادة (خادم احتياطي أو بيئة استضافة سحابية يمكنك تشغيلها بسرعة).
3. استعِد البيانات من أحدث نسخة احتياطية تم التحقق منها.
4. تحقّق من السلامة، ثم أعِد توجيه الحركة (DNS/موازِن الأحمال).
5. أبلِغ أصحاب المصلحة بالحالة.

والاستعادة من مثال restic أعلاه بسيطة:

# سرد نقاط الاستعادة، ثم استعادة أحدثها إلى مسار مستهدف
restic snapshots
restic restore latest --target /srv/recovery

احتفظ بدليل التشغيل مع الأسماء وأرقام الهواتف ومواقع بيانات الاعتماد — لا بيانات الاعتماد نفسها — في مكان يمكن الوصول إليه حتى لو كانت أنظمتك الرئيسية متوقفة.

الخطوة 5: اختبر، ثم اختبر مرة أخرى

خطط التعافي تتآكل. جدوِل تدريبات استعادة كل ربع سنة على الأقل لأنظمة المستوى 1:

• اختبار على الطاولة: استعراض دليل التشغيل على الورق.
• اختبار استعادة: استعادة نسخة احتياطية فعليًا إلى بيئة معزولة والتأكد من صحة البيانات (هي "الصفر" في 3-2-1-1-0).
• تجاوز فشل كامل: التحويل إلى موقع التعافي والتشغيل عليه.

بعد كل تدريب، قِس وقت الاستعادة وفقدان البيانات الفعليين مقابل هدفي RTO وRPO. وإذا لم تحقّقهما، عالِج الفجوة — نسخ احتياطي أكثر تكرارًا، أو مزيد من الأتمتة، أو احتياطي أكثر دفئًا — ثم أعِد الاختبار.

الخلاصة

خطة التعافي القابلة للتطبيق قصيرة: جدول تصنيف من صفحة واحدة، وأهداف RTO/RPO لكل مستوى، وتصميم نسخ احتياطي 3-2-1-1-0، ودليل تشغيل مختبَر، وجدول تدريبات. ابدأ بأهم أحمال عملك، وأثبِت أن الاستعادة تعمل من البداية إلى النهاية، ثم توسّع مستوى تلو الآخر.

إن أردت نسخًا احتياطية وبنية احتياطية تبقى داخل المملكة لأجل الامتثال لنظام حماية البيانات الشخصية والهيئة الوطنية للأمن السيبراني، استكشف مجموعة النسخ الاحتياطي السحابي للاطلاع على أدلة ذات صلة، أو أنشئ حساب سكايلاين كلاود ووفّر تخزينًا كائنيًا وخوادم سحابية ونسخًا احتياطيًا داخل المملكة في دقائق.