كيفية نقل سيرفر كامل من Hetzner إلى DigitalOcean

تُمثّل طريقة نقل سيرفر كامل من Hetzner إلى DigitalOcean عملية برمجية وتقنية دقيقة تتطلب تخطيطاً سليماً لنقل الملفات وقواعد البيانات وإعدادات النظام دون فقدان البيانات أو انقطاع طويل في الخدمة (Downtime). وتستهدف هذه الخطوات مديري السيرفرات (SysAdmins)، والمطورين، وأخصائيي الديف أوبس (DevOps)؛ حيث تعتمد العملية أساساً على أخذ نسخ احتياطية شاملة (Backups)، واستخدام أدوات المزامنة المباشرة مثل Rsync لنقل الملفات عبر اتصال SSH مشفر، وتصدير قواعد البيانات عبر mysqldump، ثم إعادة توجيه سجلات DNS إلى قطرة (Droplet) ديجيتال أوشن الجديدة.

طريقة نقل سيرفر كامل من Hetzner إلى DigitalOcean

التخطيط والتجهيز قبل بدء عملية النقل

قبل البدء في نقل البيانات، يجب إعداد البيئة الجديدة لضمان سلاسة الانتقال:

• إنشاء سيرفر جديد على DigitalOcean (Droplet): اختر نظام تشغيل مطابخاً لنظام سيرفر Hetzner الحالي (مثل Ubuntu 22.04 / 24.04 أو Debian) مع مواصفات موارد (RAM & CPU) كافية.
• تقليل زمن التخزين المؤقت للـ DNS (TTL): قم بتخفيض قيمة TTL لسجلات نطاقك (Domain) إلى 300 ثانية (5 دقائق) على الأقل قبل النقل بـ 24-48 ساعة لسرعة التوجيه لاحقاً.
• إعداد مفاتيح SSH: قم بتأمين الاتصال المباشر عبر مفاتيح SSH بين سيرفر Hetzner وسيرفر DigitalOcean لتسهيل نقل البيانات الآمن.

مقارنة بين Hetzner وDigitalOcean عند النقل

لا تقم بإلغاء اشتراكك أو مسح بيانات سيرفر Hetzner إلا بعد مرور 72 ساعة على الأقل من نقل الـ DNS والتأكد التام من استقرار جميع الخدمات والمواقع على DigitalOcean. ويقودنا هذا الانتقال السحابي للغوص في تفاصيل أسرار تحسين أداء السيرفرات السحابية وإعداد جدران الحماية UFW بهذا المقال، مع كشف لمحة عن كيفية إعداد النسخ الاحتياطي الآلي على DigitalOcean Snapshots، وتفكيك أفضل الممارسات لإدارة خوادم Nginx بفاعلية عالية.

التخطيط لنقل سيرفر كامل من Hetzner إلى DigitalOcean بأمان

تبدأ عملية نقل سيرفر كامل من Hetzner إلى DigitalOcean بفهم البيئة الحالية باعتبارها مجموعة مترابطة من الخدمات والبيانات والإعدادات، وليس مجرد ملفات يمكن نسخها من عنوان IP إلى آخر. فالسيرفر قد يضم خادم ويب مثل Nginx أو Apache، وقواعد بيانات MySQL أو PostgreSQL، وإصدارات محددة من PHP أو Node.js، وشهادات TLS، ومهام Cron، وحسابات مستخدمين، ومفاتيح SSH، وملفات إعداد موزعة داخل /etc، إضافة إلى تطبيقات تعمل عبر Docker أو خدمات systemd. لذلك ينبغي أن يسبق نقل سيرفر فعلي حصر هذه المكونات وتحديد أحجام الأقراص واستهلاك الذاكرة والمعالج والمنافذ والخدمات النشطة، مع تسجيل إصدارات نظام التشغيل والبرمجيات الأساسية. ويكتسب توافق النظام أهمية خاصة عند الانتقال بين مزودين مختلفين، لأن استنساخ محتويات القرص بصورة عمياء قد ينقل إعدادات مرتبطة بشبكة Hetzner أو بطريقة الإقلاع والتخزين الخاصة بالبيئة القديمة إلى Droplet ذي بنية مختلفة.

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

ولا تكتمل خطة نقل سيرفر دون معايير واضحة للتحقق بعد الترحيل. تشمل هذه المعايير التأكد من استجابة HTTP وHTTPS، واتصال التطبيقات بقواعد البيانات، وصحة الصلاحيات والملكية، وتشغيل الخدمات بعد إعادة الإقلاع، وسلامة مهام Cron، والشهادات، والبريد إن كان مستضافًا على السيرفر، وأي عمليات خلفية أو Queues يعتمد عليها النظام. كما يجب الانتباه إلى أن عنوان IP العام سيتغير عند الانتقال إلى DigitalOcean، وهو ما قد يؤثر في قوائم السماح لدى خدمات خارجية أو اتصالات API أو إعدادات قواعد البيانات البعيدة. وتبقى النسخة الاحتياطية المستقلة ونقطة الرجوع إلى Hetzner جزءًا من الخطة حتى بعد نجاح التحويل، إلى أن تمر فترة مراقبة كافية تثبت استقرار البيئة الجديدة وعدم وجود بيانات أو خدمات أغفلت أثناء النقل.

إنشاء DigitalOcean Droplet واختيار الموارد المناسبة للسيرفر الجديد

يمثل DigitalOcean Droplet آلة افتراضية تعمل بنظام Linux، ولذلك ينبغي اختيار مواصفاته انطلاقًا من الحمل الحقيقي للسيرفر المصدر لا من اسم الخطة أو السعر وحدهما. تبدأ المقارنة بقياس عدد أنوية vCPU المستخدمة، والذاكرة RAM، والمساحة المشغولة فعليًا، ومعدل نمو البيانات، وطبيعة الحمل على القرص والمعالج. فإذا كان سيرفر Hetzner يحتوي على 160 جيجابايت من البيانات مثلًا، فلن يكون Droplet بقرص قريب جدًا من هذا الحجم خيارًا مريحًا، لأن عملية النقل والتحديثات والسجلات وقواعد البيانات تحتاج إلى مساحة احتياطية. وينطبق المبدأ نفسه على الذاكرة؛ فالانتقال إلى RAM أقل من الاستهلاك الفعلي قد يؤدي إلى الاعتماد المفرط على Swap أو توقف العمليات تحت الضغط، حتى لو بدا السيرفر طبيعيًا أثناء الاختبارات محدودة الحركة.

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

وبعد إنشاء Droplet تصبح مرحلة التحقق من البنية الجديدة ضرورية قبل بدء نقل سيرفر الإنتاج إليه. ينبغي التأكد من القرص المتاح، والذاكرة، والمعالج، والشبكة، وإصدار النظام، والمنطقة الزمنية، ثم تثبيت حزمة البرمجيات التي يتطلبها التطبيق بإصدارات متوافقة. وتوصي DigitalOcean في إعداد Ubuntu للإنتاج باستخدام مصادقة SSH بالمفاتيح مع مستخدم غير root يمتلك صلاحيات sudo، وتعطيل الوصول إلى root بكلمة مرور، والاستفادة من Cloud Firewall والنسخ الاحتياطي. كما تساعد مراقبة استهلاك الموارد في معرفة ما إذا كانت المواصفات المختارة مناسبة بعد بدء الحمل الحقيقي، بدل الاعتماد على تقديرات ما قبل الترحيل وحدها. بهذه الصورة يصبح Droplet بيئة مستهدفة مجهزة للاختبار والمزامنة، لا مجرد خادم فارغ تنتقل إليه البيانات قبل التأكد من جاهزيته.

إعداد SSH وFirewall وUFW وتأمين الاتصال بين السيرفرين

يعتمد الاتصال بين Hetzner وDigitalOcean أثناء الترحيل بدرجة كبيرة على SSH، سواء استُخدم مباشرة للإدارة أو بوصفه قناة مشفرة لأدوات مثل rsync وscp. وتوفر مفاتيح SSH أساسًا أمنيًا أفضل من الاعتماد على كلمات المرور، مع إمكانية تخصيص مفتاح لعملية الترحيل ثم إلغائه بعد انتهائها. وعلى Droplet الجديد يكون إنشاء مستخدم إداري غير root ومنحه الصلاحيات اللازمة أكثر ملاءمة لبيئة الإنتاج، مع تقييد تسجيل الدخول المباشر للحساب الجذري. كما يمكن قصر منفذ SSH على عناوين IP موثوقة متى كانت العناوين ثابتة، بحيث لا يصبح المنفذ متاحًا لجميع المصادر على الإنترنت دون حاجة تشغيلية.

ويعمل DigitalOcean Cloud Firewall على مستوى الشبكة المحيطة بالـDroplet، بينما يوفر UFW جدار حماية على مستوى نظام التشغيل، ويمكن استخدامهما في طبقات متكاملة بشرط الحفاظ على اتساق القواعد بينهما. تسمح القواعد عادة بالمنافذ التي تحتاجها الخدمة فقط، مثل SSH للإدارة وHTTP وHTTPS لخادم الويب، مع رفض الاتصالات الواردة غير الضرورية. ومن النقاط الحساسة عند تفعيل UFW ضمان السماح باتصال SSH أولًا؛ لأن تطبيق سياسة جدار ناري قبل فتح منفذ الإدارة قد يؤدي إلى فقدان الجلسة ومنع الاتصال بالسيرفر. كما ينبغي التعامل بحذر مع منافذ قواعد البيانات مثل 3306 أو 5432، إذ لا توجد حاجة عادة إلى جعلها متاحة للعالم إذا كانت قاعدة البيانات والتطبيق يعملان على السيرفر نفسه أو كان الاتصال الخارجي محصورًا في مصدر معروف.

أما قناة الاتصال بين السيرفرين فتحتاج إلى قواعد مؤقتة تتناسب مع أسلوب نقل البيانات. فإذا كانت عملية نقل سيرفر تعتمد على تشغيل rsync عبر SSH من أحد الخادمين إلى الآخر، يكفي توفير المسار الشبكي الضروري بين عنواني IP وفق اتجاه الاتصال المستخدم، بدل فتح منافذ إضافية واسعة. وبعد اكتمال النقل يمكن إزالة أي قواعد أو مفاتيح أضيفت خصيصًا للترحيل. ومن المفيد أيضًا اختبار جلسة SSH ثانية قبل إنهاء الجلسة الإدارية الحالية عند تغيير إعدادات sshd أو UFW، لأن نجاح الاختبار يؤكد أن القواعد الجديدة لم تغلق منفذ الإدارة. الجمع بين مصادقة المفاتيح، وأقل عدد ممكن من المنافذ، وCloud Firewall، وUFW، وإلغاء الصلاحيات المؤقتة بعد الترحيل يقلل مساحة الهجوم ويحافظ على قناة موثوقة لنقل البيانات.

إنشاء Backup كامل وتقليل DNS TTL قبل بدء عملية الترحيل

تسبق النسخة الاحتياطية عملية الترحيل لأنها تمثل نقطة الاستعادة عندما ينتج خطأ عن النسخ أو تعديل الإعدادات أو مزامنة قواعد البيانات. توفر Hetzner نسخ Backups وSnapshots لقرص السيرفر، ويمكن استخدامهما لاستعادة حالة سابقة أو إنشاء سيرفر من النسخة، لكن هذه النسخ لا تشمل Volumes المرفقة بالسيرفر. لذلك يجب أن يتوافق مفهوم النسخة الكاملة مع بنية النظام الفعلية؛ فإذا كانت بيانات مهمة موجودة على Volume منفصل، فإن Snapshot للقرص الأساسي وحده لا يمثل Backup كاملًا للبيئة. كما أن وجود نسخة على مستوى القرص لا يلغي أهمية نسخ البيانات الحرجة بصورة مستقلة، ولا سيما قواعد البيانات وملفات التطبيقات والإعدادات التي قد تحتاج إلى استعادة منفصلة أو التحقق من سلامتها قبل التحويل النهائي.

وتتطلب قواعد البيانات عناية أكبر من نسخ المجلدات التقليدية، لأن نسخ ملفات قاعدة نشطة أثناء عمليات الكتابة قد ينتج حالة غير متسقة. ولهذا ينبغي أن تراعي آلية النسخ طبيعة محرك قاعدة البيانات، سواء باستخدام أدوات النسخ المنطقي المناسبة أو آلية Backup متوافقة مع المحرك، ثم اختبار إمكانية قراءة النسخة أو استعادتها قبل اعتبارها نقطة أمان. أما ملفات المواقع والتطبيقات والإعدادات فيمكن نقلها باستخدام أدوات تحافظ على الخصائص المطلوبة مثل الملكية والصلاحيات والروابط الرمزية بحسب طريقة التشغيل. وتدعم وثائق Hetzner استخدام scp أو rsync ل ـنقل البيانات عند استعادتها أو تأمينها، مع إمكانية الاحتفاظ بـSnapshot أو Backup كطبقة إضافية للاسترجاع. وتصبح هذه الاحتياطات أكثر أهمية عندما يتضمن نقل سيرفر بيانات تتغير باستمرار، لأن النسخة الأولية قد تختلف عن الحالة النهائية لحظة تحويل حركة المستخدمين.

ويرتبط تقليل DNS TTL بالمرحلة الأخيرة من الانتقال، إذ تحدد قيمة Time To Live المدة التي يمكن أن تحتفظ خلالها محللات DNS بالسجل في الذاكرة المؤقتة قبل انتهاء صلاحيته. تقليل TTL مسبقًا يجعل الانتقال إلى عنوان IP الجديد أكثر مرونة بعد تعديل سجل A أو AAAA، لكن خفض القيمة في اللحظة نفسها التي يتغير فيها عنوان IP لا يزيل النسخ القديمة التي سبق تخزينها بقيمة TTL الأعلى. لذلك يُفضّل إجراء التغيير قبل نافذة الترحيل بمدة تسمح بانتهاء القيمة السابقة لدى معظم المحللات. وإذا كانت إدارة DNS ستنتقل هي الأخرى إلى DigitalOcean، فمن الضروري إعادة إنشاء السجلات المستخدمة قبل تغيير خوادم الأسماء حتى لا تتحول عملية نقل سيرفر ناجحة إلى انقطاع سببه DNS. وبعد استقرار الخدمة على Droplet الجديد وانتهاء فترة المراقبة يمكن إعادة TTL إلى قيمة تشغيلية مناسبة، مع الاحتفاظ بسيرفر Hetzner والنسخ الاحتياطية مؤقتًا إلى أن يصبح الرجوع إلى البيئة القديمة غير ضروري.

نقل ملفات وإعدادات Linux إلى سيرفر DigitalOcean الجديد

تبدأ عملية نقل سيرفر من Hetzner إلى DigitalOcean من التعامل مع الخادم الجديد بوصفه بيئة مستقلة يجب أن تستوعب البيانات والخدمات والهوية التشغيلية للخادم القديم، وليس مجرد مساحة تُنسخ إليها الملفات. لذلك ترتبط جودة الترحيل بمدى التقارب بين توزيعة Linux والإصدارات والحزم ومسارات التخزين المستخدمة في البيئتين. اختيار إصدار Ubuntu أو Debian مماثل قدر الإمكان للإصدار الموجود على Hetzner يقلل احتمالات تعارض المكتبات وملفات الإعداد، مع ضرورة مراعاة اختلاف عنوان IP وواجهة الشبكة وقواعد الجدار الناري ومساحة القرص. ولا يعني نقل نظام الملفات بالكامل أن نسخ كل شيء من / هو الخيار الأنسب، لأن بعض المسارات مثل /proc و/sys و/dev و/run تمثل أنظمة ملفات افتراضية أو بيانات مرتبطة مباشرة بالنواة والجلسة الحالية، بينما تتركز البيانات القابلة للترحيل عادة في /home و/var/www ومسارات التطبيقات وملفات الإعداد الموجودة في /etc ومواقع البيانات المخصصة. وتعرض وثائق Hetzner الخاصة بالترحيل المبدأ نفسه بصورة عامة، إذ تفصل بين نقل البيانات الشخصية ونسخ قسم النظام كاملاً، وهو تمييز مهم عند الانتقال بين مزودين مختلفين.

تزداد أهمية هذا الفصل عندما يحتوي خادم Hetzner على خدمات قواعد بيانات أو تطبيقات تكتب إلى القرص باستمرار. فالنسخة الأولى من الملفات يمكن تنفيذها بينما تظل الخدمات تعمل، لكن البيانات المتغيرة تحتاج إلى مزامنة نهائية في نافذة انتقال قصيرة حتى لا يصبح سيرفر DigitalOcean الجديد متأخراً عن المصدر لحظة تحويل حركة المرور إليه. قواعد MySQL أو MariaDB أو PostgreSQL، على سبيل المثال، لا يُفضّل التعامل مع ملفاتها الداخلية على أنها ملفات عادية يمكن نسخها أثناء استمرار عمليات الكتابة؛ سلامة البيانات تعتمد على نسخة متسقة، سواء أُنشئت من أدوات النسخ المنطقي المناسبة أو من آلية نسخ احتياطي متوافقة مع قاعدة البيانات المستخدمة. وينطبق المبدأ نفسه على التطبيقات التي تحفظ الجلسات أو الملفات المرفوعة أو طوابير المهام محلياً. لهذا يصبح نقل سيرفر عملية ذات مرحلتين في البيئات النشطة: نقل أولي للكتلة الأكبر من البيانات، ثم مزامنة أخيرة بعد إيقاف الكتابة أو تحويل التطبيق إلى وضع صيانة، بما يقلص فترة التوقف بدلاً من ترك عملية النسخ الكاملة إلى لحظة التحويل.

أما إعداد DigitalOcean نفسه فينبغي أن يعكس احتياجات النظام المنقول قبل تشغيله فعلياً. يلزم التأكد من توفر مساحة كافية للملفات وقواعد البيانات وDocker Volumes، ومن تثبيت الحزم التي تعتمد عليها التطبيقات، وضبط المنطقة الزمنية واللغة وإعدادات النظام المؤثرة في الخدمات عند الحاجة. كما ينبغي الفصل بين العناصر التي يمكن نسخها مباشرة والعناصر التي تحتاج إلى إعادة إنشاء بما يناسب الخادم الجديد؛ فمفاتيح SSH العامة وحسابات التطبيقات وملفات إعداد المواقع قابلة للترحيل، في حين أن إعدادات الشبكة المرتبطة بعنوان Hetzner القديم أو أسماء واجهات الشبكة لا ينبغي استعادتها بصورة عمياء. وبعد اكتمال البيانات والخدمات تأتي مرحلة تحويل DNS أو أي موازن تحميل إلى عنوان DigitalOcean الجديد، مع إبقاء Hetzner متاحاً مؤقتاً للتحقق أو التراجع عند ظهور مشكلة. بهذه الصورة يكون نقل سيرفر انتقالاً منظماً لحالة النظام والخدمات والبيانات، لا مجرد عملية نسخ بين عنواني IP.

استخدام rsync وSSH لمزامنة ملفات السيرفر والصلاحيات

يجمع rsync بين النقل عبر الشبكة والمزامنة التفاضلية، ولذلك يناسب البيئات التي تحتوي على كمية كبيرة من البيانات أو التي تحتاج إلى أكثر من تمريرة قبل الانتقال النهائي. عند تشغيله فوق SSH تبقى عملية النقل معتمدة على قناة اتصال مشفرة ومصادقة يمكن إدارتها بمفاتيح SSH، بينما يتولى rsync مقارنة المصدر والوجهة ونقل الاختلافات المطلوبة بدلاً من إعادة إرسال جميع الملفات في كل مرة. ومن الخيارات الشائعة في هذا السياق نمط الأرشفة -a، الذي يحافظ على خصائص أساسية مثل البنية التكرارية والأزمنة والروابط الرمزية والمالكين والمجموعات والصلاحيات بحسب صلاحيات المستخدم وظروف النظام، ويمكن إضافة خيارات أخرى عندما يلزم الحفاظ على ACLs أو extended attributes. لهذا السبب يكون rsync أكثر ملاءمة من نسخ تقليدي لمجلدات Linux الحساسة للصلاحيات، خصوصاً عند نقل مواقع الويب ومجلدات المستخدمين وملفات التطبيقات بين Hetzner وDigitalOcean. كما تدعم Hetzner استخدام SSH وrsync في خدماتها التخزينية، وتستخدم أدلة DigitalOcean الخاصة بترحيل خوادم Linux النهج نفسه لنقل البيانات بين الأنظمة.

يكتسب الحفاظ على المالكين والأذونات أهمية خاصة لأن تطابق محتوى الملفات وحده لا يضمن عمل الخدمة. قد تصل ملفات موقع ويب كاملة إلى الخادم الجديد، لكن اختلاف UID أو GID الخاص بالمستخدم الذي يشغل PHP-FPM أو التطبيق قد يمنع الكتابة داخل مجلدات التخزين. وقد تنتقل مفاتيح SSH الخاصة بحساب ما ثم تتوقف المصادقة بسبب صلاحيات غير صحيحة على .ssh أو authorized_keys. لذلك يرتبط نقل سيرفر عبر rsync بمراجعة الهوية الرقمية للمستخدمين والمجموعات، وليس بأسمائهم فقط. ويزداد الأمر حساسية عند نقل ملفات النظام، إذ إن تشغيل المزامنة بحساب عادي قد يؤدي إلى فقدان ملكية root أو بعض السمات التي لا يملك ذلك الحساب حق إنشائها. وفي المقابل، تشغيل المزامنة بصلاحيات مرتفعة يستدعي ضبط الاستبعادات بعناية حتى لا تُكتب ملفات خاصة بالنظام القديم فوق مكونات DigitalOcean الجديدة، مثل تكوينات الإقلاع أو الشبكة أو أنظمة الملفات الافتراضية.

وتظهر الفائدة الأكبر لـrsync في نموذج المزامنة المتدرجة. يمكن نقل مئات الجيجابايت من البيانات مسبقاً بينما يعمل Hetzner بصورة طبيعية، ثم إعادة تشغيل المزامنة لاحقاً بحيث يقتصر النقل غالباً على الملفات التي تغيرت منذ الجولة الأولى. وعند الوصول إلى لحظة الانتقال يمكن إيقاف الخدمات التي تولد تغييرات مستمرة، وتنفيذ مزامنة نهائية، ثم تشغيل الخدمات على DigitalOcean وإجراء اختبارات الاستجابة قبل تحويل حركة المستخدمين. بعض البيئات تستفيد كذلك من خيار –delete لجعل الوجهة مرآة للمصدر، لكنه خيار ذو أثر مباشر لأنه يحذف من الوجهة ما لم يعد موجوداً في المصدر، وبالتالي لا يناسب الاستخدام غير المدروس. كما أن استثناء ملفات السجلات المؤقتة والكاش وملفات PID قد يقلل الضوضاء والحجم عندما تكون هذه البيانات قابلة لإعادة الإنشاء. والنتيجة أن SSH يؤمّن قناة الوصول، في حين يوفر rsync آلية عملية للحفاظ على بنية الملفات وتقليل كمية النقل في المزامنات اللاحقة.

نقل إعدادات Nginx أو Apache والمستخدمين وCron Jobs

تمثل إعدادات خادم الويب جزءاً صغيراً من حجم البيانات لكنها من أكثر مكونات الترحيل تأثيراً في نجاح التشغيل. ففي Nginx ترتبط المواقع عادة بملفات إعداد تحت /etc/nginx، وقد تشمل تعريفات server ومسارات الشهادات وإعدادات proxy وPHP-FPM وحدود الرفع وسياسات التخزين المؤقت. أما Apache فتتوزع إعداداته وفق التوزيعة بين ملفات الخدمة والمواقع والوحدات المفعلة، إلى جانب ملفات .htaccess عندما يعتمد التطبيق عليها. نسخ هذه الملفات إلى DigitalOcean لا يضمن وحده تطابق السلوك، لأن بعض التوجيهات قد تشير إلى إصدار PHP مختلف أو socket غير موجود أو عنوان IP قديم أو مسار شهادة لم ينتقل بعد. لذلك يرتبط نقل سيرفر هنا بإعادة تكوين البيئة التي تعتمد عليها الملفات، بما يشمل تثبيت الوحدات المطلوبة والتأكد من توفر منافذ الاستماع وإجراء اختبار لصحة إعداد Nginx أو Apache قبل إعادة تشغيله. وتكون شهادات TLS ومفاتيحها وملفات Let’s Encrypt من العناصر الحساسة التي تحتاج إلى الحفاظ على الأذونات والملكية، أو إعادة إصدار الشهادات عندما يكون ذلك أكثر ملاءمة لبنية البيئة الجديدة.

حسابات Linux والمجموعات تحتاج إلى معالجة أكثر دقة من نسخ /etc/passwd و/etc/group إلى الخادم الجديد بصورة كاملة. تلك الملفات تضم حسابات نظام أنشأتها الحزم والخدمات، وقد تختلف معرفاتها وترتيباتها بين تثبيت Hetzner القديم وDigitalOcean الجديد. النهج الأكثر أماناً من الناحية التشغيلية هو الحفاظ على الحسابات البشرية وحسابات التطبيقات المطلوبة مع UID وGID المناسبين عندما تعتمد الملفات على هذه الأرقام، ثم التأكد من ملكية البيانات بعد النقل. كما توجد بيانات أخرى مرتبطة بالمستخدم في /etc/shadow و/etc/gshadow ومجلدات home ومفاتيح SSH وملفات shell، ولذلك فإن هوية الحساب لا تنحصر في سطر واحد. أدلة DigitalOcean الخاصة بترحيل Linux تخصص مرحلة مستقلة للمستخدمين والمجموعات وcrontabs وإعدادات النظام الأخرى، بما يعكس أهمية نقل هذه الطبقة بعد البيانات والحزم بدلاً من معاملتها باعتبارها ملفات عادية فقط.

أما Cron Jobs فتؤثر مباشرة في المهام الدورية مثل النسخ الاحتياطي وإرسال البريد وتجديد بعض البيانات وتنظيف الملفات وتشغيل أوامر التطبيق. وقد توجد المهام في crontab الخاص بكل مستخدم، أو في /etc/crontab، أو داخل /etc/cron.d والمجلدات الدورية التابعة لـcron. ترحيلها دون مراجعة قد يؤدي إلى تشغيل المهمة نفسها على Hetzner وDigitalOcean في الوقت ذاته، وهو ما يسبب ازدواجية في إرسال الرسائل أو تنفيذ الفواتير أو النسخ الاحتياطية أو تحديث السجلات. كما قد تعتمد المهمة على مسار executable أو متغير بيئة أو عنوان داخلي أو مفتاح وصول لم يعد صالحاً على الخادم الجديد. لهذا يحتاج نقل سيرفر إلى فترة واضحة لا تكون فيها الوظائف المجدولة نشطة على النظامين بلا قصد؛ يمكن إبقاؤها معطلة على الوجهة أثناء المزامنة، ثم تفعيلها عند اعتماد DigitalOcean كبيئة الإنتاج. ويشمل التحقق أيضاً مؤقتات systemd timers عندما تستخدمها الخدمات بدلاً من cron، لأنها تؤدي وظيفة جدولة مشابهة لكنها لا تظهر ضمن crontab التقليدي.

ترحيل Docker Containers وDocker Volumes وإعدادات الخدمات

تختلف بيئات Docker عن عمليات نقل الملفات التقليدية لأن الحاوية نفسها ليست عادة العنصر الذي يحمل القيمة الدائمة. الصور يمكن إعادة تنزيلها من registry أو إعادة بنائها من Dockerfile، والحاويات يمكن إعادة إنشائها من تعريفات docker run أو Docker Compose، بينما توجد البيانات المهمة غالباً في named volumes أو bind mounts وقواعد البيانات والمجلدات التي يربطها التطبيق بالمضيف. وتوضح وثائق Docker أن volumes مصممة لاستمرار البيانات بصورة مستقلة عن دورة حياة الحاوية، كما تؤكد أن docker container export لا يصدر محتويات volumes المرتبطة بالحاوية. لذلك فإن الاعتماد على تصدير container ثم استيراده على DigitalOcean قد ينقل نظام ملفات الحاوية دون نقل بيانات التطبيق المحفوظة في volume، وهو أحد أكثر أسباب الترحيل الناقص شيوعاً في البيئات المعتمدة على Docker.

عند نقل سيرفر يعمل بـDocker، تكون ملفات Compose وملفات .env والأسرار وإصدارات الصور وتعريفات الشبكات والسياسات التشغيلية جزءاً من البنية التي يجب الحفاظ عليها أو إعادة إنشائها. فإذا كانت الصور موجودة في Docker Hub أو registry خاص، يمكن للبيئة الجديدة سحب الإصدارات نفسها، بينما يمكن حفظ الصور محلياً ونقلها عند عدم وجود registry مناسب. أما bind mounts فتتطلب نقل المجلدات الموجودة على نظام الملفات المضيف مع ملكيتها وصلاحياتها، لأنها ليست مخزنة داخل Docker volume مستقل؛ وتصف وثائق Docker الـbind mount بأنه ربط مباشر لملف أو مجلد على المضيف داخل الحاوية. Named volumes تحتاج بدورها إلى نسخة احتياطية واستعادة أو إلى نقل محتواها بطريقة تحفظ البيانات، مع مراعاة حالة الخدمة التي تستخدمها. قواعد البيانات الموجودة داخل volume تتطلب الاتساق نفسه المطلوب في قواعد البيانات التقليدية، فلا يكفي نسخ ملفاتها عشوائياً أثناء عمليات كتابة كثيفة لمجرد أن البيانات موجودة داخل Docker.

اكتمال ترحيل Docker يعتمد كذلك على إعادة إنتاج سلوك الخدمة خارج الحاويات. يجب أن تتوافق متغيرات البيئة مع عنوان قاعدة البيانات الجديدة، وأن تكون المنافذ والشبكات وقواعد firewall متاحة بالصورة المتوقعة، وأن تعمل سياسات restart وhealth checks والترتيب بين الخدمات كما كانت في Hetzner. وإذا كان Nginx الموجود على المضيف يعمل reverse proxy إلى حاويات داخلية، فإن تغيّر أسماء الشبكات أو المنافذ يمكن أن يمنع الوصول رغم نجاح تشغيل الحاويات ذاتها. ويتيح Docker إعادة إنشاء containers من الصور والتعريفات التشغيلية، بينما توصي وثائقه بالتعامل مع بيانات volumes عبر آليات النسخ والاستعادة أو الترحيل المخصصة بدلاً من اعتبارها جزءاً ضمنياً من صورة الحاوية. وعند اكتمال نقل سيرفر إلى DigitalOcean تظل مرحلة الاختبار ضرورية للتأكد من أن الحاويات ليست فقط في حالة running، بل إن التطبيقات نفسها تستجيب، والبيانات موجودة، والـvolumes مرتبطة بالخدمات الصحيحة، والسجلات لا تكشف أخطاء صلاحيات أو اتصالات أو متغيرات بيئة مفقودة.

ترحيل قواعد البيانات والمواقع دون فقدان البيانات

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

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

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

نقل MySQL وMariaDB وPostgreSQL إلى السيرفر الجديد

تحتاج قواعد MySQL وMariaDB وPostgreSQL إلى معاملة مستقلة عن بقية ملفات الموقع، لأن سلامة البيانات ترتبط بحالة المعاملات والجداول والعلاقات الداخلية في لحظة النسخ. في البيئات الصغيرة أو التي يمكنها تحمل نافذة توقف محدودة، يمثل التصدير المنطقي خيارًا واضحًا: تُستخرج قواعد MySQL عبر mysqldump، أو قواعد MariaDB باستخدام الأدوات المتوافقة معها مثل mariadb-dump، بينما يوفر PostgreSQL أداة pg_dump لإنشاء نسخة منطقية يمكن استعادتها على الخادم الجديد. وتفيد هذه الطريقة أيضًا عند اختلاف بنية التخزين الفعلية بين السيرفرين، لأنها تنقل تعريفات الكائنات والبيانات بطريقة يفهمها محرك قاعدة البيانات بدل الاعتماد على نسخ ملفات التخزين الداخلية وهي قيد الاستخدام.

يتطلب النقل كذلك الانتباه إلى توافق إصدارات محركات قواعد البيانات وإعدادات الترميز والمستخدمين والصلاحيات والإضافات قبل الاستعادة. ففي PostgreSQL، على سبيل المثال، يمكن أن ترتبط التطبيقات بامتدادات أو أدوار وقواعد صلاحيات لا يكفي نقل الجداول وحدها لإعادة إنتاجها، كما أن DigitalOcean تشترط في خدمة الترحيل المستمر الخاصة بقواعد PostgreSQL المُدارة ألا يكون إصدار المصدر أحدث من إصدار المجموعة المستهدفة. وفي MySQL وMariaDB ينبغي فحص المحركات المستخدمة، ومجموعات المحارف وcollations، والحسابات التي تعتمد عليها التطبيقات، ثم التحقق بعد الاستيراد من عدد قواعد البيانات والجداول ومن قدرة التطبيقات على القراءة والكتابة باستخدام بيانات الاتصال الجديدة. كما تساعد مراجعة صلاحيات مستخدمي MySQL على التأكد من أن التطبيق يعمل بالحسابات والامتيازات المناسبة بعد الانتقال. بذلك لا يتحول نقل سيرفر ناجح على مستوى الملفات إلى فشل عند طبقة التطبيق بسبب اختلاف إعداد صغير في قاعدة البيانات.

أما الأنظمة ذات معدل الكتابة المرتفع، فقد يكون الاعتماد على نسخة تصدير واحدة غير كافٍ إذا استمرت البيانات في التغير أثناء عملية الاستيراد. هنا تصبح المزامنة المستمرة أو replication أكثر ملاءمة عندما تسمح البنية بذلك. وتوفر قواعد البيانات المُدارة في DigitalOcean إمكانات ترحيل مستمر لـMySQL وPostgreSQL من مصادر خارجية، بحيث يستمر تطبيق التغييرات الواردة إلى المصدر خلال فترة الترحيل إلى أن يحين موعد التحويل. وإذا كانت قاعدة البيانات ستظل ذاتية الإدارة داخل Droplet بدل استخدام Managed Databases، فينبغي تصميم آلية النسخ أو replication وفق المحرك والإصدار المستخدمين، ثم إيقاف الكتابة على المصدر في نافذة التحويل الأخيرة والتأكد من وصول آخر المعاملات قبل توجيه التطبيق إلى قاعدة البيانات الجديدة.

مزامنة مواقع WordPress والملفات المتغيرة قبل التحويل النهائي

تحتوي مواقع WordPress على نوعين مترابطين من البيانات: قاعدة البيانات التي تضم المحتوى والإعدادات والمستخدمين والعديد من بيانات الإضافات، ونظام الملفات الذي يضم WordPress والقوالب والإضافات وملفات الوسائط داخل wp-content. ولهذا لا تكفي نسخة مبكرة من مجلد الموقع إذا استمر المستخدمون في رفع الصور أو تحديث الإضافات أو إنشاء محتوى جديد بعد أخذها. يمكن تنفيذ النقل الأولي بينما يعمل موقع Hetzner بصورة طبيعية، ثم استخدام rsync مرة أخرى قرب موعد التحويل لنقل الملفات التي تغيرت فقط، وهو ما يقلل حجم البيانات المطلوب تمريرها خلال النافذة النهائية مقارنة بإعادة نسخ الموقع بالكامل.

تظهر أهمية التنسيق بين مزامنة الملفات وقاعدة البيانات عندما يكون WordPress نشطًا حتى الدقائق الأخيرة. فقد يؤدي نقل قاعدة البيانات في وقت ونقل مجلد uploads في وقت مختلف إلى وجود سجل يشير إلى ملف لم يصل إلى الخادم الجديد، أو إلى انتقال ملف لا تتوافق حالته مع البيانات المخزنة في قاعدة البيانات. لذلك تُحصر الكتابات الجديدة خلال مرحلة التحويل الأخيرة قدر الإمكان، وتُجرى المزامنة النهائية للملفات والبيانات ضمن نافذة قصيرة ومحددة. كما ينبغي التأكد من أن إعدادات wp-config.php تتوافق مع قاعدة البيانات الجديدة، وأن المستخدم الذي يتصل بها يمتلك الصلاحيات المطلوبة، وأن ملكية الملفات وصلاحياتها على DigitalOcean مناسبة للمستخدم الذي تعمل تحته خدمة الويب وPHP.

بعد اكتمال المزامنة يصبح الاختبار قبل تعديل DNS عنصرًا حاسمًا في نقل سيرفر WordPress، إذ يمكن توجيه جهاز الاختبار محليًا إلى عنوان IP الجديد عبر ملف hosts من دون تغيير النطاق لجميع الزوار. يسمح ذلك بفحص الصفحات ولوحة الإدارة وتسجيل الدخول والوسائط والروابط الدائمة والنماذج والعمليات المرتبطة بالإضافات، مع مراقبة سجلات Nginx أو Apache وPHP وقاعدة البيانات بحثًا عن الأخطاء. وعند نجاح الاختبارات تُنفذ المزامنة الأخيرة ثم يتحول DNS إلى DigitalOcean. ويظل منع إجراء تعديلات مستقلة على نسختي WordPress بعد التحويل مهمًا، لأن استقبال عمليات كتابة على السيرفر القديم والجديد في الوقت نفسه يؤدي إلى انقسام البيانات ويجعل توحيد النسختين لاحقًا أكثر تعقيدًا.

إعداد شهادات SSL وLet’s Encrypt والتحقق من عمل الخدمات

لا تنتقل هوية TLS الخاصة بالموقع تلقائيًا لمجرد نسخ المحتوى إلى خادم جديد، كما أن نسخ ملفات شهادات Let’s Encrypt القديمة وحده لا يضمن استمرار التجديد الآلي بصورة سليمة. يحتاج خادم DigitalOcean إلى إعداد Nginx أو Apache بالـvirtual hosts أو server blocks الصحيحة، وربط أسماء النطاقات بالمواقع المقابلة، والتأكد من أن المنافذ المطلوبة متاحة عبر جدار الحماية. ويمكن في بعض سيناريوهات الترحيل نقل إعدادات Certbot ذات الصلة، إلا أن إصدار شهادة جديدة على البيئة الجديدة غالبًا ما يوفر نقطة بداية أوضح متى كانت آلية التحقق من ملكية النطاق قابلة للتنفيذ، مع ضرورة مراعاة أن بعض طرق التحقق تعتمد على وصول Let’s Encrypt إلى النطاق أو على التحكم في سجلات DNS.

ترتبط لحظة إصدار الشهادة بطريقة التحقق المستخدمة. فإذا كان التحقق يعتمد على HTTP-01، يجب أن يصل طلب التحقق إلى الخادم الذي يحتوي على ملف challenge الصحيح، وهو أمر يستدعي الانتباه أثناء الفترة التي لا تزال فيها سجلات DNS تشير إلى Hetzner. أما DNS-01 فيعتمد على إنشاء سجل DNS مخصص ويمكن أن يكون مناسبًا للبيئات التي تتطلب فصل إصدار الشهادة عن توجيه حركة HTTP، فضلًا عن استخدامه مع الشهادات ذات أسماء النطاقات البديلة المناسبة. وبعد نجاح الإصدار ينبغي فحص سلسلة الشهادة واسم النطاق وتاريخ الصلاحية، والتأكد من وجود مهمة التجديد الآلي ومن قدرة Certbot على إعادة تحميل خادم الويب عند الحاجة. وتساعد معرفة أنواع شهادات SSL على التحقق من أن الشهادة المختارة تغطي أسماء النطاقات المطلوبة في البيئة الجديدة.

لا تكتمل عملية نقل سيرفر بمجرد ظهور الصفحة الرئيسية عبر HTTPS، لأن الخادم قد يشغّل خدمات أخرى تعتمد عليها المواقع بصورة غير ظاهرة للمستخدم. يشمل التحقق النهائي تشغيل Nginx أو Apache وPHP-FPM ومحرك قاعدة البيانات والمهام المجدولة وعمليات cron وخدمات التخزين المؤقت وأي workers أو queues أو خدمات تطبيق مخصصة، إلى جانب مراجعة السجلات واستهلاك الموارد واختبار إعادة تشغيل السيرفر للتأكد من أن الخدمات الضرورية تبدأ تلقائيًا. وبعد تحويل DNS تُراقب الطلبات على Hetzner وDigitalOcean خلال فترة الانتشار؛ فإذا انخفضت الحركة على الخادم القديم واستقرت التطبيقات وقواعد البيانات وHTTPS على الخادم الجديد دون أخطاء، يصبح إيقاف بيئة Hetzner خطوة لاحقة يمكن تنفيذها بعد الاحتفاظ بنسخة احتياطية مناسبة وفترة تحقق كافية.

تحويل الزيارات إلى DigitalOcean وتقليل توقف السيرفر

بعد اكتمال نقل الملفات وقواعد البيانات وإعداد بيئة التشغيل على الخادم الجديد، تصبح مرحلة تحويل الزيارات من Hetzner إلى DigitalOcean أكثر حساسية من عملية النسخ نفسها؛ فالبيانات قد تكون موجودة بالكامل على الوجهة الجديدة، لكن نقل سيرفر فعليًا لا يكتمل ما دام المستخدمون يصلون إلى عنوان IP القديم. ويزداد التعقيد عندما تكون المواقع ديناميكية وتستقبل تسجيلات دخول أو طلبات شراء أو تعليقات أو ملفات مرفوعة باستمرار، لأن استمرار الكتابة على الخادم القديم بعد آخر مزامنة قد يؤدي إلى وجود نسختين مختلفتين من البيانات. لذلك تعتمد جودة الانتقال على تقليص الفاصل الزمني بين المزامنة النهائية وتحويل حركة المرور، مع إبقاء خادم Hetzner متاحًا خلال فترة الانتقال بدل إيقافه بمجرد اكتمال النسخ الأولي.

تتحقق أقل فترة توقف عندما يكون خادم DigitalOcean جاهزًا لاستقبال الطلبات قبل تحويل أي زائر إليه. ويشمل ذلك توافق إصدارات PHP أو Node.js أو Python وغيرها من بيئات التشغيل، وتشغيل Nginx أو Apache والخدمات الخلفية المطلوبة، واستعادة قواعد البيانات، وضبط الصلاحيات والجدار الناري وشهادات TLS والمهام المجدولة ومتغيرات البيئة. وفي المواقع التي تتغير ملفاتها باستمرار يمكن تنفيذ مزامنة أولية كبيرة مبكرًا، ثم مزامنة لاحقة للفروقات فقط باستخدام أدوات مثل rsync، بينما تحتاج قواعد البيانات النشطة إلى آلية تضمن اتساق البيانات عند اللحظة الأخيرة من نقل سيرفر. أما مجرد نسخ قاعدة بيانات قديمة وترك الموقع يستقبل عمليات كتابة على Hetzner لساعات بعدها، فيخلق احتمال فقدان التغييرات التي حدثت خلال تلك المدة عند بدء استقبال الزيارات على الخادم الجديد.

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

اختبار المواقع والخدمات على عنوان IP الجديد قبل تغيير DNS

وجود الملفات وقاعدة البيانات على الخادم الجديد لا يكفي لإثبات أن الموقع سيعمل بعد تحويل النطاق إليه. فالاختبار المسبق ينبغي أن يجعل الطلب يصل إلى عنوان IP الخاص بـ DigitalOcean مع الاحتفاظ باسم النطاق الحقيقي داخل طلب HTTP، لأن كثيرًا من خوادم الويب والتطبيقات تختار الموقع أو Virtual Host اعتمادًا على اسم المضيف وليس عنوان IP وحده. ويمكن تحقيق ذلك محليًا بربط النطاق بعنوان IP الجديد في ملف hosts على جهاز الاختبار، أو باستخدام أدوات تسمح بتحديد عملية حل الاسم مؤقتًا. بهذه الطريقة يظهر الموقع كما لو أن DNS قد تغير بالفعل، بينما تظل الزيارات العامة متجهة إلى Hetzner، وهو ما يوفر فرصة لاكتشاف المشكلات قبل أن تؤثر في المستخدمين.

ينبغي أن يغطي الفحص أكثر من الصفحة الرئيسية؛ فنجاح استجابة HTTP لا يثبت سلامة التطبيق بأكمله. تحتاج المواقع الديناميكية إلى التحقق من الاتصال بقاعدة البيانات، وتسجيل الدخول والجلسات، والرفع والتحميل، والصفحات التي تعتمد على إعادة الكتابة، والواجهات البرمجية، والطلبات الخلفية، والمهام التي تنفذها خدمات مستقلة. كما تكشف سجلات Nginx أو Apache وسجلات التطبيق وsystemd عن أخطاء قد لا تظهر بوضوح في المتصفح، مثل مسار ملف غير صحيح أو خدمة لم تبدأ بعد إعادة التشغيل أو اختلاف في مالك الملفات وصلاحياتها. ويشمل نقل سيرفر كذلك مراجعة الاتصالات الصادرة التي قد تكون مقيدة بعنوان IP القديم، مثل قواعد السماح في خدمات خارجية أو قواعد بيانات بعيدة أو بوابات تعتمد على قائمة عناوين موثوقة.

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

تحديث سجلات DNS وتنفيذ Zero Downtime Migration قدر الإمكان

تمثل سجلات DNS نقطة التحويل الفعلية في نقل سيرفر، وخصوصًا سجل A الذي يربط اسم المضيف بعنوان IPv4 وسجل AAAA عند استخدام IPv6. وقبل موعد الانتقال بفترة مناسبة يمكن خفض قيمة TTL للسجلات التي ستتغير، لأن TTL يحدد المدة التي تستطيع خلالها محللات DNS الاحتفاظ بالبيانات المخزنة مؤقتًا قبل طلب تحديثها. ولا يؤدي خفض القيمة قبل ثوانٍ من الترحيل إلى التخلص فورًا من النسخ القديمة الموجودة بالفعل في ذاكرة التخزين المؤقت؛ لذلك تكون فائدته أكبر عندما يتم قبل عملية التحويل بمدة تسمح بانتهاء قيمة TTL السابقة. وعند إدارة النطاق عبر DigitalOcean ينبغي إنشاء السجلات اللازمة قبل تفويض النطاق إلى خوادم الأسماء التابعة لها إذا كان النطاق مستخدمًا بالفعل، حتى لا تنشأ فجوة في عملية الحل. وتساعد مراجعة إعدادات DNS في الاستضافة على التأكد من توجيه السجلات المطلوبة إلى الوجهة الجديدة بصورة صحيحة.

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

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

مراقبة السيرفر بعد الترحيل وحل مشاكل الملفات وقواعد البيانات والخدمات

تبدأ مرحلة تحقق جديدة بعد انتقال غالبية الزيارات إلى DigitalOcean، لأن بعض الأعطال لا تظهر في الاختبارات المحدودة السابقة للتحويل. مراقبة السيرفر عبر Netdata واستهلاك CPU والذاكرة ومساحة القرص وعمليات الإدخال والإخراج وحركة الشبكة تكشف ما إذا كان حجم الخادم الجديد مناسبًا للحمل الحقيقي، بينما تساعد سجلات النظام وخادم الويب والتطبيق في اكتشاف أخطاء HTTP 5xx أو العمليات التي تنهار وتُعاد تلقائيًا أو الاتصالات البطيئة بقاعدة البيانات. كما ينبغي مقارنة حركة المرور على عنواني IP القديم والجديد؛ فانخفاض الطلبات على Hetzner تدريجيًا يوفر مؤشرًا عمليًا على انتقال العملاء، في حين أن استمرار عدد ملحوظ منها قد يشير إلى سجلات DNS أخرى لم تُحدّث أو إلى خدمات تستخدم IP القديم مباشرة.

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

أما الخدمات المحيطة بالتطبيق فقد تسبب أعطالًا متأخرة يصعب ربطها بالترحيل مباشرة، مثل cron jobs وsystemd timers والـworkers ومعالجات queues وخوادم البريد والتخزين المؤقت وRedis وخدمات النسخ الاحتياطي والمراقبة. وقد يعمل الموقع في المتصفح بصورة طبيعية بينما تتوقف الرسائل أو المهام المجدولة أو معالجة الطوابير بسبب خدمة لم تُفعّل على الخادم الجديد، كما قد تظهر أخطاء في طبقة خادم الويب مثل 502 Bad Gateway إذا تعطلت خدمة خلفية أو تغير مسار الاتصال إليها. لذلك يبقى خادم Hetzner دون حذف خلال فترة تحقق معقولة، مع تجنب استمرار تنفيذ المهام نفسها على الخادمين إذا كان ذلك سيؤدي إلى عمليات مكررة. وعندما تستقر الخدمات والبيانات والزيارات على DigitalOcean، وتتوقف الطلبات المهمة عن الوصول إلى العنوان القديم، يصبح إنهاء الخادم السابق خطوة أخيرة مدروسة في نقل سيرفر، ويفضل أن تسبقها نسخة احتياطية نهائية قابلة للاسترجاع إذا ظهرت لاحقًا حاجة إلى ملف أو إعداد لم يُنقل كما كان متوقعًا.

ما أفضل وقت لتنفيذ نقل السيرفر إلى DigitalOcean؟

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

كم يجب الاحتفاظ بسيرفر Hetzner بعد اكتمال النقل؟

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

كيف يمكن التأكد من عدم نسيان ملفات أو خدمات أثناء الترحيل؟

يساعد إعداد قائمة جرد قبل النقل على مقارنة مكونات الخادمين بعد انتهاء الترحيل. ويمكن أن تشمل المواقع وقواعد البيانات والمستخدمين وCron Jobs وsystemd timers وDocker Volumes والشهادات ومفاتيح SSH والخدمات الخلفية والنسخ الاحتياطية. وبعد تشغيل DigitalOcean تتم مطابقة هذه القائمة مع البيئة الجديدة واختبار كل عنصر بصورة مستقلة، بدل الاعتماد فقط على نجاح تحميل صفحات الموقع، لأن بعض الخدمات غير المرئية قد لا يظهر تعطلها إلا بعد مرور وقت.

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

منهجية الفحص والتقييم

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