النسخ الاحتياطي لنظام التذاكر خطةٌ تحدّد ما يُنسخ وكم مرة وأين يُخزَّن وكيف يُسترجَع ومن يملك القرار. يُقاس بمؤشرين: RPO أي أقصى قدر بيانات يُقبل فقدانه، وRTO أي أقصى زمن توقّف مقبول. القاعدة الحاكمة: النسخة غير المختبَرة ليست نسخة احتياطية — هي افتراض لم يُتحقَّق منه.
نظام التذاكر يُصنَّف عادةً كنظام مساند، ثم يتوقّف يومًا كاملًا فتكتشف الجهة أنها لا تعرف من طلب ماذا، ولا ما تعهّدت به لعملائها، ولا أين وصلت الطلبات المفتوحة. مركز الدعم بلا نظام تذاكر لا يعمل ببطء — يعمل عشوائيًّا.
وأخطر ما في هذا الملف أن الجميع يملك نسخًا احتياطية، وقليل جدًّا ممن اختبر استرجاعها. هذا المقال عن الفرق بين الاثنين.
المؤشران اللذان يحكمان كل شيء
قبل اختيار أي أداة أو دورية، حدّد رقمين. كل قرار تقني لاحق مشتقّ منهما، وأي نقاش عن النسخ الاحتياطي قبل تحديدهما نقاش بلا مرجع يُحتكم إليه.
الخطأ الشائع أن يُحدَّد الرقمان في اجتماع تقني منفرد. الرقم صفر مطلوب دائمًا وغير قابل للتمويل غالبًا؛ والرقم المرتفع رخيص وقد يعطّل العمل يومًا كاملًا. القرار عملٌ مشترك بين التقنية وصاحب الخدمة، لأنه في جوهره قرار كلفة مقابل مخاطرة لا قرار هندسي.
ما الذي يجب نسخه فعلًا؟
«ننسخ قاعدة البيانات» إجابة ناقصة تنكشف عند أول استرجاع حقيقي: تعود التذاكر وتغيب المرفقات، أو يعمل النظام بلا قواعد الأتمتة، أو تعود البيانات بلا مستخدمين يستطيعون الدخول.
| المكوّن | الأهمية | ملاحظة |
|---|---|---|
| قاعدة البيانات | حرجة | التذاكر والردود والمستخدمون — واضح ونادرًا ما يُنسى |
| المرفقات | حرجة | غالبًا في تخزين منفصل بخطة نسخ مختلفة — وأشيع ما يُنسى |
| الإعدادات وقواعد الأتمتة | عالية | إعادة بنائها يدويًّا قد تستغرق أيامًا وتُنتج نظامًا مختلفًا |
| سجلات التدقيق | عالية | فقدانها يعني فقدان قدرتك على التحقيق فيما قبل العطل |
| قوالب النماذج والردود | متوسطة | عمل تراكمي لسنوات يصعب استعادته من الذاكرة |
| قاعدة المعرفة | متوسطة | قد تكون في نظام منفصل بخطة نسخ منفصلة |
| مفاتيح التكامل والأسرار | عالية | تُدار في خزنة أسرار لا في النسخة نفسها — لكن يجب أن تكون مستردّة |
| الشهادات الرقمية | أساسية | قابلة لإعادة الإصدار، لكنها تُبطئ التعافي إن غابت |
الصف الثاني هو الفخّ الأشهر. المرفقات غالبًا في تخزين كائنات منفصل، وخطة نسخه قد تكون أُعدَّت من فريق آخر بدورية مختلفة — أو لم تُعدّ أصلًا. النتيجة: استرجاع «ناجح» يعيد أربعين ألف تذكرة تشير كلها إلى مرفقات غير موجودة.
حماية النسخ نفسها
النسخة الاحتياطية أصلٌ خطر بطبيعته: نسخة كاملة من بياناتك، تُخزَّن غالبًا بضوابط أضعف من الإنتاج، ويصل إليها أشخاص لا يصلون للنظام نفسه. وهي في الوقت ذاته الهدف الأول لبرامج الفدية — فالمهاجم الذي يشفّر بياناتك ويترك نسخك سليمة لا يملك ورقة ضغط.
- النسخ مشفَّرة أثناء التخزين والنقل — لا تفترض ذلك، تحقّق منه صراحةً؛ النسخة قد تُكتب خامًا بينما القاعدة الحيّة مشفَّرة.
- نسخة واحدة على الأقل غير قابلة للتعديل أو الحذف خلال مدة محدّدة، بأي صلاحية كانت.
- نسخة معزولة عن الشبكة أو في حساب منفصل تمامًا لا تصل إليه بيانات اعتماد الإنتاج.
- صلاحيات النسخ الاحتياطية منفصلة عن صلاحيات نظام التذاكر — من يدير النظام لا يجب أن يملك حذف نسخه.
- حذف النسخ يتطلّب موافقة مزدوجة ويُسجَّل في سجل التدقيق كحدث حرج.
- مراقبة فعلية لنجاح مهام النسخ — والأهم: تنبيه عند الفشل. مهمة تفشل بصمت شهرين أسوأ من غياب النسخ، لأنها تمنح طمأنينة كاذبة.
- مواقع تخزين النسخ متوافقة مع قرارك بشأن موضع البيانات — النسخة بيانات كاملة لا استثناء لها.
- سجل بمن وصل إلى النسخ ومتى؛ الوصول إليها حدث يستحق التدقيق كأي وصول للإنتاج.
وهنا تعارض عملي جدير بالانتباه: سياسة الاحتفاظ تقتضي حذف بيانات بلغت أجلها، والنسخ الاحتياطية تحتفظ بها. حذف تذكرة من الإنتاج لا يحذفها من نسخة عمرها ستة أشهر. عالج هذا صراحةً في سياستك — بمواءمة دورة النسخ مع مدد الحذف — لا بتجاهله. التفصيل في سياسة الاحتفاظ ببيانات التذاكر وحذفها.
الاختبار: الجزء الذي يُتجاهَل دائمًا
هذه أهم فقرة في المقال. النسخة التي لم تُسترجَع ليست نسخة احتياطية — هي ملف تفترض أنه سيعمل. والافتراض يُختبر مرة واحدة: أثناء الكارثة، وهي أسوأ لحظة ممكنة لاكتشاف أنه خاطئ.
الخطوة الرابعة تكشف فجوة تنظيمية لا تقنية: خطة تعافٍ يعرفها شخص واحد ليست خطة، بل نقطة فشل واحدة تمشي على قدمين. وثّق الإجراء بتفصيل يكفي لتنفيذه من فنّي لم يبنِ النظام، تحت ضغط، في الثالثة فجرًا.
وإن كنت تشغّل نظام تذاكر سحابيًّا، فمسؤولية النسخ مشتركة لا منقولة: المزوّد يحمي البنية، وأنت تحتاج نسخة خاصة بك تحت سيطرتك تحسّبًا لإنهاء العقد أو خطأ بشري أو خلاف تعاقدي. القائمة الكاملة لما تسأله في أسئلة الأمن والخصوصية لمزوّد النظام، ويمكن مراجعة قدرات منصة TixDesk في هذا الجانب.
الأسئلة الشائعة
هل النسخ الاحتياطي مسؤولية المزوّد في النظام السحابي؟
مسؤولية مشتركة لا منقولة. المزوّد ينسخ البنية التحتية عادةً، لكن ذلك لا يغطّي حذفًا خاطئًا من مستخدم لديك، ولا خلافًا تعاقديًّا، ولا رغبتك في الانتقال لمزوّد آخر. اسأل صراحةً: ما الذي تنسخونه، وبأي دورية، وكم مدة الاحتفاظ، وكيف أطلب استرجاعًا، وهل أستطيع تصدير نسختي الخاصة بانتظام؟
ما الفرق بين النسخ الاحتياطي والتوافر العالي (High Availability)؟
مختلفان تمامًا ولا يُغني أحدهما عن الآخر. التوافر العالي يحميك من عطل مكوّن — يتحوّل الحمل لخادم آخر بلا انقطاع. النسخ الاحتياطي يحميك من فساد البيانات أو حذفها أو تشفيرها. المفارقة: التوافر العالي ينسخ الخطأ فورًا إلى كل النسخ — إن حُذفت البيانات أو شُفّرت بفدية، ستنتشر الكارثة في الوقت الحقيقي. تحتاجهما معًا.
كم مدة الاحتفاظ المناسبة بالنسخ الاحتياطية؟
لا يوجد رقم صحيح عالميًّا. المدة تُشتقّ من ثلاثة قيود متعارضة: قدرتك على اكتشاف مشكلة متأخرة (تدفع للإطالة)، وكلفة التخزين (تدفع للتقصير)، ومبدأ عدم الاحتفاظ بالبيانات الشخصية بلا مسوّغ (يدفع للتقصير). الممارسة الشائعة تدرّج الاحتفاظ: نسخ متقاربة قصيرة المدى، وأقل تواترًا لمدى أطول.
هل يجب أن تكون النسخ في منطقة جغرافية مختلفة؟
هنا يتقاطع مطلبان. الفصل الجغرافي يحميك من كارثة تصيب موقعًا كاملًا، وهو مبدأ سليم في التعافي. لكن موضع البيانات قد يقيّد إلى أين تذهب النسخة. الحلّ الشائع: فصل جغرافي داخل النطاق المسموح — منطقتان متباعدتان داخل المملكة مثلًا. راجع استضافة نظام التذاكر داخل السعودية أم خارجها.
ماذا نفعل بالتذاكر أثناء توقّف النظام؟
هذا سؤال استمرارية أعمال لا تعافٍ تقني، وأغلب الخطط تغفله. حدّد مسبقًا: قناة بديلة معلومة لاستقبال الطلبات، وطريقة تسجيل يدوية موحّدة، وإجراء إدخالها للنظام بعد عودته، وكيفية إبلاغ المستفيدين. بلا ذلك ستتلقّى الطلبات في قنوات متفرّقة تضيع كلها عند العودة، فتتحوّل ساعات التوقّف إلى أسابيع من الفوضى.