النسخ الاحتياطية في الاستضافة: ما لا يخبرك به مزودك

ثمة فارق دقيق يغيب عن كثير من أصحاب المواقع حين يقرؤون عبارة "نسخ احتياطية يومية" في صفحات التسعير: التكرار اليومي لا يخبرك شيئًا عن المدة التي تبقى فيها هذه النسخ متاحةً للاستعادة. هذا الفارق — بين خطة النسخ الاحتياطي وفترة الاحتفاظ بها — هو ما يحدد فعليًا ما إذا كنت ستستعيد موقعك وقت الأزمة، أم ستجد أن كل نسخة لديك تحمل المشكلة ذاتها.

ما الذي يُنسخ احتياطيًا فعلًا؟

قبل الحديث عن الخطط والاحتفاظ، ثمة أمر أساسي يجب فهمه: موقعك لا يُنسخ كقطعة واحدة. هناك مكوّنان مستقلان، وكلاهما ضروري:

• الملفات: كود التطبيق، القوالب، الإضافات، الصور المرفوعة — كل ما يقع في نظام الملفات.
• قاعدة البيانات: المحتوى، المستخدمون، الطلبات، الإعدادات — كل ما تخزّنه MySQL أو MariaDB.

يُنسخ هذان المكوّنان بشكل منفصل، وهذا يعني أنهما قد يُستعادان في لحظتين زمنيتين مختلفتين. استعادة ملفات WordPress من يوم الثلاثاء مع قاعدة بيانات من يوم الاثنين قد تنتهي بشاشة بيضاء أو أخطاء قاعدة بيانات، إذا أجرت إحدى الإضافات بينهما تحديثًا على هيكل الجداول.

الفرق بين خطة النسخ الاحتياطي وفترة الاحتفاظ

كثير من المستخدمين يعتقدون أن "نسخ يومية" تعني أن بمقدورهم الرجوع إلى أي يوم في الشهر الماضي. الحقيقة مختلفة تمامًا.

خطة النسخ الاحتياطي تحدد متى تُؤخذ اللقطات: كل ساعة، يوميًا، أسبوعيًا. هذا هو الرقم الذي يظهر في الإعلانات.

فترة الاحتفاظ تحدد كم نسخة تبقى مخزّنة قبل الحذف. مضيف يُجري نسخًا يومية مع احتفاظ لثلاثة أيام لديه ثلاث نقاط استعادة فحسب — ليس ثلاثين.

السؤال الذي يجب طرحه على مزود الاستضافة ليس "هل النسخ يومية؟" بل: "ما أقدم نقطة استعادة يمكنني الوصول إليها الآن؟"

مقارنة عملية

الفساد الصامت: حين تُصبح كل نسخة احتياطية ملوّثة

هذا هو السيناريو الأكثر إيلامًا، وهو ما لا تُحذّر منه صفحات التسعير.

لنفترض أن موقعك تعرّض للاختراق في الأول من الشهر. المخترق لم يُشوّه الموقع — فعل شيئًا أذكى: زرع بابًا خلفيًا وروابط مخفية، وانتظر. الموقع يبدو طبيعيًا تمامًا. الزوار لا يلاحظون شيئًا. أنت لا تلاحظ شيئًا.

في الخامس عشر من الشهر، تُرسل لك Google Search Console تحذيرًا: موقعك يحتوي على محتوى ضار. تسرع لاستعادة نسخة احتياطية — وتكتشف أن مضيفك يحتفظ بسبعة أيام فقط. أقدم نسخة لديك هي من الثامن. جميع النسخ السبع أُخذت بعد يوم الاختراق. جميعها تحمل الباب الخلفي. لا يوجد إصدار نظيف.

هذا ليس سيناريو نادرًا — إنه النمط الأكثر شيوعًا في اختراقات المواقع الصغيرة. وهو ينطبق على حالات أخرى:

• تحديث إضافة فاسد: يُخرب قاعدة البيانات تدريجيًا في حالات استخدام محددة لا تظهر إلا بعد أسابيع.
• خطأ برمجي في كود مجدوَل: سكريبت يعمل ليلًا يُعدّل بيانات بشكل خاطئ لأيام قبل اكتشافه.
• حذف محتوى خاطئ: موظف يحذف بيانات عن طريق الخطأ ولا يُكتشف الأمر إلا بعد انتهاء نافذة الاحتفاظ.

المعيار الاحترافي للمواقع التجارية هو 30 يومًا على أقل تقدير. للمواقع التي تُعالج معاملات مالية، 90 يومًا. الاستضافة المشتركة الرخيصة غالبًا تقدم 3 إلى 7 أيام.

أين تُخزَّن النسخ: الفارق بين النسخة الاحتياطية والوهم

ليس كل ما يُسمّى "نسخة احتياطية" هو نسخة احتياطية فعلية. إذا خزّن مضيفك نسخك على الخادم ذاته الذي يشغّل موقعك، فأنت لا تملك نسخة احتياطية بالمعنى الحقيقي — أنت تملك نسخة ثانية على القرص الصلب نفسه. إذا تعطّل ذلك الخادم أو احترق مركز البيانات، تضيع النسخة مع الموقع.

النسخة الاحتياطية الحقيقية تُخزَّن في موقع منفصل جغرافيًا: خادم آخر في مدينة مختلفة، أو خدمة سحابية كـ S3 أو Backblaze. هذا ما تفعله المضيفات الجادة، وهذا ما يجب سؤالهم عنه صراحةً.

cPanel والنسخ الاحتياطية: ما يعرفه المحترفون

cPanel هي الواجهة التي يستخدمها أغلب أصحاب المواقع، لكن إمكانياتها في إدارة النسخ الاحتياطية أعمق مما يظهر للوهلة الأولى.

الاستعادة الكاملة مقابل الاستعادة الجزئية

حين تقع مشكلة، الغريزة الأولى هي "استعد كل شيء". لكن هذا قد يُفاقم الأمور. إذا كانت المشكلة في قاعدة البيانات وحدها، فاستعادة الحساب بالكامل ستُرجع ملفاتك إلى نسخة أقدم أيضًا — وربما تفقد تحديثات وأكوادًا أضفتها مؤخرًا.

في cPanel تحت قسم Backups → Restore، يمكنك اختيار ما تستعيده:

• Home Directory: الملفات فقط. استخدمه حين المشكلة في الكود أو ملفات الموقع.
• MySQL Databases: قاعدة بيانات بعينها. استخدمه حين المحتوى هو المتضرر.

نزّل نسختك قبل أن تنتهي النافذة

هذه النصيحة وحدها تستحق قراءة هذا المقال: cPanel يتيح لك تنزيل نسخة احتياطية كاملة لحسابك كملف .tar.gz في أي وقت. إذا اكتشفت اليوم مشكلة بدأت قبل خمسة أيام، ومضيفك يحتفظ بسبعة أيام، فعندك 48 ساعة فقط قبل أن تُحذف أقدم نسخة نظيفة.

الطريق: cPanel → Backup Wizard → Download a Full Website Backup. يُحزّم الأداة الملفات وقواعد البيانات وإعدادات DNS وإعدادات البريد في ملف واحد. احتفظ به على جهازك أو في Google Drive.

JetBackup: واجهة أفضل إذا وُجدت

كثير من المضيفات تُثبّت JetBackup بجانب cPanel أو عوضًا عن أداة النسخ الأصلية. الفارق عملي: JetBackup يتيح استعادة ملف واحد بعينه، أو جدول واحد من قاعدة البيانات، وكذلك "الاستعادة إلى مجلد مؤقت" — أي تحميل النسخة القديمة إلى مكان آخر للفحص قبل تطبيقها على الموقع الحي. هذا يُجنّبك سيناريو استعادة نسخة فاسدة فوق موقع سليم.

إذا ظهر لك خيار JetBackup في قائمة cPanel، استخدمه بدلًا من أداة Backup الافتراضية.

ملف النسخة داخل الحساب: وهم الحماية المزدوجة

بعض المضيفات تُشغّل أداة النسخ الداخلية لـ cPanel، التي تُنشئ ملف أرشيف backup-YYYY-MM-DD.tar.gz داخل مجلدك الرئيسي. ثم تُدرج هذا المجلد ضمن النسخة الخارجية للخادم. يبدو هذا حماية مزدوجة، لكنه ليس كذلك: الأرشيف يستهلك من حصّتك على القرص، وإذا تعطّل نظام النسخ الاحتياطي الخارجي، وجدت نفسك تعتمد على ملف موجود على الخادم ذاته.

الحل: نزّل هذا الأرشيف محليًا عند إنشائه، ثم احذفه من الخادم.

أخطاء الاستعادة الشائعة

استعادة الملفات دون قاعدة البيانات من التاريخ ذاته

الخطأ الأول والأكثر تكرارًا. إذا أجرت إضافة تحديثًا على هيكل قاعدة البيانات بين التاريخين، سيتعطّل الموقع. استعد دائمًا المكوّنين معًا من اللحظة الزمنية ذاتها.

تطبيق الاستعادة مباشرة على الموقع الحي

إذا كنت تشك أن النسخة ملوّثة، لا تستعدها مباشرة. أنشئ نطاقًا فرعيًا مؤقتًا، استعد النسخة هناك، افحصها، ثم انقلها. استعادة نسخة مخترقة فوق موقع نظيف تجعل الأمور أسوأ.

إغفال DNS وSSL بعد الانتقال إلى خادم جديد

النسخة الاحتياطية تحمل الملفات وقاعدة البيانات، لا إعدادات DNS ولا شهادات SSL. بعد الاستعادة على خادم جديد، ستحتاج إلى تحديث سجلات DNS وإعادة إصدار الشهادة — وإلا بقي الموقع لا يعمل رغم اكتمال الاستعادة.

طبقة النسخ الاحتياطي الثانية: لا تثق بمزودك وحده

النسخ الاحتياطية للاستضافة تحميك من أعطال الخادم وأخطاء المزود. لكنها لا تمنحك التحكم الكامل: أنت لا تتحكم في جدولها، ولا في مكان تخزينها، ولا في مدى سهولة الوصول إليها.

لمواقع WordPress، إضافة مثل UpdraftPlus تُتيح لك جدولة نسخ احتياطية إلى Google Drive أو Dropbox أو S3 بشكل مستقل عن المضيف. إذا أفلس المضيف غدًا أو أغلق حسابك بالخطأ، نسختك في مكان آمن تتحكم به أنت.

الأسئلة التي يجب طرحها على مزودك

هذه الأسئلة تكشف ما إذا كانت النسخ الاحتياطية حقيقية أم مجرد تسويق:

1. ما أقدم نقطة استعادة متاحة لي الآن؟ — ليس "هل النسخ يومية"، بل كم يومًا يمكنني الرجوع إليه فعليًا.
2. أين تُخزَّن النسخ؟ — على الخادم ذاته، أم في موقع منفصل؟
3. هل تُنسخ الملفات وقاعدة البيانات في اللحظة ذاتها؟
4. هل أستطيع الاستعادة بنفسي من cPanel، أم أحتاج لفتح تذكرة دعم؟
5. هل الاستعادة مجانية، أم هناك رسوم لكل عملية؟
6. هل خطتي الحالية تتضمن النسخ الاحتياطية، أم أنها إضافة مدفوعة؟

خلاصة

النسخة الاحتياطية التي لا تعرف تفاصيلها ليست أمانًا — إنها وهم أمان. الفارق بين مضيف يحتفظ بسبعة أيام ومضيف يحتفظ بثلاثين ليس رقمًا في جدول المقارنة، بل هو الفارق بين التعافي والخسارة حين يحدث شيء لم تتوقعه.

اعرف نافذة احتفاظ مضيفك. تأكد أن النسخ تُخزَّن خارج الخادم. شغّل طبقة احتياطية ثانية إلى مكان تتحكم به. ونزّل نسخة يدوية من cPanel قبل أي تغيير كبير.

والأهم: لا تنتظر وقوع المشكلة لتختبر آلية الاستعادة. النسخة الاحتياطية غير المختبرة هي نسخة لا تملكها.