خطة التعافي من الكوارث للسيرفرات: سيرفر احتياطي في دولة ثانية

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

معنى RPO وRTO ببساطة

• RPO (نقطة الاستعادة المستهدفة): مقدار البيانات الذي تتحمل خسارته، مقاسًا بالزمن. RPO قدره 24 ساعة يعني أن الرجوع إلى حالة الأمس مقبول. أما RPO قدره دقيقة واحدة فيعني أنك تحتاج نسخًا متماثلًا شبه مستمر.

• RTO (زمن الاستعادة المستهدف): المدة التي تتحمل فيها توقف الخدمة. RTO قدره يوم يسمح ببناء سيرفر جديد من النسخ الاحتياطية. وRTO قدره ربع ساعة يعني أن السيرفر الاحتياطي يجب أن يكون شغالًا بالفعل.

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

النسخ الاحتياطي ليس خطة تعافٍ من الكوارث

النسخ الاحتياطي يجيب عن سؤال: هل أستطيع استرجاع بياناتي؟ أما التعافي من الكوارث فيجيب عن سؤال آخر: كم من الوقت أحتاج لأعود للعمل من مكان آخر؟ تحتاج الاثنين، وكل منهما يفشل بطريقة مختلفة:

• النسخة المحفوظة على السيرفر نفسه أو في المنشأة نفسها قد تضيع في الحادث نفسه الذي أصاب السيرفر.

• النسخة التي لم تجرّب استرجاعها أبدًا مجرد أمل وليست خطة، واسترجاع قواعد البيانات الكبيرة قد يستغرق أطول بكثير مما يتوقعه الناس.

• النسخ المتماثل (replication) ليس نسخًا احتياطيًا: إذا حذف أحدهم جدولًا على السيرفر الأساسي، يُحذف من النسخة المتماثلة بعده بلحظات.

ابدأ بنظام نسخ احتياطي سليم، ويفضل قاعدة 3-2-1 المشروحة في دليل استراتيجية النسخ الاحتياطي لسيرفر VPS، ثم أضف سيرفرًا احتياطيًا للأنظمة التي لا يكفي الاسترجاع من النسخ لتحقيق RTO الخاص بها.

الاحتياطي البارد والدافئ والساخن

الاحتياطي البارد (Cold standby)

لا يوجد سيرفر ثانٍ يعمل يوميًا. تحتفظ بالنسخ الاحتياطية والإعدادات في موقع آخر، وعند الكارثة تطلب أو تشغّل سيرفرًا في منطقة أخرى وتثبت البيئة وتسترجع البيانات. هو الخيار الأرخص، لكن RTO يُقاس بالساعات، وRPO يساوي عمر أحدث نسخة محفوظة خارج الموقع.

الاحتياطي الدافئ (Warm standby)

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

الاحتياطي الساخن (Hot standby)

نسخة كاملة الحجم تعمل في المنطقة الثانية ويمكنها استقبال الزيارات فورًا، وأحيانًا تخدم المستخدمين طوال الوقت فيما يُعرف بـ active-active. يقترب RTO وRPO من الصفر، لكنك تدفع ثمن بيئتي إنتاج كاملتين وتتحمل تعقيدًا حقيقيًا: تعارض البيانات، وإدارة الجلسات، واختبار كل تغيير في المكانين.

لماذا يجب أن يكون الاحتياطي في دولة أخرى؟

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

اختر الثنائي المناسب حسب جمهورك وقواعد بياناتك:

• القاهرة مع لندن: مناسب للخدمات الموجهة للشرق الأوسط؛ القاهرة أساسي لمستخدمي مصر، ولندن احتياطي جيد الاتصال.

• وارسو مع برلين: يبقي النسختين داخل الاتحاد الأوروبي، ما يبسّط أسئلة مكان البيانات للخدمات الموجهة لأوروبا. موقع السيرفر جزء واحد فقط من الامتثال لـ GDPR، فراجع التزاماتك. يشرح دليل سيرفر VPS في بولندا ودليل سيرفر VPS في ألمانيا كل طرف بالتفصيل.

• لندن مع وارسو أو برلين: مناسب لجمهور أوروبي موزع بين بريطانيا والبر الأوروبي.

المسافة تؤثر في النسخ المتماثل أيضًا. بين دولتين اجعل النسخ غير متزامن (asynchronous)، لأن النسخ المتزامن يجعل كل عملية كتابة تنتظر تأكيد الموقع البعيد، فيُضاف زمن الرحلة إلى كل معاملة.

أساسيات النسخ المتماثل لقاعدة البيانات

في PostgreSQL الطريقة المعتادة هي streaming replication. على السيرفر الاحتياطي انسخ السيرفر الأساسي ودع pg_basebackup يكتب إعدادات النسخ بنفسه:

# على السيرفر الاحتياطي، مع إيقاف PostgreSQL ومجلد بيانات فارغ
sudo -u postgres pg_basebackup -h PRIMARY_IP -U replicator \
  -D /var/lib/postgresql/16/main -R -X stream -P

الخيار -R ينشئ ملف standby.signal وإعدادات الاتصال، فيبدأ السيرفر كنسخة للقراءة فقط. يحتاج السيرفر الأساسي إلى مستخدم مخصص للنسخ وسطر في pg_hba.conf يسمح له فقط من IP السيرفر الاحتياطي. اقصر المنفذ 5432 في الجدار الناري على هذا العنوان، أو مرّر النسخ عبر نفق WireGuard.

راقب التأخر على السيرفر الاحتياطي، فهذا التأخر هو RPO الحقيقي لديك:

SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;

عند التحويل رقِّ السيرفر الاحتياطي بالأمر SELECT pg_promote();. وقبل ذلك تأكد أن السيرفر الأساسي القديم لا يمكنه العودة وقبول عمليات كتابة من تلقاء نفسه، وإلا ستنتهي بقاعدتي بيانات تعتبر كل منهما نفسها الأساسية. ويوفر MySQL وMariaDB نسخًا متماثلًا مشابهًا يعتمد على binary log وبنفس التحفظات.

الملفات والإعدادات والأسرار

• زامن الملفات المرفوعة وملفات المستخدمين بالأمر rsync -az بشكل مجدول، أو استخدم أداة نسخ مثل restic تحفظ لقطات مشفرة في المنطقة الثانية.

• احفظ إعداد السيرفر في سكربتات أو ملفات Docker Compose داخل نظام إدارة إصدارات، ليُبنى الاحتياطي بالطريقة نفسها التي بُني بها الأساسي.

• احفظ كلمات المرور وملفات البيئة في مكان يصل إليه المسؤول المناوب حتى لو اختفى السيرفر الأساسي.

• خطط لشهادات TLS: انسخها إلى الاحتياطي، أو تأكد أنه يستطيع طلب شهادات جديدة بعد توجيه DNS إليه.

• أوقف المهام المجدولة على الاحتياطي حتى ترقيته، حتى لا تُرسل الرسائل أو الفواتير أو عمليات المزامنة مرتين.

التحويل عبر DNS وقيمة TTL

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

dig +noall +answer example.com A

اخفض TTL للسجلات المهمة إلى نحو 300 ثانية قبل حاجتك إليها بوقت كافٍ، لأن القيمة القديمة الأطول يجب أن تنتهي أولًا. بعض الخوادم تحتفظ بالسجلات أطول مما يُطلب منها، فتوقع أن يستمر جزء من الزيارات في الوصول إلى العنوان القديم لفترة. كثير من مزودي DNS يوفرون تحويلًا تلقائيًا مبنيًا على فحص صحة السيرفر. وإذا كان موقعك خلف CDN يعمل كوكيل (proxy)، فتغيير السيرفر الأصلي هناك يسري دون انتظار ذاكرة DNS لدى الزوار.

اكتب دليل التشغيل ثم اختبره

دليل التشغيل (runbook) قائمة مرقمة يستطيع أي شخص اتباعها في الثالثة فجرًا تحت الضغط. اجعله قصيرًا ومحددًا:

1. من يقرر التحويل، وكيف يُتواصل معه.

2. كيف تتأكد أن السيرفر الأساسي متوقف فعلًا وليس مجرد انقطاع شبكة عابر.

3. كيف تعزل السيرفر الأساسي القديم (إيقاف قاعدة البيانات، حظره في الجدار الناري).

4. الأوامر الدقيقة لترقية قاعدة البيانات وتشغيل التطبيق على الاحتياطي.

5. تغييرات DNS أو CDN مكتوبة بالسجلات والقيم.

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

7. كيفية العودة إلى المنطقة الأساسية بعد تعافيها، بما في ذلك إعادة مزامنة البيانات.

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

موازنة التكلفة

• البارد: تدفع مقابل التخزين خارج الموقع فقط، وتقبل توقفًا لساعات.

• الدافئ: تدفع مقابل سيرفر أصغر يعمل دائمًا، وتقبل تحويلًا يدويًا قصيرًا.

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

قارن هذه التكلفة بما تكلفه ساعة توقف أو يوم بيانات ضائعة على عملك. ضمانات التشغيل مفيدة أيضًا، لكن اقرأ ما تغطيه: يوضح مقال ماذا تعني نسبة تشغيل 99.9% لماذا تمثل اتفاقية SLA تعويضًا وليست خطة تعافٍ.

أسئلة شائعة

هل النسخ الاحتياطي اليومي كافٍ كخطة تعافٍ؟

فقط إذا كنت تقبل خسارة ما يصل إلى يوم من البيانات، إضافة إلى الوقت اللازم لإعادة البناء والاسترجاع في مكان آخر. احفظ النسخة في موقع مختلف وجرّب الاسترجاع لتعرف زمن التعافي الحقيقي.

هل يمكن أن يكون السيرفر الاحتياطي أصغر من الأساسي؟

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

هل أستخدم النسخ المتزامن بين دولتين؟

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

كم مرة يجب اختبار التحويل؟

عدة مرات في السنة على الأقل، وبعد أي تغيير كبير في البنية. دليل التشغيل غير المجرَّب يفشل عادة في أول حادث حقيقي.

بناء إعداد من منطقتين مع IM HOST

تعمل IM HOST في خمس دول: القاهرة ولندن ووارسو وبرلين ونيويورك، والمتوفر حاليًا معروض في صفحة مراكز البيانات، فيمكن أن يكون السيرفر الأساسي والاحتياطي في دولتين مختلفتين لدى مزود واحد. تتضمن خدمة Cloud VPS نسخًا احتياطيًا تلقائيًا مجانيًا كل 72 ساعة، وهي نسخة إضافية مفيدة بجانب نسخ قاعدة البيانات التي تأخذها بنفسك. ويمنحك سيرفر Linux VPS صلاحيات root كاملة على KVM وNVMe لبناء النسخ المتماثل بنفسك، مع إمكانية إضافة نسخ احتياطي يومي كخدمة إضافية.