التعافي من الكوارث في السحابة: RTO وRPO وبناء خطة نسخ احتياطي واقعية

"لدينا نسخة احتياطية" ليست خطة تعافٍ من الكوارث. الفرق بينهما يتحدد بسؤالين دقيقين: كم من الوقت تتحمل التوقف، وكم من البيانات تتحمل خسارتها؟

"لدينا نسخة احتياطية" جملة تطمئن كثيراً من أصحاب الأعمال، لكنها لا تجيب على السؤالين الأهم فعلياً: كم من الوقت سيستغرق استعادة النظام بعد عطل كبير؟ وكم من البيانات ستُفقد نهائياً بين آخر نسخة احتياطية واللحظة الفعلية للعطل؟

RTO: كم من الوقت تتحمل التوقف

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

RPO: كم من البيانات تتحمل خسارتها

• نسخ احتياطي يومي يعني خسارة محتملة تصل لبيانات يوم كامل عند وقوع عطل قبل النسخة التالية مباشرة.
• نسخ احتياطي كل ساعة يقلل هذه الخسارة المحتملة إلى ساعة واحدة، لكن بتكلفة تخزين وتعقيد أعلى.
• التكرار اللحظي (Real-time replication) يقلل الخسارة إلى ثوانٍ، لكنه الخيار الأعلى تكلفة تقنياً.

لا يوجد رقم "صحيح" واحد لكل الأنظمة

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

الاختبار الفعلي، لا الافتراض النظري

خطة تعافٍ لم تُختبر فعلياً هي مجرد افتراض. جدولة تمرين استعادة فعلي (ولو مرة سنوياً) يكشف غالباً فجوات لم تظهر على الورق — صلاحية وصول ناقصة، توثيق قديم، أو خطوة يدوية نُسيت تماماً.

الخلاصة

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