RPO وRTO: كيف تصمّم نسخك الاحتياطي على قدر خسارتك المقبولة

RPO وRTO رقمان يحدّدان شكل نسختك الاحتياطية قبل أن تحدّده أنت. RPO هو نقطة الاسترجاع المقبولة (Recovery Point Objective)، أي كم من البيانات تحتمل فقدها مقاساً بالزمن: لو انهار السيرفر الآن وآخر نسخة قبل ساعة، فأنت خسرت ساعة عمل. RTO هو زمن الاسترجاع المستهدف (Recovery Time Objective)، أي كم من الوقت تحتمل بقاء الخدمة متوقفة حتى تعود. من هذين الرقمين يُشتق كل شيء: كم مرة تأخذ نسخة، وأين تخزّنها، وهل تحتاج نسخة جاهزة للتشغيل الفوري أم يكفي أرشيف يومي. متجر بسيط قد يقبل RPO يوماً كاملاً وRTO بضع ساعات، بينما نظام حجوزات أو منصة مدفوعات لا يحتمل فقد أكثر من دقائق ولا توقفاً يتجاوز نصف ساعة. القاعدة الذهبية هي 3-2-1: ثلاث نسخ من بياناتك، على وسيطين مختلفين، وواحدة خارج الموقع. لكن أخطر فخ ليس في التكرار، بل في نسخة لم تُختبر استعادتها أبداً، فتكتشف يوم الكارثة أنها فاسدة أو ناقصة. في كلاود النسخ الاحتياطي مبني على هذا المنطق: خطة يومية باحتفاظ 7 أيام بـ800 ريال سنوياً، وخطة يومية باحتفاظ 30 يوماً بـ2,000 ريال سنوياً، والاستضافة المُدارة تشمل نسخاً يومياً وأسبوعياً وشهرياً في كل الباقات. بقية المقال يشرح كيف تحوّل RPO وRTO إلى خطة نسخ فعلية، وكيف تختبرها قبل أن تحتاجها.

ماذا يعني RPO بالضبط

RPO يجيب عن سؤال واحد: كم بيانات أقدر أخسر؟ لو كانت الإجابة ساعة، فلازم تأخذ نسخة كل ساعة على الأكثر، لأن أي عطل بين نسختين يضيّع كل ما دخل بينهما. RPO منخفض (دقائق) يتطلب نسخاً متكرراً أو نسخاً مستمراً على مستوى قاعدة البيانات، وهذا أغلى وأثقل. RPO مرتفع (يوم كامل) يكتفي بنسخة يومية واحدة، وهو أرخص وأخف. الخطأ الشائع أن تفترض RPO صفراً للجميع، فتدفع تكلفة ضخمة لبيانات تتحمل فعلياً فقد يوم.

لتحديد RPO الواقعي، اسأل: كم يكلّفني فقد ساعة من البيانات؟ متجر يسجّل طلبات كل دقيقة يختلف عن مدوّنة تُحدَّث أسبوعياً. صنّف بياناتك بطبقات، فقاعدة بيانات الطلبات قد تستحق RPO ساعة، بينما ملفات الوسائط الثابتة تحتمل RPO أسبوعاً.

ماذا يعني RTO بالضبط

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

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

جدول: من RPO/RTO إلى الخطة

الجدول التالي يربط الرقمين بنوع النظام وخطة النسخ المناسبة:

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

قاعدة 3-2-1 والنسخة خارج الموقع

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

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

الفخ الأكبر: نسخة لم تُختبر

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

راقب أيضاً نجاح النسخ نفسه: نسخة تفشل بصمت كل ليلة أخطر من غياب النسخ، لأنها تعطيك طمأنينة زائفة، فعّل تنبيهاً يصلك عند فشل أي نسخة.

أخطاء شائعة في تصميم النسخ الاحتياطي

أكثر خطأ يتكرر هو الخلط بين النسخ الاحتياطي والتكرار (replication). المرآة الحية التي تنسخ كل تغيير فوراً لسيرفر ثانٍ ممتازة للتوافر، لكنها ليست نسخة احتياطية، لأن أي حذف خاطئ أو تلف أو هجوم برمجية فدية ينعكس على المرآة في اللحظة نفسها. النسخة الاحتياطية الحقيقية تحفظ حالات سابقة يمكن الرجوع إليها، بينما التكرار يحفظ الحالة الراهنة فقط، فتحتاج الاثنين لغرضين مختلفين ولا تعتمد أحدهما بديلاً عن الآخر.

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

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

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

ثم حوّل كل رقم إلى إجراء واضح: RPO ساعة يعني جدولة نسخ كل ساعة على الأكثر، وRTO نصف ساعة يعني تجهيز مسار استعادة مؤتمت ومختبَر لا خطوات يدوية طويلة. اكتب هذه الإجراءات في مستند تشغيلي يعرفه فريقك، حتى لا تتحول الاستعادة يوم الحادثة إلى ارتجال تحت الضغط. النسخة الاحتياطية الجيدة نصفها تقنية ونصفها إجراء موثّق يعرف الجميع خطواته مسبقاً.

كيف تربطها بخطتك في كلاود

ابدأ بتحديد RPO وRTO لكل نظام عندك، ثم اختر الخطة التي تحقّقهما بأقل تكلفة زائدة. لموقع يحتمل فقد يوم، تكفي خطة النسخ اليومي باحتفاظ 7 أيام بـ800 ريال سنوياً. لنظام إداري أو متجر، ارفع للاحتفاظ 30 يوماً بـ2,000 ريال سنوياً وأضف نسخاً أكثر تكراراً لقاعدة البيانات. لو استضافتك مُدارة على cPanel، فالنسخ اليومي والأسبوعي والشهري مضمّن في كل الباقات أصلاً. راجع خيارات الخوادم في الخادم السحابي والاستضافة المُدارة في الاستضافة السحابية. الخلاصة: لا تشتري نسخاً احتياطياً بالحدس، اشترِه بالرقمين، ثم اختبره قبل أن تحتاجه.