اسأل أي فريق يشغّل Odoo إن كانت لديه نسخ احتياطية، وستكون الإجابة نعم دائماً. لكن اسأله كم من العمل سيخسر لو تعطّلت قاعدة البيانات في الثالثة عصراً، وكم سيمضي قبل أن يستطيع إصدار الفواتير مجدداً، وستصبح الإجابات ضبابية. هذان السؤالان هما الموضوع بأكمله. وكل ما عداهما — أين تُحفظ النسخة، وكم مرة تعمل المهمة، وأي زر يشغّلها — تفاصيل تنفيذية تحتهما.
رقمان يحسمان كل شيء
الأول: كم من البيانات تحتمل خسارته، مقيساً بالزمن. إذا كانت آخر نسخة سليمة من الثانية فجراً ووقع العطل في الثالثة عصراً، فقد خسرت يوماً كاملاً من الطلبات والمدفوعات وحركات المخزون، وستقضي الأسبوع التالي في إعادة بنائها من البريد والذاكرة. والثاني: كم من التوقف تحتمل. بالنسبة لشركة خدمات مهنية، بضع ساعات إزعاج. أما لمستودع يشحن في اليوم نفسه أو سلسلة تجزئة في وسط حملة ترويجية، فهو إيراد لا يعود.
دوّن الرقمين قبل أن تقيّم أي ترتيب استضافة، لأنهما يحددان ما تحتاج شراءه فعلاً. فالشركة التي تستوعب خسارة يوم وتوقف يوم تحتاج شيئاً مختلفاً تماماً عن شركة لا تحتمل خسارة ساعة، ودفع ثمن الثاني وأنت تحتاج الأول خطأ بقدر العكس.
أين تفشل النسخة الليلية بصمت
النسخة الليلية تجيب عن سؤال «هل لدينا نسخة احتياطية؟» بنعم، وتجيب عن سؤال «كم سنخسر؟» بعبارة «حتى أربع وعشرين ساعة». وتبقى هذه الفجوة غير مرئية حتى اليوم الذي تهم فيه.
الاسترجاع إلى نقطة زمنية محددة هو ما يغلق هذه الفجوة. فبدلاً من العودة إلى لقطة الليلة الماضية، تعيد قاعدة البيانات إلى لحظة تختارها أنت: خمس دقائق قبل الاستيراد الخاطئ، أو اللحظة التي سبقت تنفيذ تحديث جماعي بمُرشِّح خاطئ. واستضافة Plemo المُدارة تشغّل نسخاً احتياطية آلية مع استرجاع إلى نقطة زمنية محددة لهذا السبب تحديداً؛ فمعظم الحوادث الحقيقية ليست أعطالاً في العتاد، بل تصرفات بشرية لها توقيت دقيق، وقيمة نقطة الاسترجاع أنها تستطيع أن تقف قبل ذلك التوقيت مباشرة.
أما الفشل الصامت الثاني فهو مخزن الملفات. Odoo يحتفظ بالمرفقات — العقود الموقّعة وملفات الفواتير وأذون التسليم الممسوحة — خارج قاعدة البيانات نفسها. والنسخة التي التقطت قاعدة البيانات وحدها تُرجع لك نظاماً كل روابط مستنداته مكسورة، وهو أمر تكتشفه في أسوأ لحظة ممكنة. اسأل صراحةً هل المرفقات مشمولة، وتأكد بفتح مستند واحد بعد استرجاع تجريبي.
الاسترجاع الذي لم تتمرن عليه مجرد تخمين
مهام النسخ الاحتياطي تُبلّغ عن نفسها. والحالة الخضراء تعني أن المهمة عملت، لا أن الأرشيف قابل للقراءة، ولا أن الاسترجاع يتم داخل مدة التوقف التي افترضتها، ولا أن من كان يعرف الإجراء ما زال يعمل معك.
الطريقة الوحيدة للمعرفة هي الاسترجاع في مكان ليس بيئة الإنتاج. وبيئات staging وsandbox تحوّل ذلك إلى تمرين روتيني بدل أن يكون تجربة وقت الأزمة: تسترجع نسخة حديثة في بيئة منفصلة، وتقيس الزمن، وتفتح بضعة تقارير، وتتأكد أن المرفقات تعمل. افعلها مرة واحدة تكن قد استبدلت بالافتراض رقماً مقيساً. وافعلها مرتين في العام يبقَ الرقم صحيحاً مع نمو بياناتك.
وهذا النمو هو ما تستهين به الفرق عادة. فقاعدة بيانات بحجم 5 غيغابايت وأخرى بحجم 300 غيغابايت لا تتصرفان بالطريقة نفسها، والثانية هي التي تتحول فيها عبارة «سنسترجعها ببساطة» إلى ظهيرة طويلة جداً.
ما الذي تتحقق منه مع أي مزود استضافة Odoo
- هل يمكن الاسترجاع إلى أي نقطة زمنية تختارها، أم إلى آخر لقطة مجدولة فقط؟
- هل المرفقات ومخزن الملفات مشمولان، وهل يفتح النظام المسترجَع مستنداته فعلاً؟
- كم يستغرق الاسترجاع الكامل لقاعدة بياناتك أنت؟ اطلب رقماً مقيساً على حجمك، لا طمأنة عامة.
- هل يستطيع فريقك التمرن على الاسترجاع في بيئة staging دون تذكرة دعم ودون المساس بالإنتاج؟
- من ينفذ الاسترجاع في الثانية فجراً في يوم عطلة رسمية، وكيف تصل إليه؟
- متى جرى آخر استرجاع فعلي من هذه النسخ، أياً كان منفذه؟
السؤال الأخير يفرز المزودين أسرع من أي قائمة ميزات. فالمزود الذي يسترجع بانتظام يجيب عنه فوراً.
الجزء الذي لا تقرره الاستضافة عنك
الاستضافة المُدارة تتولى الميكانيكا: النسخ تعمل، ونقاط الاسترجاع موجودة، والمراقبة قائمة، والبيئات متاحة للاختبار فيها. لكنها لا تستطيع أن تقرر كم من الخسارة والتوقف تقبله شركتك، ولا أن تعرف أن إقفال نهاية الشهر صار عندك النافذة التي يكلف فيها الانقطاع عشرة أضعاف ما يكلفه في يوم ثلاثاء عادي. هذه قرارات تشغيلية، ومكانها عند من يملك العملية.
وإن أردت أن تُدار الميكانيكا بينما تبقى القرارات عند فريقك، فهذا هو شكل استضافة Plemo المُدارة وعملنا في الدعم المُدار وSLA. والنسخة المفيدة من هذه المحادثة تبدأ برقميك أنت، لا بقائمة ميزات.