الخادم الافتراضي يمنحك تحكماً كاملاً في الخادم، وهذا يعني أن النسخ الاحتياطي مسؤوليتك أيضاً. إليك ما يجب نسخه احتياطياً، وكيف تطبّق قاعدة 3-2-1 على الخوادم الافتراضية، وكيف تؤتمت الجدولة، ولماذا يُعدّ اختبار الاستعادة الدليل الوحيد الحقيقي.
النسخة الاحتياطية للخادم الافتراضي هي نسخةٌ من بيانات خادمك مخزَّنةٌ في مكانٍ لا يستطيع الخادم نفسه الوصول إليه، بحيث إذا فشل الخادم أو حُذف عن طريق الخطأ أو شفّره برنامجُ فدية، يمكنك إرجاع البيانات ذاتها على جهازٍ جديد. على الاستضافة المشتركة يأخذ مزوِّد الخدمة هذه النسخ نيابةً عنك؛ أما على الخادم الافتراضي فأنت تتحكّم في المكدس بالكامل، فتنتقل إليك مسؤولية النسخ الاحتياطي والاستعادة منه. المعيار العملي هو قاعدة 3-2-1: ثلاث نسخٍ من البيانات، على نوعين مختلفين من التخزين، مع نسخةٍ واحدة بعيدةٍ عن الموقع، والدليل الوحيد على نجاح أيٍّ منها هو استعادةٌ جرّبتها فعلاً.
على الاستضافة المشتركة يلتقط مزوِّد الخدمة لقطاتٍ للجهاز كله، وتفتح تذكرة دعمٍ فاعترض شيءٌ ما. الخادم الافتراضي يرفع هذا السقف: أنت من يختار نظام التشغيل وقاعدة البيانات وجدار الحماية وجدولة التحديثات، وهذا بالضبط جوهر فائدته، ولكنه يعني أيضاً أنه لا أحد يأخذ نسخةً نيابةً عنك. لا يزال المزوِّد يحمي العتاد، ويفقد مزوِّدٌ جيدٌ قرصاً معطوباً دون أن تلاحظ، لكن ذلك يغطّي الطبقة المادية فقط. لا يغطّي المشغّل الذي يثبّت تحديثاً فيكسر قاعدة البيانات، ولا السكربت الذي يكتب فوق المجلد الخطأ، ولا المهاجم الذي يشفّر كل شيء ويطلب فدية، ولا حساب المزوِّد المخترَق فيختفي المشروع كله. تشترك هذه السيناريوهات الأربعة في سمةٍ واحدة: أنها غير مرئية لمركز البيانات، وتنتهي كلها بالطريقة ذاتها ما لم توجد نسخةٌ في مكانٍ آخر.
القاعدة هي ثلاث نسخٍ من البيانات، على نوعين من التخزين، مع نسخةٍ واحدة بعيدة، وقد صمدت لأنها بسيطة وتغطّي كل نقطة فشلٍ مفردة. على الخادم الافتراضي تُقابَل مباشرةً بالبنية التي تملكها أصلاً. النسخة الأولى هي الخادم الحيّ نفسه. والثانية نسخةٌ على تخزينٍ مختلف داخل المشروع ذاته — لقطة قرصٍ منفصلة، أو ملف تصدير قاعدة بيانات يُكتَب في مخزن كائنات، أو خدمة نسخٍ داخل المزوِّد نفسه لكن على أقراصٍ منفصلة. والثالثة هي النسخة البعيدة، و"البعيدة" يجب أن تعني نطاق فشلٍ مختلفاً تماماً: مزوِّداً آخر، أو مركز بياناتٍ آخر، أو حساب تخزين كائنات في منطقةٍ منفصلة. يهمّ النوعان لأن مصفوفة التخزين بأكملها قد تفشل، ويهمّ الموقع المنفصل لأن حساباً أو مزوِّداً بأكمله قد يفشل. رقماران يحدّدان شكل الإعداد كله: هدف نقطة الاستعادة، وهو مقدار البيانات الذي يمكنك تحمّل خسارته مقاساً بالوقت، وهدف زمن الاستعادة، وهو المدة التي يستطيع العمل تحمّلها دون الخدمة. أجب عن السؤالين أولاً فيتخذ كل قرار نسخٍ احتياطيٍّ بعدهما نفسه.
ليس كل ما على الخادم يحتاج نسخةً، ومعاملة الجميع على حدٍّ سواء هي كيف تنفجر ميزانيات النسخ. تأتي قواعد البيانات أولاً لأنها تحمل العمل: خذ تصديراً منطقياً كل ليلة عبر pg_dump أو mysqldump — ملفٌ واحد مضغوط يُستعاد في أي مكان — ولقواعد البيانات الأكبر أضِف استعادةً نقطيةً مستمرة فيمكن إرجاع استيرادٍ خاطئ إلى الساعة بدلاً من منتصف الليلة السابقة. كود التطبيق لا يحتاج نسخاً احتياطياً لأن المستودع هو النسخة، والنشر من git يعني إعادة بناء التطبيق أمراً واحداً. ما يحتاج النسخ هو كل ما لا يستطيع المستودع إعادة إنشائه: الملفات المرفوعة ووسائط المستخدمين، وملفات البيئة التي تحمل الأسرار ومفاتيح الأطراف الثالثة، وإعدادات nginx والخدمات، وجداول cron وسكربت النسخ نفسه. الشهادات وسجلات DNS على القائمة أيضاً، فالنطاق الذي تضيع سجلاته قد يستغرق أياماً لإعادة بنائه. واحفظ الأسرار مشفّرةً في مكان تخزينها — نسخةٌ احتياطية من ملف .env في مخزنٍ عام هي خرقُ بياناتٍ ينتظر من يكتشفه.
النسخة الاحتياطية التي تعتمد على تذكّر إنسانٍ ستُنسى في اليوم نفسه الذي تهمّ فيه. أتمتها واجعل الأتمتة صادقة: شغّل المهمة من cron أو systemd وفق جدولةٍ ثابتة، وليكتب كل خطوةٍ في سجل، والأهم: ليخرج السكربت برمز خطأٍ غير صفري إذا فشلت أي خطوة، ثم أرسل ذلك الرمز إلى مكانٍ يقرؤه إنسان — بريداً أو قناة دردشةٍ أو نظام مراقبة. مهمة نسخٍ أنتجت بصمتٍ ملفاً فارغاً لستة أشهر هي خلاصة حادثةٍ كلاسيكية، ورمز الخروج هو الحارس الرخيص ضدها. أضِف فحوص السلامة: تحقّق أن ملف التصدير ليس فارغاً، وافحص بصمة الأرشيف، وتأكّد أن النسخة البعيدة وصلت فعلاً بفحص قائمة المخزن بدل الثقة بأمر الرفع. ثم عيّن الاحتفاظ عمداً بدل الاحتفاظ بكل شيء للأبد — دورة الأب-الجد لنسخٍ يوميةٍ أسبوعاً، وأسبوعيةٍ شهراً، وشهريةٍ سنةً واحدة — تغطّي كل حاجةٍ واقعية بجزءٍ من تكلفة التخزين، وتُجبر البيانات القديمة على التقاعد بدل أن تتراكم حتى تتضاعف الميزانية بهدوء.
النسخة الاحتياطية نظريةٌ حتى تُستعاد. مرةً كل ربع، اختر نسخةً حديثة، ووفّر خادماً تجريبياً بنفس الحجم، واستعد المكدس كاملاً من الصفر: التطبيق والإعدادات وقاعدة البيانات والملفات المرفوعة. احسب زمن التمرين، فالنسخة التي تستغرق استعادتها تسع ساعاتٍ مسألةٌ مختلفةٌ عن التي تستغرق عشرين دقيقة، ولا يُرى الفرق إلا حين تقيسه. ثم قارن سجلاتٍ حقيقيةً بالبيانات المستعادة — مجموعاً أو عدد صفوفٍ أو معاملةً حديثة — فالاستعادة التي تكتمل وفيها الأسبوع الماضي ناقصٌ ليست نجاحاً. عند انتهاء التمرين، دوّن ما حدث في دليل تشغيلٍ يعيش خارج الخادم: الأوامر بالترتيب، ومصدر بيانات الاعتماد، وسجلات DNS التي يجب تبديلها، ومن ينفّذ كل خطوة. دليلٌ مخزّنٌ على الجهاز الذي ينقذه عديم النفع في اللحظة التي يُحتاج فيها بالضبط، والمهندس الهادئ الذي يملك دليلاً مُختبَراً يستعيد في ساعةٍ ما يعيد اكتشافه المهندس المذعور في يوم.
الحد الأدنى لموقعٍ تجاري هو نسخٍ يوميةٍ مؤتمتة، مع تصدير قاعدة البيانات بشكلٍ أكثر تكراراً إذا كانت البيانات تتغير باستمرار — كل بضع ساعات، أو استعادةٌ نقطيةٌ مستمرة لو كان فقدان صباحٍ كاملٍ من العمليات مؤلماً. يحدّد الفاصل الصحيح هدفُ نقطة الاستعادة: إجابة "كم عملاً جديداً يمكننا تحمّل خسارته؟" مقاساً بالساعات، لا قاعدةً عامة.
نسخ المزوِّد طبقةٌ أولى مفيدة، وعلى منصةٍ جيدة تكون موثوقة، لكنها ليست خطة استعادة كوارث. غالباً تعيش في الحساب نفسه ونطاق الفشل نفسه الذي يعيش فيه الخادم، وكثيراً ما تكون تكلفةً إضافيةً تُستبعد عند ضغط الميزانية، وإذا اخترق حساب المزوِّد ضاع الخادم ونسخه معاً. احتفظ بنسخة المزوِّد، وأضِف نسخةً تتحكم بها خارج ذلك الحساب — هذه هي النسخة البعيدة التي وُجدت قاعدة 3-2-1 لفرضها.
بأن تستعيدها. نجاح مهمة النسخ يثبت فقط أن السكربت جرى وأن ملفاً كُتب، ولا يقول شيئاً عمّا إذا كان الملف كاملاً أو سليماً أو قابلاً للاستعادة. الفحص الوحيد الموثوق هو تمرين استعادةٍ في بيئةٍ تجريبية — وفّر خادماً جديداً، أعد بناء المكدس من النسخة، وقارن بياناتٍ حقيقيةً بالأصل. أجره مرةً كل ربعٍ على الأقل، واحسب زمنه، فالاستعادة التي تنجح لكنها تستغرق يوماً كاملاً تغيّر خططك.
خوادم VPS تُنشر بقصة استعادةٍ تعمل — نسخٌ يومية لقاعدة البيانات ونسخٌ بعيدة واستعادةاتٌ مُختبَرة كجزءٍ من الخدمة المُدارة.
نصف المنع من هذا الدليل — مفاتيح SSH وجدار الحماية والتحديثات التلقائية وTLS، فتصل حوادثُ أقل إلى النسخة الاحتياطية.
موقع خادمك يحدّد زمن الوصول ونطاق فشله — السؤال نفسه الذي تطرحه قبل وضع نسخةٍ بعيدة.
تتولى إيجي ماس الاستضافة والأمان والإدارة المستمرة - لتتفرغ أنت لمنتجك.
احصل على استشارة مجانية