النسخ الاحتياطي للأنظمة لا يعني وجود ملف مضغوط يحمل تاريخ الأمس. النسخة تصبح مفيدة فقط إذا كانت تشمل البيانات اللازمة، ومحفوظة خارج نقطة العطل، ومحمية من التعديل، ويمكن استعادتها خلال زمن يقبله العمل. أما استمرارية الأعمال فهي الخطة التي تحدد كيف يعمل الفريق ويتواصل ويتخذ القرار إلى أن تعود الخدمة.
هذا الدليل موجه للأنظمة الصغيرة التي لا تملك مركز عمليات كبيراً، لكنه لا يفترض أن بياناتها قليلة القيمة. عيادة أو متجر أو مركز تعليمي قد يعتمد كلياً على نظام واحد، ولذلك يحتاج خطة بسيطة ومكتوبة ومجربة.
ابدأ بجرد ما يجب استعادته
اكتب مكونات الخدمة: قاعدة البيانات، والملفات والمرفقات، وإعدادات التطبيق، والأسرار ومفاتيح التشفير، وقواعد DNS، والشهادات، والمهام المجدولة، ومستودع الكود، وتوثيق البنية. نسخ قاعدة البيانات وحدها قد يعيد السجلات دون صور أو مستندات، ونسخ الملفات دون المفتاح قد يجعلها غير قابلة للقراءة.
حدد مالك كل مكون ومكانه وطريقة تصديره. لا تحفظ كلمات المرور داخل الوثيقة؛ احفظ طريقة الوصول الآمن ومن يوافق عليه. حدّث الجرد عند إضافة مزود أو تكامل.
حدّد RPO وRTO بلغة العمل
RPO هو مقدار البيانات التي يستطيع العمل تحمل فقدها زمنياً. إذا كانت النسخة كل ليلة، فقد تضيع تغييرات يوم كامل عند عطل قبل النسخ التالي. RTO هو الزمن المقبول لإعادة الخدمة أو بديل عملي. لا تختَر الرقم من قالب تقني؛ اسأل ماذا يحدث للمواعيد أو الطلبات إذا توقف النظام ساعتين أو يوماً.
قد تختلف الأهداف بين المكونات. صفحة تسويقية يمكن أن تنتظر، بينما جدول المواعيد أو أوامر العمل يحتاج مساراً أسرع. وثّق الأولويات ليعرف الفريق ما يستعيد أولاً.
استخدم طبقات منفصلة للنسخ
القاعدة المعروفة 3-2-1 نقطة تخطيط مفيدة: أكثر من نسخة، وعلى نوع تخزين مختلف، ونسخة خارج الموقع الأساسي. المهم ليس ترديد الرقم، بل منع حادث واحد أو حساب مخترق من حذف الأصل والنسخ معاً. استخدم حساباً أو صلاحية منفصلة للنسخ، وفعّل حماية من الحذف أو نسخاً غير قابلة للتعديل عندما تتوفر.
لا تجعل الخادم نفسه يحتفظ بالنسخة الوحيدة. فشل القرص أو اختراق الحساب قد يصيب الاثنين. وراقب اكتمال النسخ وحجمها؛ مهمة مجدولة تُرجع نجاحاً بينما تنتج ملفاً فارغاً ليست حماية.
انسخ قاعدة البيانات بطريقة متسقة
النسخ عبر نسخ ملفات قاعدة حية قد ينتج حالة غير صالحة. استخدم أدوات المحرك أو لقطات متسقة، وسجل إصدار قاعدة البيانات وطريقة الاستعادة. للأنظمة ذات الكتابة المستمرة، قيّم نسخاً دورية مع سجل معاملات يحقق RPO المطلوب.
شفّر النسخ أثناء النقل والتخزين، لكن افصل مفتاح التشفير عن الملف. اختبر أن الشخص المخول يستطيع الوصول إلى المفتاح في حالة طوارئ من دون الاعتماد على حساب الموظف الغائب.
لا تنسَ الملفات والخدمات الخارجية
المرفقات في object storage، والبريد، ومنصة الدفع، ونظام الفوترة، وخدمة الهوية قد تحتفظ بجزء من الحقيقة. افهم ما يمكنك استعادته منها وما يبقى مسؤوليتك. لا تفترض أن مزود SaaS يقدم تصديراً أو استعادة بنقطة زمنية لمجرد أنه مستضاف في السحابة.
راجع العقود وسياسات الاحتفاظ، ونفذ تصديراً تجريبياً للبيانات الحرجة. يمكن الاستفادة من دليل ملكية بيانات SaaS لبناء أسئلة الخروج والاستعادة.
اختبار الاستعادة هو الاختبار الحقيقي
مرة وفق تكرار يناسب الخطر، أنشئ بيئة معزولة واستعد نسخة كاملة. تحقق من عدد السجلات، وعينات العلاقات، وفتح الملفات، وتسجيل الدخول، وتشغيل المسار الحرج. سجّل الزمن والخطوات والأخطاء، ثم حدّث الدليل.
لا تستعد فوق الإنتاج للتجربة. استخدم بيئة منفصلة وبيانات محمية، وامنع الإشعارات أو الدفعات الحقيقية من الانطلاق أثناء الاختبار. يجب أن يثبت الاختبار أن النسخة قابلة للاستخدام، لا أن الملف يمكن تنزيله فقط.
اكتب دليل استعادة يستطيع شخص آخر تنفيذه
يشمل الدليل كيف يُعلن الحادث، ومن يقود، وكيف تُقيّم سلامة البيئة، وأين توجد النسخ، وكيف تُنشأ بنية بديلة، وترتيب الاستعادة، وكيف يُتحقق من النتيجة، ومن يوافق على إعادة الفتح. أضف أوامر أو روابط دقيقة، لكن لا تضع أسراراً مباشرة.
اختبر الدليل مع شخص لم يكتبه. إذا احتاج إلى معرفة غير موثقة في رأس المطور، فالخطة غير مكتملة. تحتفظ خدمة الصيانة والدعم بمثل هذه الإجراءات ضمن مسؤولية تشغيل واضحة.
فرّق بين العطل والاختراق
في عطل بنية عادي قد تكون أحدث نسخة سليمة. في اختراق، ربما تحتوي النسخة الحديثة على التغيير الضار أو يكون المهاجم ما زال يملك الوصول. عندها يجب عزل البيئة، وحفظ الأدلة، وتدوير الأسرار، وتحديد نقطة نظيفة، ومراجعة الحسابات قبل الاستعادة.
لا تعِد تشغيل النظام بسرعة على نفس البيئة غير المفحوصة. الاستمرارية لا تعني إعادة الخطر. ضع مسار تصعيد لمختص أمني عندما توجد مؤشرات اختراق.
جهّز وضع عمل يدوي محدود
حدّد ما يستطيع الفريق فعله دون النظام: استقبال بيانات الحد الأدنى في نموذج مراقب، وإعطاء أرقام مرجعية، وتأجيل العمليات التي لا يمكن التحقق منها، ثم إدخالها بعد العودة مع مراجعة تمنع التكرار. لا تستخدم أوراقاً أو أجهزة شخصية لبيانات حساسة بلا ضوابط.
اطبع أو احفظ خارج النظام قائمة الاتصال، وحالة المواعيد القريبة عند الحاجة، وتعليمات التواصل. راجع هذا الوضع مع الموظفين حتى لا يكون أول استخدام له أثناء الضغط.
صمّم التواصل أثناء الحادث
عيّن قناة داخلية ومالك تحديث، وحدد متى يحتاج العملاء إلى إشعار وما الذي يمكن قوله بثقة. تجنب تقدير عودة غير مؤكد. اذكر الأثر المعروف والإجراء المؤقت ووقت التحديث التالي. حافظ على سجل زمني للقرارات.
بعد العودة، أخبر المعنيين بما تم استعادته وأي بيانات تحتاج تحققاً. الشفافية المنضبطة أفضل من الصمت أو الوعود المتغيرة.
راقب النسخ كخدمة حية
أنشئ تنبيهاً لفشل المهمة وتأخر آخر نسخة وتغير الحجم غير المعتاد وانتهاء مساحة التخزين. يجب أن يصل التنبيه إلى أكثر من شخص وأن ينتج عنه إجراء. راجع الوصول دورياً، وألغ حسابات الموظفين والموردين السابقين.
اجعل تقرير النسخ يوضح آخر نسخة ناجحة لكل مكون وآخر اختبار استعادة ونتيجته. المؤشر الأخضر دون اختبار قد يعطي ثقة زائفة.
جدول صغير للمسؤوليات
عيّن مسؤول قرار الحادث، ومسؤول البنية، ومسؤول التحقق من البيانات، ومسؤول التواصل، وبدلاءهم. قد يؤدي شخص واحد أكثر من دور في شركة صغيرة، لكن الأسماء يجب أن تكون معروفة. حدد كذلك من يملك صلاحية حذف النسخ ومن يراجع هذا الفعل.
راجع الخطة بعد تغيير كبير أو حادث أو انتقال موظف رئيسي. وتأكد أن الوصول الطارئ لا يعتمد على جهاز واحد أو حساب فردي.
من النسخة إلى الاستمرارية
توضح صفحة التقنية مبادئ الاستضافة والبيانات، لكن كل نظام يحتاج أهدافاً تناسب عملياته. ابدأ هذا الأسبوع بجرد من صفحة واحدة، واستعادة تجريبية، وقائمة اتصال. ثم عالج الفجوات بالترتيب: نسخة خارج نقطة العطل، حماية الوصول، مراقبة، ودليل استعادة.
الخاتمة: اسأل «متى استعدنا آخر مرة؟»
السؤال الأقوى ليس «هل لدينا نسخ احتياطي؟» بل «متى استعدنا نظاماً كاملاً من هذه النسخة، ومن نفذ الخطوات، وكم استغرق؟». إذا لم توجد إجابة، فالمشروع التالي واضح. يمكن طلب مراجعة صيانة واستمرارية تخرج بخريطة أصول واختبار استعادة وخطة مسؤوليات، لا بوعد عام أن كل شيء محفوظ.
