استراتيجية نسخ احتياطي للمواقع تنجح فعلًا

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

ابدأ بقاعدة 3-2-1: احتفظ بثلاث نسخ من بياناتك، على نوعين مختلفين من وسائط التخزين، مع نسخة واحدة خارج الموقع. بالنسبة لموقع الويب، يُعدّ الموقع الحي النسخة الأولى، والنسخ الاحتياطية لدى مزوّد الاستضافة النسخة الثانية، وأرشيف تنزّله إلى وسيط تخزين تتحكم به النسخة الثالثة. ثم ضع قائمة بما تحتاجه الاستعادة الكاملة فعلًا. ملفات الموقع والملفات المرفوعة وقواعد البيانات أمور بديهية. أما الأقل بداهة فهي صناديق البريد، ومهام cron، وإعدادات PHP، وقواعد .htaccess أو nginx، ومفاتيح API وملفات البيئة، وتصدير لمنطقة DNS الخاصة بك، لأن إعادة بناء أربعين سجلًا من الذاكرة أثناء انقطاع الخدمة عملية بطيئة وعرضة للأخطاء.

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

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

تحتاج قواعد البيانات إلى عناية خاصة. فنسخ الملفات الخام لخادم MySQL أو PostgreSQL قيد التشغيل قد ينتج نسخة احتياطية تبدو مكتملة لكنها لن تعمل، لأن البيانات كانت تتغير أثناء النسخ. استخدم بدلًا من ذلك تفريغًا صحيحًا: mysqldump مع الخيار --single-transaction لجداول InnoDB، أو pg_dump لـ PostgreSQL، وكلاهما يعطي لقطة متسقة دون قفل الموقع. اضغط ملف التفريغ، وضع التاريخ والوقت في اسمه، وتحقّق من أن حجم الملف ليس صغيرًا على نحو مريب. فاكتشاف ملف تفريغ بحجم صفر بايت كان يعمل «بنجاح» كل ليلة لمدة ستة أشهر أمر شائع على نحو مفاجئ.

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

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