النسخ الاحتياطي للموقع: كيف تستعيده قبل أن تخسره

 

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

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

الوعد بسيط: بعد قراءة هذا الدليل ستكون لديك خطة نسخ تعرف بالضبط ما تحتويه، وكم تستغرق استعادتها، وكيف تتأكد قبل الكارثة أن الاستعادة تعمل. ولا تنسَ أن النسخة الاحتياطية تحمي من الحذف والخطأ، أما من الاختراق فتحتاج خطوة أخرى: حماية الموقع من الاختراق لا تغني عنها نسخة، والنسخة لا تغني عنها.

1. النسخة الاحتياطية ليست ملفًا، بل قدرة على الاستعادة

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

قِس على موقعي: قرأت من خادم المدونة حجم قاعدة البيانات 164 ميجابايت موزّعة على 124 جدولًا، وجدول المقالات وحده 39 ميجابايت. ومجلد الصور والوسائط يحتوي 17476 ملفًا بحجم 403 ميجابايت. أما حزمة القوالب فـ41 ميجابايت، والإضافات 365 ميجابايت، فيصبح إجمالي ما يحتاج النسخ قرابة 943 ميجابايت.

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

وجدت أيضًا في القاعدة نفسها ما يفسد كل حساب: جدولان مهجوران يعودان إلى عملية ترحيل قديمة، يحملان اسمًا يبدأ بـ_mig_، ويشغلان معًا نحو 35 ميجابايت — أي خُمس قاعدة البيانات. نسخة تحدّق في هذه الجداول تُضاعف زمن الاستعادة بلا فائدة. فحص القاعدة قبل النسخ جزء من العمل، وليس ترفًا.

2. ماذا تنسخ فعلًا؟ أربعة أجزاء لا يكفي أحدها

أولًا: قاعدة البيانات

هنا المقالات والتصنيفات والوسوم والتعليقات والمستخدمون وإعدادات الموقع وبيانات الإضافات. لقطة قاعدة بلا ملفات تعيد لك نصوصًا بلا صور، وملفات بلا قاعدة تعيد لك مجلدًا لا يعرف كيف يعرض نفسه. في مدونة أرباحي دفعت القاعدة 164 ميجابايت في الخام، و10 ميجابايت فقط بعد ضغطها، وهذا فرق يسمح لك بالاحتفاظ بعشرين لقطة بدل واحدة.

ثانيًا: مجلد المحتوى والملفات المخصّصة

ليس المقصود مجلد الإضافات كله؛ فمعظمه قابل للتنزيل من مستودع ووردبريس. المهم هو ما لا يمكن تنزيله: مجلد الصور، والقوالب المعدّلة، وملفات mu-plugins. عندي في هذا المجلد الأخير أكثر من خمسين ملفًا كتبتُها بنفسي لهذا الموقع — من بوكس الإجابات السريعة إلى الهيدرات الأمنية والتحويلات — ولا يوجد لها نسخة في أي مستودع في العالم.

ثالثًا: الإعدادات الخارجة عن الموقع

ملف wp-config.php ومفاتيح الأمان فيه، وبيانات الاتصال، وسجلات DNS، وشهادات النطاق، وصناديق البريد، وصلاحيات حسابات الأدوات التي تتحكم بالموقع (Search Console، التحليلات، بوابة الدفع). هذه الأشياء لا تدخل في أي نسخة تلقائية، ونسيانها يحوّل الاستعادة إلى مشروع أسبوعين.

رابعًا: ما لا يجب نسخه

ملفات الكاش، وسجلات الأخطاء، والمجلدات المؤقتة، ونسخ الإضافات الاحتياطية القديمة المتراكمة داخل الموقع نفسه. هذه تستهلك مساحة وتُبطئ الاستعادة، وقد تحتوي على بيانات لا تريد نسخها إلى مكان آخر. عمليًا: استثنِ wp-content/cache و*.log من أي أرشيف.

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

 

3. قاعدة 3-2-1 واشتقاقها العملي

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

كيف تُترجم عندي إلى جدول أسبوعي؟ النسخة الأولى على الخادم نفسه (للاستعادة السريعة من خطأ تحرير)، والثانية على جهاز آخر خارج الخادم (تنزيل أرشيف أسبوعي)، والثالثة في تخزين بعيد منفصل جغرافيًا. الوسائط مختلفة: قرص الخادم، وقرص جهازي، وتخزين سحابي. والنسخة الثالثة هي التي تنجو حين يختفي الخادم كله، ولهذا لا تُوكَل إلى المزوّد وحده.

في المواقع التي أعمل عليها، أدفع ثمن «مكان ثالث» بسيط جدًا: خطة تخزين رخيصة أو مساحة على خادم آخر أملكه. الفرق بين موقع يعود في ساعة وموقع ينتظر أسبوعًا هو غالبًا هذا المكان الثالث. وإذا كنت تدير أكثر من موقع، فافصل «مكان النسخ» عن «مكان الاستضافة» حتى لا تسقط الاثنتان بعطل واحد؛ وهذا جوهر ما أطبّقه في استضافة VPS وتحسين السيو حين أضع مواقع العميلات على خوادم متعددة.

4. خمس طرق للنسخ، وأين تنكسر كل واحدة

لا توجد طريقة واحدة صحيحة؛ توجد طرق تصلح لأحجام مختلفة. هذا الجدول خلاصة تجربتي مع الخمس:

الطريقة	ماذا تنسخ	نقطة الانكسار	تصلح لـ
أمر mysqldump يدوي	قاعدة البيانات فقط	تُنسى مع الوقت، ولا تحفظ الصور	قبل تعديل كبير على القاعدة
إضافة نسخ داخل ووردبريس	القاعدة والملفات	النسخة داخل الموقع نفسه إن لم تُضبط الوجهة	المواقع المتوسطة بلا سطر أوامر
نسخة لوحة الاستضافة	الحساب كله	لا تملكها ولا تعرف تكرارها ولا مدة الاحتفاظ	طبقة أخيرة مطمئنة
خدمة تخزين خارجية	أرشيف مضغوط ومشفّر	تكلفة شهرية وتنظيم مفاتيح الوصول	النسخة الثالثة البعيدة
سكربت مجدول بالكامل	ما تحدّده أنت بالضبط	صمت الفشل: لا أحد يعلم أن النسخة لم تُنشأ	المواقع الكبيرة والمتكررة

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

5. جدول من مئة نقطة: قيّم خطتك الآن

هذه هي الأداة التي أستخدمها حين يطلب مني عميل تقييم وضعه. أعطِ كل بند درجته بشرط أن يتحقق الشرط كاملًا، ثم اجمع:

البند	الدرجة	شرط النقطة الكاملة
نسخة خارج الموقع	20	موجودة على وسيط أو خادم آخر لا يسقط مع الموقع
اختبار استعادة موثّق	20	جرّبتها فعلًا ونجحت، ومكتوب تاريخ آخر تجربة
التكرار المناسب	15	تتسع لأقصى قدر من التغيير تقبله (يوم للقاعدة مثلًا)
الشمول	15	قاعدة البيانات، والصور، والملفات المخصّصة، والإعدادات
الاحتفاظ بعدة أجيال	10	لا تُستبدل النسخة السليمة بنسخة تحمل العطب نفسه
تنبيه عند الفشل	10	يصلك إشعار إن لم تُنشأ النسخة أو كان حجمها شاذًّا
حماية النسخة	5	غير متاحة عبر رابط عام، ومشفّرة إن كانت بعيدة
زمن الاستعادة المعروف	5	تعرف كم يستغرق الموقع ليعود، بالأرقام لا بالتقدير

اقرأ النتيجة: من 80 إلى 100 خطتك جاهزة، ومن 50 إلى 79 لديك نسخ لكنها غير مُختبرة، وأقل من 50 يعني أنك تعمل بلا شبكة أمان. أغلب المواقع التي فحصتها كانت بين 40 و55، والسبب دائمًا بند واحد: لم يُجرّب أحد الاستعادة قط.

6. بروفة الاستعادة: ست خطوات تفصل النسخة الحقيقية عن الوهم

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

1. جهّز بيئة معزولة: نطاق فرعي محمي أو خادم محلي، بمساحة أكبر من حجم الأرشيف.
2. أنشئ قاعدة فارغة واستورد الملف: إن ظهر خطأ في منتصف الاستيراد فقد اكتشفت العطب اليوم لا بعد الكارثة.
3. فكّ الأرشيف وضع الملفات في مكانها: وانتبه إلى الصلاحيات، فهي سبب نصف حالات «الصفحة البيضاء».
4. اضبط ملف الإعداد: بيانات القاعدة وروابط الموقع؛ ولا تنسَ أن رابط الموقع في القاعدة يحتاج تحديثًا إن كنت تستعيد على نطاق آخر.
5. افحص بعينك لا بالحالة فقط: افتح الرئيسية، وسجّل الدخول، وافتح مقالًا قديمًا بصورة داخلية، وتأكد أن التصنيفات والوسوم موجودة. صفحة تفتح بلا صور ليست نجاحًا.
6. أعِد الفهرسة: راجع ملف robots.txt وsitemap ثم أرسل الخريطة من جديد في أدوات مشرفي المواقع، واطلب فحص الصفحات المهمة. الاستعادة تعيد المحتوى، لكنها لا تُخبر محركات البحث أن الموقع عاد.

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

 

7. أخطاء تُفسد النسخة الاحتياطية

• النسخة على الخادم نفسه. تحمي من خطأ التحرير فقط، وتسقط مع أي عطل في الحساب أو الخادم. هذا أشيع خطأ وأغلى ثمنًا.
• نسخة بلا اختبار. ملف يفتح ليس ملفًا يعمل؛ الفرق بينهما يظهر في أسوأ وقت.
• صمت الفشل. سكربت يتوقف بلا تنبيه يُنتج أرشيفًا بحجم صغير لا يلاحظه أحد. قارن حجم كل نسخة بالمتوسط، وأوقف الثقة عند أول انحراف.
• نسخة واحدة تُستبدل كل مرة. إن كان العطب قد بدأ قبل أسبوع، فالنسخة الجديدة تحمل العطب نفسه. احتفظ بأجيال متعددة.
• استثناء الصور لأنها «ثقيلة». استعادة بلا صور تعني إعادة رفع 17476 ملفًا يدويًا، أو موقعًا مكسورًا للأبد.
• نسيان الملفات المخصّصة. القوالب المعدّلة وملفات mu-plugins لا تأتي مع أي استعادة قياسية، وهي غالبًا أهم ما في الموقع.
• الاعتماد الكامل على «ننسخ لك». إن لم يكن لديك وصول إلى نسخة قابلة للتنزيل، فأنت لا تملك شيئًا؛ تملك وعدًا.

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

8. الخطة التنفيذية: أسبوع واحد ثم ثلاثون يومًا

أول أسبوع: اليوم الأول، قِس الحجم الحقيقي للموقع والقاعدة واحسب مساحة الأرشيف. اليوم الثاني، أنشئ أول نسخة كاملة يدويًا وانزلها خارج الخادم. اليوم الثالث، جرّب استعادتها على بيئة معزولة وسجّل الزمن. اليوم الرابع، اضبط نسخة يومية للقاعدة تلقائيًا. اليوم الخامس، أضف تنبيه فشل بسيطًا. اليوم السادس، وثّق كل شيء في ملف واحد: أين النسخ، ومفاتيح الوصول، ومن يستعيد. اليوم السابع، اختبر الاستعادة الثانية — لأن الأولى قد تكون مصادفة.

ثم ثلاثون يومًا: نسخة قاعدة يومية تُحفظ سبعة أجيال، وأرشيف ملفات أسبوعي يُحفظ أربعة أجيال، ونسخة شهرية بعيدة تُحفظ ثلاثة أجيال. مرة كل ربع، اختبار استعادة كامل. ومرة كل شهر، نظرة على القاعدة: هل تراكمت جداول مهجورة كما تراكم عندي 35 ميجابايت من مخلفات ترحيل قديم؟

وأضف عادة صغيرة تُوفّر كثيرًا: خُذ لقطة قبل أي تعديل كبير على مقال أو قالب. النسخة الاحتياطية ليست للكوارث فقط، بل للتراجع السريع عن قرار خاطئ؛ وهذا بالضبط ما يجعل العمل على المحتوى القديم آمنًا كما في دليل تحديث المحتوى القديم.

الخلاصة

النسخة الاحتياطية ليست ملفًا تحتفظ به، بل وعدًا تختبره. ابدأ من الأرقام: عندي 164 ميجابايت قاعدة و403 ميجابايت صور و943 ميجابايت موقع كامل، ونسخة القاعدة المضغوطة 10 ميجابايت فقط — أي أن الحجم ليس عذرًا. اجعلها ثلاث نسخ على وسيطين وواحدة خارج الموقع، واختبر الاستعادة فعلًا قبل أن تحتاجها، وراقب فشل السكربتات لا نجاحها فقط.

إن كان هذا الدليل وفّر عليك وقتًا، يمكنك دعم المدونة عبر رابط الدعم.

الأسئلة الشائعة

كم مرة يجب أن أنسخ موقعي احتياطيًّا؟

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

هل نسخة لوحة الاستضافة كافية؟

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

كيف أعرف أن النسخة الاحتياطية سليمة فعلًا؟

بالاستعادة، لا بالحجم. استورد القاعدة على بيئة معزولة وافتح مقالًا قديمًا بصورة داخلية. نجاح الاستيراد وحده لا يكفي، لأن الملفات قد تكون ناقصة والقاعدة سليمة.

هل أنسخ الصور كل مرة؟

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

ما المدة المناسبة للاحتفاظ بالنسخ؟

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

هل تحمي النسخة الاحتياطية موقعي من الاختراق؟

تساعد على العودة، لكنها لا تمنع الاختراق. الموقع المخترق قد يظل يُصاب بعد الاستعادة إن لم تُغلق الثغرة أولًا، ولهذا تُقرن النسخة دائمًا بإجراءات الحماية والمراقبة.