كيفية ترحيل VPS إلى مضيف جديد دون توقف

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

ما الذي يعنيه "دون توقف" فعليًا

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

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

خذ الجرد قبل أن تأخذ النسخة

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

دوّنه في ملف تحتفظ به في نظام التحكم بالإصدارات، لا في سجل تمرير الطرفية (scrollback). ستقرؤه ثلاث مرات أثناء التبديل، مرة منها في لحظة لن يكون تفكيرك فيها صافيًا.

اختر الوجهة بناءً على ما لا يمكنك تغييره لاحقًا

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

• الموقع الجغرافي، لأن زمن الاستجابة إلى مستخدميك والقانون المعمول به كلاهما يتحدد به. يسرد /locations المناطق وخصائص زمن الرحلة (round-trip) لكل منها؛ اختر منطقة تفشل بشكل مستقل عمّا تغادره.
• الموقف القانوني، إن كان سبب الانتقال أن مزوّدك الحالي يُحيل الشكاوى أسرع مما يُحيل حزم البيانات (packets). يوضّح /offshore-hosting ما الذي تتحكم فيه الولاية القضائية فعليًا وما لا تتحكم فيه.
• هوية الفوترة، لأن أي مضيف يطلب مستندات قبل قبول الدفع يملك بحكم البنية ملفًا عنك. يصف /no-kyc-vps و/pay-with البديل — رصيد مشحون بعملات رقمية، دون بطاقة، ودون اسم مرتبط بالجهاز.
• هامش النمو (headroom)، لأن الترحيل مرتين نتيجة لا يخطط لها أحد. يسرد /vps الفئات، ويضم /guides طريقة تحديد الحجم إن لم يُقَس الجهاز الحالي فعليًا من قبل.
• IPv6 وعنوان IPv4 نظيف، إذ قد يصل عنوان مُعاد استخدامه حاملًا سمعة شخص آخر — تحقّق منه قبل أن يتحوّل إلى مشكلة بريد.

اخفض TTL الخاص بـDNS أولًا، قبل أيام

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

1. 1

   اقرأ قيمة TTL الحالية

   يعرض الأمر dig +noall +answer yourdomain.com الوقت المتبقي للتخزين المؤقت؛ واستعلام خادم الأسماء الموثوق (authoritative nameserver) مباشرة عبر dig @ns1.example.net yourdomain.com يعرض القيمة المضبوطة. دوّنها — فهي التي تحدد طول فترة انتظارك.

2. 2

   اخفضها إلى 300 ثانية

   اخفض TTL على كل سجل سيتغيّر: A، وAAAA، وأي MX أو CNAME يشير إلى المضيف. خمس دقائق مدة قصيرة بما يكفي لجعل التبديل مريحًا، وطويلة بما يكفي كي لا تُرهق خوادم الأسماء الخاصة بك.

3. 3

   انتظر انتهاء TTL القديم، ثم انتظر مجددًا

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

ابنِ الخادم الجديد، ولا تستنسخ القديم

الغريزة الأولى هي أخذ صورة (image) للقرص الحالي واستعادتها في مكان آخر. وهذه خطوة خاطئة، للسبب نفسه الذي تكون فيه خاطئة عند الاستعادة: فالاستنساخ على مستوى الكتل (block-level) يُعيد إنتاج انحراف الإعدادات (config drift) بأمانة، والحزم اليتيمة، والخدمة نصف المُهيَّأة التي تخلّى عنها أحدهم، وأي وسيلة بقاء (persistence) تركها مقتحِم سابق. كما يُقيّدك بإصدار التوزيعة القديم.

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

• جهّز الخادم وحدّثه وحصّنه قبل أن يلمسه أي شيء آخر: SSH بالمفاتيح فقط، وجدار ناري بسياسة رفض افتراضية، وتحديثات أمنية تلقائية دون تدخل يدوي. يضم /guides النسخة المُفصَّلة من تلك القائمة، التي تستغرق ساعة.
• ثبّت الإصدارات الرئيسية نفسها لبيئة التشغيل (runtime) وقاعدة البيانات كما في بيئة الإنتاج. الترحيل وقت سيئ لترقية PostgreSQL من 14 إلى 17 في الوقت نفسه — أجرِ تغييرًا واحدًا في كل مرة حتى يكون لأي فشل تفسير واحد فقط.
• أعِد إنشاء المستخدمين والمجموعات بالمعرّفات الرقمية نفسها قبل نسخ الملفات، أو أصلح الملكية يدويًا بعد ذلك. النقل باستخدام --numeric-ids يُبقي الأرقام سليمة؛ وربطها بالأسماء الصحيحة مجددًا مهمتك أنت.
• أضِف العنوان الجديد إلى كل قائمة سماح (allowlist) تذكر العنوان القديم حاليًا — واجهات API لدى الشركاء، وجدران الحماية لقواعد البيانات المُدارة، وبوابات الدفع، وأداة المراقبة الخاصة بك — بينما لا يزال العنوانان صالحَين معًا.

انسخ الملفات على مرحلتين

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

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

• استخدم rsync -aAXH --numeric-ids --info=progress2 عبر SSH: -a للسمات المعتادة، و-A لقوائم ACL، و-X للسمات الموسّعة (extended attributes)، و-H للروابط الصلبة (hard links)، وهي مهمة إن كان أي شيء على الجهاز يُزيل التكرار.
• استبعِد ما لا ينبغي أن يُنقل: /proc، و/sys، و/dev، و/run، والمجلدات المؤقتة، وذاكرة الحزم المؤقتة والسجلات التي لا تحتاجها. فنسخ واجهات النواة يُهدر الوقت في أفضل الأحوال، ويُعلِّق عملية النقل في أسوأها.
• أضِف --delete في المرحلة الثانية فقط. في الأولى لا ضرر منها؛ وفي الثانية تُزيل الملفات التي حُذفت من المصدر منذ ذلك الحين، وهذا بالضبط هو الانحراف الذي تحاول إزالته.
• انسخ إعدادات النظام بانتقائية لا بالجملة. أنت تريد مضيفات (vhosts) خادم الويب، ووحدات الخدمة (service units)، وإعدادات تطبيقك — لا جدول نظام الملفات الخاص بالجهاز القديم، ولا إعدادات الشبكة، ولا معرّف الجهاز (machine ID).
• ولِّد مفتاح SSH مؤقتًا خاصًا بعملية النقل، وفعِّله على الوجهة، واحذفه عند انتهاء الترحيل. مفتاح ترحيل يبقى لعامين هو بيانات اعتماد لا يتذكر أحد أنه أصدرها.

بين المرحلتين، تحقّق بدلًا من أن تفترض. تشغيل المرحلة الثانية بخيار --dry-run يطبع بالضبط ما كان سيتغيّر: قائمة من بضع مئات من الملفات الحديثة أمر سليم، أما قائمة من أربعين ألف ملف فتعني أن استثناءً ما خاطئ أو أن شيئًا يعيد كتابة الطوابع الزمنية (timestamps) دون سبب.

انقل قاعدة البيانات دون فقدان أي كتابة

هنا يُنفَق رصيد التجميد، والتقنية الصحيحة يحددها بالكامل الرقم الذي دوّنته في البداية. الخيارات الثلاثة أدناه جميعها صحيحة — لأرقام مختلفة.

فرِّغ المخطط (schema) والبيانات كلًا على حدة حين تكون مجموعة البيانات كبيرة. استعادة المخطط أولًا تتيح لك التحقق مبكرًا من البنية والفهارس والصلاحيات على المضيف الجديد، مما يحوّل تحميل البيانات إلى عملية طويلة واحدة يمكنك بدؤها أثناء التجميد وأنت واثق بالفعل أنها ستنجح.

أصدِر شهادة TLS قبل التبديل، لا بعده

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

• انسخ الشهادة الحالية. إما دليل حالة ACME بأكمله، أو الشهادة والمفتاح فقط من حيث يحتفظ بهما عميلك (client). تكون صالحة فورًا، لأن الصلاحية لا علاقة لها بأي خادم يحمل الملف، ويستأنف التجديد عمله بشكل طبيعي بمجرد انتقال DNS.
• أصدِر شهادة جديدة عبر تحدي DNS-01، الذي يُثبت التحكم بالنطاق من خلال سجل TXT بدلًا من طلب HTTP إلى العنوان الحالي. يعمل هذا قبل الترحيل، وقبل التبديل، ومع الشهادات الشاملة (wildcard)، وهو ما لا يستطيع HTTP-01 فعله على الإطلاق.
• لا تحاول التحقق عبر HTTP-01 على الخادم الجديد قبل التبديل. يُجلب التحدي عبر المنفذ 80 على اسم النطاق، والنطاق لا يزال يُحلَّل إلى الجهاز القديم، فيفشل التحقق في كل مرة.

تحقّق منها دون لمس DNS، عبر تحليل اسم المضيف إلى العنوان الجديد لأمر واحد فقط: curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ — مع استبدال العنوان الحقيقي. هذا السطر الواحد هو أعلى فحص قيمةً في الترحيل بأكمله. فهو يُشغِّل المضيف الافتراضي (vhost) الحقيقي، والشهادة الحقيقية، ومكدّس التطبيق (stack) الحقيقي على الجهاز الجديد، وهو كيف تجد الخطأ في الإعداد بينما لا يزال اكتشافه دون أي تكلفة.

إن كان الخادم يرسل بريدًا، ابدأ مبكرًا

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

• تحقّق من العنوان الجديد مقابل القوائم السوداء (blocklists) الكبرى قبل أن تلتزم به. عنوان IP مُعاد استخدامه وله سجل سابق يستحق استبداله ما دام الاستبدال لا يزال مجانيًا.
• اضبط سجل DNS العكسي على العنوان الجديد ليشير إلى اسم مضيف بريدك. تتحقق الخوادم المستقبِلة من تطابق التحليل الأمامي والعكسي، وغياب سجل PTR وحده كافٍ لتصنيف الرسالة كبريد مزعج.
• أضِف العنوان الجديد إلى SPF قبل التبديل، واحذف القديم بعده — يكون كلاهما مدرَجًا أثناء التداخل، بحيث يُصادَق على البريد أيًا كان الخادم الذي أرسله فعليًا.
• انسخ مفاتيح DKIM الخاصة بدلًا من توليد مفاتيح جديدة، حتى يستمر المُحدِّد (selector) المنشور بالفعل في DNS في التحقق بنجاح. فإعادة التوليد تعني إعادة النشر، وإعادة النشر لها تأخير انتشار خاص بها.
• سخِّن العنوان الجديد تدريجيًا إن كنت ترسل بأي حجم يُذكر. فخادم لم يرسل شيئًا طوال عمره ثم يُصدر عشرة آلاف رسالة دفعة واحدة لا يمكن تمييزه، من وجهة نظر المستقبِل، عن مضيف مخترَق.

التبديل

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

1. 1

   جمِّد الكتابة على الخادم القديم

   وضع الصيانة، أو مستخدم قاعدة بيانات للقراءة فقط، أو خطأ على مسارات الكتابة عند الوكيل العكسي (reverse proxy). تستمر القراءة في الخدمة من الجهاز القديم طوال الوقت — وهذا ما يُبقي الموقع يعمل بينما تنتقل البيانات.

2. 2

   عطِّل كل مؤقّت على الخادم القديم

   علِّق سطور crontab، وأوقِف المؤقّتات، وأوقِف عمّال قائمة الانتظار (queue workers). من هذه اللحظة يجب ألا يُعالج الجهاز القديم أي شيء، وإلا فستعمل المهام مرتين: فاتورتان، ورسالتا بريد، وعمليتا تسليم ويب هوك (webhook).

3. 3

   نفّذ الفرق (delta) النهائي

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

4. 4

   تحقّق من الخادم الجديد عبر اسم مضيفه الحقيقي

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

5. 5

   بدِّل DNS وشغِّل الخدمات

   حدِّث سجلي A وAAAA إلى العنوان الجديد، ثم فعِّل وشغِّل التطبيق ومؤقّتاته على الخادم الجديد. تبدأ الزيارات بالوصول خلال مدة TTL واحدة وتستمر في التحوّل على مدار الساعة التالية.

6. 6

   أبقِ الخادم القديم يخدم القراءة

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

أول 48 ساعة

الترحيل لا ينتهي حين يُحمَّل الموقع. بل ينتهي حين لا يعتمد أي شيء على الجهاز القديم بعد الآن، والعثور على تلك التبعيات تمرين فعّال لا لعبة انتظار.

• راقِب سجل الوصول (access log) الخاص بالخادم القديم. كل طلب لا يزال يصل إليه تبعية لم تُرحَّل بعد — عنوان مُضمَّن في الكود لدى تكامل شريك، أو عميل جوال لديه ذاكرة تخزين مؤقت قديمة، أو مسبار مراقبة لا يملكه أحد. السجل هو قائمة المهام المتبقية.
• تأكّد من أن المؤقّتات عملت فعليًا على المضيف الجديد. لا أنها مُفعَّلة فقط — بل أنها عملت، في الوقت المتوقع، وبالمخرجات المتوقعة. فمهمة cron لا تفعل شيئًا بصمت تبدو تمامًا مثل مهمة cron تعمل بنجاح.
• اختبر تجديد الشهادة فعليًا بتشغيل تجريبي (dry run)، بدلًا من أن تكتشف بعد ستين يومًا أن عميل ACME الخاص بك كان يحاول التجديد مقابل خادم لم يعد يستقبل التحدي.
• تحقّق من تدفق البريد من طرف إلى طرف وفي الاتجاهين، بما في ذلك كل ما يرسله التطبيق تلقائيًا. إعادة تعيين كلمة المرور هي الضحية الكلاسيكية، لأن لا أحد يختبرها إلى أن يحتاج إليها مستخدم.
• خذ نسخة احتياطية من الخادم الجديد واستعِدها في مكان ما. جهاز جديد دون نسخة احتياطية مُتحقَّق منها وضع أسوأ من الذي غادرته؛ ويضم /guides النسخة الكاملة من هذه الحجة.
• أعِد قيمة TTL الخاصة بـDNS إلى وضعها الطبيعي بمجرد أن تطمئن. فإبقاؤها عند 300 ثانية إلى الأبد تكلفة دائمة صغيرة في الاستعلامات وزمن الاستجابة دون أي فائدة متبقية.

إخراج الخادم القديم من الخدمة

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

• انتظر حتى يصمت سجل الوصول القديم قبل أن تلمس أي شيء. فإلغاء الخدمة بينما لا يزال مزوّد دفع يرسل ويب هوك (webhooks) إلى العنوان القديم هو بالضبط كيف يتحوّل ترحيل إلى حادثة بعد أسبوع.
• دوِّر (rotate) بدلًا من مجرد الحذف: كل بيانات اعتماد كان يحملها الخادم القديم — مفاتيح API، وكلمات مرور قاعدة البيانات، ومفاتيح النشر (deploy keys)، ومفتاح الترحيل المؤقت. افترض أن أي شيء عاش على جهاز لم تعد تتحكم فيه مخترَق، لأنه سيصبح كذلك عاجلًا أم آجلًا.
• اكتب فوق البيانات قبل إعادة الحجم إلى المجمّع. مزّق (shred) المجلدات الحساسة، أو املأ المساحة الفارغة بملف عشوائي كبير واحد ثم احذفه. أسلوب غير مثالي على قرص مُفترَض (virtualised)، لكنه أفضل بكثير من لا شيء.
• خذ أرشيفًا أخيرًا لأي شيء قد تحتاجه للرجوع إليه — السجلات، والإعدادات، وسجل أوامر الشل (shell history) الذي يوثّق ما نُفِّذ فعليًا — واحفظه مشفَّرًا في مكان ليس أيًا من الخادمين.
• ألغِ الخدمة فقط بعد أن ينجو الخادم الجديد من دورة فوترة كاملة، ومن اختبار نسخ احتياطي واستعادة كامل. شهر التداخل ذاك هو أرخص تأمين في العملية بأكملها.

جدول زمني يمكنك نسخه

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

كيف تفشل عمليات الترحيل فعليًا

ليس عبر النسخ. بل عبر الأشياء التي لم تكن يومًا على القرص، والأشياء التي عملت مرتين.

• كلا الخادمين يكتبان في الوقت نفسه — نافذة "انقسام الدماغين" (split-brain)، والفشل الوحيد هنا الذي لا حل نظيف له. يُمنع هذا بالترتيب لا بالأدوات: أوقِف القديم، ثم شغِّل الجديد.
• مؤقّتات تعمل على الجهازين معًا، وهذا بالضبط كيف يستلم العملاء نسختين من كل شيء. عطِّل القديمة قبل المزامنة النهائية، لا بعدها.
• قيمة TTL لم تُخفَّض أبدًا، فتحوّل تبديل مدته خمس دقائق إلى ذيل يستمر يومًا كاملًا لم يخطط أحد لتغطيته.
• ملكية ملفات تصل خاطئة لأن المعرّفات الرقمية تختلف بين الجهازين، فيبدأ التطبيق ثم يعجز عن الكتابة في مجلد الرفع الخاص به.
• شهادة كان من المفترض ترتيبها بعد التبديل، تصطدم بترويسة HSTS تترك الزوار دون أي طريقة للمتابعة.
• عنوان مُضمَّن في الكود (hard-coded) في مكان لا تتحكم فيه — تكامل لدى شريك، أو قاعدة جدار ناري، أو سجل DNS لنطاق فرعي نسيت أنه موجود أصلًا.
• إلغاء الخادم القديم في يوم الانتقال نفسه، مما يُزيل مسار التراجع في اللحظة عينها التي تقول فيها الإحصاءات إنك على الأرجح ستحتاج إليه.