نقطة التعافي المستهدفة (RPO) وزمن التعافي المستهدف (RTO) هما هدفا التعافي اللذان يُحددان لكل نظام. فـ RPO هي أقصى قدر من البيانات، مقيساً بالزمن، تقبل فقدانه في حادث، وRTO هو أطول مدة يمكن أن يبقى فيها النظام متوقفاً قبل أن يصبح الأثر غير مقبول. ومعاً يحددان عدد مرات نسخ البيانات المطلوبة وسرعة استعادة الخدمة.
تعريفا RPO وRTO جنباً إلى جنب
| الجانب | نقطة التعافي وزمن التعافي متفق عليهما لكل نظام مع الأعمال، وترتيبات مصممة لتحقيقهما لا مجرد أمل. | يجب عادةً أن يكون RTO أقصر من أقصى مدة توقف مقبولة (MTD)، أما RPO فمقياس مستقل. ويعرّف NIST مدة التوقف المقبولة القصوى بأنها إجمالي الانقطاع الذي يقبله مالك النظام لإجراء أعمال، مع احتساب كل الآثار. ويجب أن يكون RTO أقصر لأن عملاً يبقى بعد عودة النظام، مثل التحقق من البيانات وإعادة تنفيذ المعاملات ومعالجة المتراكم. وتتعلق RPO بفقد البيانات لا بزمن التوقف، فلا تدخل في احتساب MTD. |
|---|---|---|
| السؤال الذي يجيب عنه | ما مقدار البيانات الحديثة الذي نتحمل فقدانه؟ | كم يمكن أن يتوقف هذا النظام؟ |
| يُقاس بـ | الزمن بين آخر نسخة قابلة للاستعادة والعطل. | الزمن من العطل حتى يعود النظام إلى العمل. |
| يصفه دليل NIST SP 800-34 بأنه | النقطة الزمنية التي يمكن استعادة البيانات إليها بناءً على أحدث نسخة احتياطية. | أقصى مدة يمكن أن يكون فيها مورد النظام غير متاح قبل أن يصبح الأثر غير مقبول. |
| ما الذي يحدده أساساً | عدد مرات النسخ الاحتياطي للبيانات أو نسخها المتماثل. | طريقة التعافي ومقدار القدرة الاحتياطية الجاهزة. |
| خطأ شائع | افتراض أن النسخ الاحتياطي الليلي يحقق RPO صغيرة، بينما قد يعني فقدان معظم يوم. | ذكر هدف لم يُقس زمنه قط في اختبار استعادة. |
التعريفات مأخوذة من NIST SP 800-34 Rev. 1، دليل التخطيط للطوارئ لأنظمة المعلومات الأمريكي (مايو 2010، المحدّث في 11 نوفمبر 2010)، حيث تقع ضمن تحليل الأثر على الأعمال. ويعرّفهما دليل التعافي من الكوارث لدى Google Cloud بشكل شبه مطابق للتطبيقات. ويعامل NIST الهدفين كأهداف تُحدد لكل مورد نظام وإجراء أعمال، لا مرة واحدة للمنشأة كلها.
ما العلاقة بين RTO وRPO وأقصى مدة توقف مقبولة؟
يجب عادةً أن يكون RTO أقصر من أقصى مدة توقف مقبولة (MTD)، أما RPO فمقياس مستقل. ويعرّف NIST مدة التوقف المقبولة القصوى بأنها إجمالي الانقطاع الذي يقبله مالك النظام لإجراء أعمال، مع احتساب كل الآثار. ويجب أن يكون RTO أقصر لأن عملاً يبقى بعد عودة النظام، مثل التحقق من البيانات وإعادة تنفيذ المعاملات ومعالجة المتراكم. وتتعلق RPO بفقد البيانات لا بزمن التوقف، فلا تدخل في احتساب MTD.
يقبل مالك الإجراء من جهة الأعمال مدة التوقف القصوى وفقد البيانات. ومهمة تقنية المعلومات أن توضح أزمنة التعافي ونوافذ فقد البيانات التي يستطيع كل تصميم تحقيقها فعلاً، وما يتطلبه كل منها. لذا يحمل التعريف الكامل لـ RPO وRTO في الخطة اسم المالك وتاريخ الاتفاق.
مثال محسوب لـ RPO وRTO لنظام طلبات
هذه حالة افتراضية، والأرقام مفترضة للتوضيح وليست معايير أو توصيات. موزّع يستقبل طلبات العملاء في تطبيق واحد ويعد بالتسليم في اليوم التالي، والخطوات أدناه تحدد RPO وRTO لهذا التطبيق.
- حدد مدة التوقف القصوى. يقول مديرو العمليات إن وعود التسليم في اليوم التالي تبدأ بالإخفاق بعد 8 ساعات دون إدخال طلبات. فمدة التوقف القصوى 8 ساعات.
- حدد RTO. بعد التعافي يحتاج الموظفون إلى نحو 3 ساعات لإعادة إدخال الطلبات من سجل مركز الاتصال والتحقق من المخزون. فيتبقى 5 ساعات، ويحدد الفريق RTO بـ 4 ساعات للإبقاء على هامش.
- حدد RPO. تُسجَّل الطلبات الهاتفية بشكل منفصل، فيمكن إعادة إدخال طلبات آخر 30 دقيقة، وما هو أقدم لا يمكن إعادة بنائه بشكل موثوق. فـ RPO هي 30 دقيقة.
- قارن بالوضع الحالي. نسخة احتياطية واحدة في الساعة 01:00 كل ليلة تعني أن انقطاعاً في الساعة 00:59 يُفقد قرابة 24 ساعة من الطلبات. واستغرق آخر اختبار استعادة 9 ساعات. والنتيجتان لا تحققان الهدفين.
- سدّ الفجوة. تحقيق RPO بـ 30 دقيقة يحتاج إلى نسخ للبيانات، مثل شحن سجلات المعاملات أو النسخ المتماثل، بفواصل لا تتجاوز 30 دقيقة. وتحقيق RTO بـ 4 ساعات يحتاج غالباً إلى بيئة احتياطية مجهزة مسبقاً بدلاً من إعادة البناء من النسخة الاحتياطية. اطلب خيارات مسعّرة لكل هدف، لأن كل تشديد يضيف تكلفة وجهداً.
- اختبر وسجّل. نفّذ عملية تعافٍ، وقِس زمنها مقابل RTO، وتحقق من مقدار البيانات المستعادة مقابل RPO، وكرر ذلك بعد أي تغيير.
أي نهج تعافٍ يناسب أي أهداف RPO وRTO؟
يناسب النسخ الاحتياطي والاستعادة أطول تحمّل لـ RPO وRTO، بينما تناسب الإضاءة التجريبية (Pilot Light) والاستعداد الدافئ (Warm Standby) والتشغيل النشط في عدة مواقع أهدافاً أقصر تدريجياً. فالأهداف الأقصر تحتاج إلى قدرة احتياطية أكبر ونسخ أكثر تكراراً، وترتفع التكلفة معها. ويتبع الجدول الاستراتيجيات الأربع في الورقة البيضاء للتعافي من الكوارث لدى AWS. ويصف NIST نطاقاً مماثلاً من المواقع البديلة، من الباردة إلى المتطابقة. وتُعرض التكلفة كترتيب نسبي فقط، لأن الأرقام الحقيقية تعتمد على حجم البيانات والتصميم والتراخيص والمزود.
| الأهداف | فئة النهج | ما يُبقى جاهزاً | التكلفة والجهد النسبيان |
|---|---|---|---|
| أطول توقف وأكبر فقد بيانات مقبولان | النسخ الاحتياطي والاستعادة | نسخ احتياطية محفوظة بشكل منفصل، وتُعاد بناء الأنظمة واستعادة البيانات بعد الحادث. | أقل تكلفة وتعقيد. |
| تعافٍ أقصر وفقد بيانات قليل | الإضاءة التجريبية (Pilot Light) | بيانات تُنسخ باستمرار وبنية أساسية تعمل، مع إيقاف خوادم التطبيقات حتى الحاجة إليها. | أعلى من النسخ الاحتياطي والاستعادة. |
| تعافٍ قصير | الاستعداد الدافئ (Warm Standby) | نسخة مصغّرة لكنها عاملة من حمل العمل تعمل طوال الوقت، وتُوسَّع عند التحويل. | أعلى من ذلك. |
| زمن تعافٍ وفقد بيانات يقاربان الصفر | تشغيل نشط في عدة مواقع (Active/Active) | يعمل حمل العمل في أكثر من موقع في الوقت نفسه. | أعلى تكلفة وتعقيد. |
وتصنيف NIST مشابه، إذ يربط جدوله 3-2 الأنظمة الأقل أثراً بالنسخ الاحتياطي على الأشرطة والمواقع الباردة، والأنظمة عالية الأثر بالأنظمة المتطابقة والمواقع الساخنة. والنسخ المتماثل ينسخ عمليات الحذف والتلف بدقة نسخه للبيانات السليمة نفسها، لذا تحتفظ تصاميم كثيرة بنسخ احتياطية لنقاط زمنية إلى جانبه.
أين تخطئ خطط التعافي عادةً؟
- تحدد تقنية المعلومات الأرقام وحدها. يجب أن يقبل مالك الأعمال التوقف وفقد البيانات، فتحتاج الأهداف إلى اعتماده.
- هدف واحد لكل شيء. قاعدة بيانات الرواتب والشبكة الداخلية لا تحتاجان إلى RTO نفسه. صنّف الأنظمة حسب الأثر ليذهب النهج المكلف فقط حيث يبرره الأثر.
- لا يُختبر RPO وRTO أبداً. زمن التعافي الحقيقي مجهول حتى يقيسه أحد، وتدعو AWS وGoogle Cloud وNIST جميعها إلى اختبار خطط التعافي بانتظام.
- إغفال الاعتماديات. التطبيق المستعاد الذي لا يصل إلى خدمة الهوية أو DNS أو الشبكة لم يتعافَ فعلاً.
هل تحدد الأنظمة السعودية قيماً لـ RPO أو RTO؟
ليس في ضوابط الهيئة الوطنية للأمن السيبراني التي راجعناها. فالضابط 3-1-3 في ECC-2:2024 يُلزم الجهات المشمولة بتضمين إعداد خطط التعافي من الكوارث في متطلبات الأمن السيبراني لاستمرارية الأعمال، لكن ضوابط هذا المكون الفرعي لا تحدد قيماً رقمية لـ RPO وRTO، فالأهداف لك أن تحددها وتدافع عنها. وتنطبق الضوابط على الجهات الحكومية والجهات التابعة لها وعلى ملاك البنى التحتية الوطنية الحساسة ومشغليها ومستضيفيها، وتشجع الهيئة الجهات الأخرى على تطبيقها. وقد تضيف الجهات التنظيمية القطاعية متطلبات خاصة بها، فتحقق من متطلبات قطاعك.
أما موقع نسخة التعافي فمسألة منفصلة، فهي تحمل البيانات نفسها التي في بيئة الإنتاج، فتنطبق عليها قواعد الموقع التي يتناولها مقال إقامة البيانات في السعودية. وإن كنت تدير استمرارية الأعمال وفق ISO 22301:2019، المعيار الدولي لأنظمة إدارة استمرارية الأعمال، فتعامل مع RPO وRTO كمدخلات لهذا النظام الأوسع لا كإعداد تقني.
تغطي وسنا للحلول الرقمية تخطيط التعافي من الكوارث، بما في ذلك تحديد RPO وRTO واختبار التعافي، ضمن أعمال الافتراضية والحوسبة الطرفية والتعافي من الكوارث.
قارن أهداف التعافي بما تستطيع نسخك الاحتياطية تحقيقه فعلاً
أرسل لنا أنظمتك الرئيسية، وكيف يُنسخ احتياطياً منها حالياً، وآخر مرة قاس فيها أحد زمن الاستعادة. وسيعود إليك مستشار من وسنا للحلول الرقمية بالأسئلة التي تحدد الأهداف والخيارات.
راجع أهداف RPO وRTO لديكالمصادر
- Contingency Planning Guide for Federal Information Systems، NIST SP 800-34 Rev. 1 (مايو 2010، المحدّث في 11 نوفمبر 2010). المعهد الوطني للمعايير والتقنية الأمريكي. csrc.nist.gov؛ النص الكامل nvlpubs.nist.gov. تاريخ الاطلاع: 2 أكتوبر 2026.
- Disaster recovery planning guide (آخر مراجعة 5 يوليو 2024). وثائق Google Cloud. docs.cloud.google.com. تاريخ الاطلاع: 2 أكتوبر 2026.
- Disaster Recovery of Workloads on AWS: Disaster recovery options in the cloud. وثائق Amazon Web Services. docs.aws.amazon.com. تاريخ الاطلاع: 2 أكتوبر 2026.
- الضوابط الأساسية للأمن السيبراني (ECC-2:2024). الهيئة الوطنية للأمن السيبراني. cdn.nca.gov.sa. تاريخ الاطلاع: 2 أكتوبر 2026.
- ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements. المنظمة الدولية للمعايير. iso.org. تاريخ الاطلاع: 2 أكتوبر 2026.
