الرئيسية›الأدلة›ماذا تفعل إذا…
ماذا تفعل إذا…
فشل النسخ الاحتياطي الليلة الماضية
فشل النسخ الاحتياطي ليلة واحدة ليس كارثة، بل تأخير: فعمر آخر نسخة سليمة لا يقل عن 48 ساعة إذا كانت نسخة الليلة السابقة قد نجحت. أما تكرار الفشل عدة مرات متتالية فهو حادث يمس الحماية: يُبحث عن سببه في اليوم نفسه، ولا يُكتفى بإقرار التنبيه.
الخلاصة
- اقرؤوا رسالة الخطأ، لا المؤشر الأحمر فقط: المساحة، مصدر غائب، بيانات الاعتماد، ملفات مقفلة، سرعة الاتصال، وكيل متوقف.
- قد تكون مهمة «ناجحة» قد نسخت مجلدًا فارغًا: راجعوا حجم البيانات المنسوخة.
- دوّنوا تاريخ آخر نجاح وأبلغوا به مسؤول القسم المعني.
- أعيدوا التشغيل بعد التصحيح، ثم تحققوا من الليلة التالية.
- ثلاث حالات فشل في شهر على الجهاز نفسه: غيّروا الإعدادات، لا تكتفوا بزر «إعادة التشغيل».
1. قراءة الخطأ، لا المؤشر الأحمر فقط
الأسباب الشائعة، بحسب ترتيب ظهورها:
| السبب | العلامة | التصحيح |
|---|---|---|
| نفاد المساحة في الوجهة، أو بلوغ الحصة | خطأ في الكتابة، مدة احتفاظ تتقلص | زيادة السعة، أو تقصير السجل التاريخي عن وعي |
| المصدر مطفأ أو خارج الشبكة أو تغيّر مساره | حرف محرك أقراص أو مجلد مشترك أُعيدت تسميته؛ مهمة «ناجحة» على مجلد فارغ | إعادة المصدر، تصحيح المسار، التحقق من حجم البيانات المنسوخة |
| رفض بيانات الاعتماد | انتهاء صلاحية كلمة مرور حساب الخدمة | إعادة تفعيل الحساب: وإلا ستفشل جميع الليالي |
| ملفات مقفلة أو قاعدة بيانات لم تُوضع في حالة ثبات | نسخ جزئي | استخدام الطريقة المخصصة للقواعد المفتوحة؛ فقاعدة SQL في هذه الحالة لا يمكن استعادتها بشكل سليم |
| اتصال بطيء جدًا أو مقطوع | مهمة متوقفة في نهاية النافذة الزمنية | نسخ تزايدي أكثر كفاءة، أو نافذة أطول، أو تقليل البيانات غير الضرورية |
| توقف الوكيل على الجهاز | لا يوجد أي إرسال | إعادة تشغيل الخدمة، والبحث عن سبب توقفها |
أكثر الحالات خداعًا هي المهمة الخضراء على مجلد فارغ. وتطلب الوكالة الوطنية الفرنسية لأمن نظم المعلومات (ANSSI) أن يخضع النسخ الاحتياطي دائمًا للمراقبة، مع متابعة خاصة لأي حجم بيانات أو عدد ملفات غير متسق، ولبطء الشبكة وتغييرات الإعدادات. والانخفاض المفاجئ في حجم البيانات المنسوخة من ليلة إلى أخرى يستحق الاهتمام نفسه الذي يستحقه الفشل.
2. معرفة تاريخ آخر نجاح
هذا هو التاريخ الوحيد الذي يهم بالنسبة إلى RPO اليوم. وإذا مضى عليه أكثر من بضعة أيام، فأبلغوا به الشخص المسؤول عن القسم المعني. فهو يعمل دون شبكة أمان، ويجب أن يعلم ذلك. فإقرار التنبيه في وحدة التحكم دون هذا الإبلاغ هو التصرف الذي يحوّل حادثًا إلى فقدان بيانات بعد أسبوعين.
3. إعادة التشغيل بعد التصحيح
أعيدوا تشغيل مهمة يدوية بعد معالجة السبب، وانتظروا حتى تنتهي. فشل إعادة التشغيل يعني أن السبب لا يزال قائمًا. وفي صباح اليوم التالي، تحققوا من الليلة التالية: فكثير من التصحيحات «البديهية» لا تصمد في التشغيل الثاني.
المهمة الناجحة تثبت أن نسخة قد كُتبت، لا أنها قابلة للاستعادة. فبالنسبة لقاعدة بيانات SQL Server، توضح Microsoft أن أمر التحقق من النسخة الاحتياطية لا يفحص بنية البيانات التي تحتويها. وتطلب ANSSI اختبار النسخ الاحتياطية بانتظام، مع إجراء استعادة مكتوب؛ كما يوصي NIST أيضًا باختبار النسخ الاحتياطية للتأكد من إمكانية استرجاع الملفات دون أخطاء. وبعد أي حادث في النسخ الاحتياطي، تبقى الاستعادة التجريبية لملف أو لقاعدة بيانات أفضل وسيلة للتحقق. راجعوا كيف تختبر أن النسخ الاحتياطي يعمل؟.
4. إذا تكرر الفشل
ثلاث حالات فشل في شهر على الجهاز نفسه تعني أن النطاق أو سرعة الاتصال أو المنتج غير ملائم. يجب تغيير إعداد ما (استبعاد مجلد ضخم عديم الفائدة، تقسيم المهمة، زيادة سعة التخزين)، لا الاكتفاء بإعادة التشغيل يدويًا كل يوم اثنين.
قائمة التحقق الصباحية
- هل انتهت جميع مهام الليلة، وليس فقط «دون أخطاء»؟
- هل حجم البيانات المنسوخة متسق مع حجم الليالي السابقة؟
- هل مضى على آخر نجاح لكل جهاز حيوي أقل من 24 ساعة؟
- هل قرأ شخص محدد بالاسم التنبيهات، ولم تُستلم فحسب؟
- هل تغطي المساحة المتبقية في الوجهة مدة الاحتفاظ المقررة؟
لدى WeDoBack
تشمل المراقبة على مدار الساعة النسخ الاحتياطية، وتُرسل تنبيهًا عندما لا تكتمل عملية نسخ. والتنبيه هو بداية هذه الصفحة، لا نهايتها. في عرض INTEGRAL، يمكن استخدام ساعتي الدعم الشهريتين لمعالجة السبب. وفي عرض SMART، يُفوتر الدعم حسب كل تدخل: ويبقى الفشل ظاهرًا للعميل في وحدة التحكم، وعليه هو أن يطّلع عليه. يمكن التواصل مع الدعم الفني على الرقم +33 9 72 50 78 28، من 9:00 إلى 13:00 ومن 14:00 إلى 17:30 (بتوقيت باريس). ولتحديد سعة التخزين، فإن التقدير المنشور هو الحجم الحالي مضروبًا في ثلاثة، ثم يُعدّل بعد أسبوع من الاستخدام: فالسعة المحدودة جدًا تظهر في المهام الفاشلة أو في مدة احتفاظ تتقلص. أما مفتاح التشفير، الذي يحتفظ به العميل، فلا دور له في فشل الإرسال: إذا فشلت المهمة، فهذا يعني ببساطة أن النسخة البعيدة لم تُحدّث.
الأسئلة الشائعة
هل فشل ليلة واحدة أمر خطير؟
نادرًا، إذا نجحت الليلة السابقة وتم تصحيح السبب خلال اليوم. فالخطر يأتي من التراكم: كل ليلة فاشلة تزيد حجم العمل الذي سيضيع عند وقوع كارثة. وبعد بضعة أيام، يصبح الأمر حادثًا يجب إبلاغ الإدارة به.
هل تكفي حالة «ناجح» لإثبات أن النسخة الاحتياطية سليمة؟
لا. تطلب الوكالة الوطنية الفرنسية لأمن نظم المعلومات (ANSSI) مراقبة منهجية للنسخ الاحتياطية، ولا سيما لأحجام البيانات غير المتسقة، وإجراء اختبارات استعادة منتظمة. وبالنسبة لـ SQL Server، توضح Microsoft أن التحقق من النسخة الاحتياطية لا يفحص بنية البيانات التي تحتويها: وحدها استعادة فعلية يليها فحص للاتساق تثبت ذلك.
من يجب أن يراقب تنبيهات النسخ الاحتياطي؟
شخص محدد بالاسم، مع بديل في فترات الإجازات. فالتنبيه الذي يصل إلى صندوق بريد مشترك لا يقرؤه أحد يعادل غياب التنبيه. وحددوا أيضًا من يُبلغ الإدارة عندما يتجاوز آخر نجاح عتبة متفقًا عليها مسبقًا.
لمزيد من المعلومات
المصادر
وثائق اطُّلع عليها في أكتوبر 2026.
- النسخ الاحتياطي لنظم المعلومات – الأساسيات (ANSSI-BP-100، الإصدار 1.1، 27 نوفمبر 2025) — ANSSI
- لماذا وكيف تُدار النسخ الاحتياطية بشكل جيد؟ — Cybermalveillance.gouv.fr
- RESTORE VERIFYONLY (Transact-SQL) — Microsoft Learn
- SP 800-34 Rev. 1، دليل التخطيط للطوارئ لنظم المعلومات الفيدرالية — NIST
- العروض والأسعار — WeDoBack
هل تحتاج إلى مساعدة الآن؟
لا تستعِد أي شيء قبل التأكد من وجود نسخة سليمة. يمكننا إرشادك.
اتصل على الرقم +33 9 72 50 78 28أو راسلناهل تواجه حادثًا الآن؟
تساعدك فرقنا على تحديد النسخة السليمة واستعادتها، من الاثنين إلى الجمعة من 9:00 إلى 13:00 ومن 14:00 إلى 17:30 (بتوقيت باريس).