انقل موقعك إلى استضافة جديدة دون أي توقّف
عمليات النقل تفشل في المواضع الأربعة نفسها دائمًا. إليك ترتيب الخطوات الذي يُبقي موقعك وبريدك وشهادتك تعمل خلال التحويل.
معظم عمليات نقل الاستضافة تُروى بعدها بالطريقة نفسها: «الموقع كان بخير، لكن البريد تعطّل يومين». هذا ليس سوء حظ، بل ما يحدث حين يُعامَل النقل كمفتاحٍ واحد بدل أن يُعامَل كأربعة أنظمة مستقلة تتشارك اسم نطاقٍ واحد.
النقل المنفَّذ بالترتيب الصحيح لا ينتج عنه توقّف إطلاقًا — ليس «بضع دقائق»، بل صفر. يظل الزوّار يفتحون الخادم القديم حتى اللحظة التي يبدؤون فيها بفتح الجديد، ولا يُطفأ أيٌّ من الخادمين لحظة واحدة. وهذا هو الترتيب الذي يحقّق ذلك.
أولًا: ما الذي تنقله فعلًا؟
النطاق لافتةٌ لا مكان. خلفه أربعة أشياء مستقلة على الأقل، ولكلٍّ منها نقلٌ مقصود:
- الموقع — ملفات، وغالبًا قاعدة بيانات.
- البريد — الصناديق وسنوات الرسائل داخلها. هذا هو الجزء المؤلم.
- سجلات DNS — التي تخبر العالم أين يقيم الموقع وأين يقيم البريد.
- تسجيل النطاق نفسه — وقد يكون لدى شركة مختلفة تمامًا عن مستضيفك.
لست مضطرًّا لنقل الأربعة دفعةً واحدة، وغالبًا لا ينبغي. نقل الموقع مهمّة صغيرة، أمّا نقل صناديق البريد فهو ما يحتاج خطةً وعطلة نهاية أسبوع.
اخفض مدة التخزين (TTL) قبل يوم
كل سجلّ DNS يحمل قيمة TTL: كم يُسمح لمخدّمات العالم بالاحتفاظ بالإجابة في ذاكرتها. فإذا كان سجلّ A لديك بقيمة 14400، سيظل بعض الزوّار يصلون إلى الخادم القديم أربع ساعات بعد التغيير، ولا حيلة لك في ذلك حينها.
لذلك افعلها مسبقًا. قبل يوم من النقل، اخفض TTL على السجلات التي تنوي تغييرها إلى 300 ثانية. عندها ينسى العالم الإجابة القديمة خلال خمس دقائق بدل أربع ساعات، وتنكمش نافذة التحويل من «معظم يوم» إلى «مدّة فنجان قهوة». وأعد رفع القيمة بعد أن تستقرّ الأمور.
هذه الخطوة وحدها هي الفارق بين تحويلٍ نظيف ويومٍ كامل من «عندي يشتغل، وعندها لا».
ابنِ الموقع الجديد واختبره قبل تغيير أي سجل
انسخ الملفات وقاعدة البيانات إلى الخادم الجديد، ثم تحقّق منه هناك — قبل أن يشير النطاق إليه. وأمامك طريقان:
- اسم مضيف مؤقّت لدى المستضيف الجديد: مناسب لموقع ثابت، لكنه يفسد أي شيء تُخزَّن روابطه المطلقة داخل قاعدة البيانات.
- سطر في ملف hosts على جهازك أنت، يوجّه حاسوبك وحده إلى الخادم الجديد بينما يرى بقية العالم القديم. وهذا هو الاختبار الصادق: النطاق نفسه، والروابط نفسها، وظروف حقيقية.
وتجوّل في الموقع كما ينبغي في هذه المرحلة: النماذج تُرسَل فعلًا، وتسجيل الدخول يعمل، والصور تظهر، وعملية الشراء تكتمل. النقل ليس «ظهرت الصفحة الرئيسية»، بل كل مسارٍ يسلكه عميل.
البريد هو ما يعضّ
المواقع بلا حالة بما يكفي لنسخها مرتين، أمّا صناديق البريد فلا: أثناء النسخ تستمر رسائل جديدة في الوصول، والرسالة التي تصل إلى الخادم القديم بعد التحويل لا تنتقل تلقائيًا إلى الجديد.
التسلسل الذي ينجح:
- أنشئ كل صندوق على الخادم الجديد أولًا، بالعناوين نفسها — بما فيها العناوين البديلة وإعادات التوجيه التي نسي الجميع ذكرها.
- زامِن الرسائل الموجودة عبر نقل IMAP بينما الخادم القديم ما زال حيًّا ويستقبل. لا شيء يضيع، لأن شيئًا لم يُحوَّل بعد.
- غيّر سجلات MX.
- شغّل المزامنة مرة ثانية بعد التحويل، لالتقاط ما وصل إلى الخادم القديم أثناء الانتقال.
- اترك الصناديق القديمة قائمة أسبوعين. لا تكلّف شيئًا، وهي شبكة الأمان.
واختبر الإرسال لا الاستقبال فقط. خادمٌ يستقبل بامتياز لكن رسائله تسقط في «غير المرغوب» لم يُكمل نقله بعد — وهنا تأتي السجلات التي لا يتذكّرها أحد.
السجلات التي يُنساها الجميع
كل الناس ينقلون سجل A وسجلات MX. أمّا التي تسبّب المتاعب بهدوء بعد أسبوع فهي:
- SPF — إن ظلّ يخوّل مزوّدك القديم وحده، بدأ بريدك من الجديد يفشل في التحقق.
- DKIM — خادم جديد يعني مفتاحًا جديدًا وسجلًّا جديدًا؛ ونسخ القديم لا يحقّق شيئًا.
- DMARC — إن نشرت سياسة صارمة ونسيت الاثنين أعلاه، فسترفض بريدك بنفسك رفضًا مقنعًا.
- النطاقات الفرعية — نظام إدارة العملاء، وموقع التجربة، وأداة التتبّع، وذلك الشيء الذي أعدّه قسم التسويق سنة 2023.
- سجلات التحقق TXT — لأدوات البحث وأدوات الأعمال، وتفقد توثيقها بصمت إن أُسقطت.
صدّر المنطقة (Zone) كاملة من المزوّد القديم قبل أن تلمس شيئًا، وعامِلها كقائمة تحقّق. وإن لم تكن متأكدًا من الذي يجيب باسم نطاقك اليوم، فحسم هذا السؤال أولًا يستحق العناء — وقد كتبنا عن لماذا نجيب عن نطاقاتنا بأنفسنا بدل ترك الأمر لإعداد المسجِّل الافتراضي.
حوِّل، ثم راقب
مع TTL بقيمة 300 ثانية، يصبح التغيير نفسه بلا إثارة. غيّر السجلات، ثم اقضِ الساعة التالية في المراقبة لا الاحتفال: سجلّات الخادمين، وطلب تجريبي، ورسالة تجريبية داخلة وخارجة، وشهادة SSL على المستضيف الجديد — التي يجب أن تكون صادرة ومثبَّتة قبل التحويل لا بعده، وإلا استقبل أوائل زوّار العهد الجديد تحذيرًا من المتصفح.
ولا تلغِ الاستضافة القديمة في اليوم نفسه. أبقِها من أسبوعين إلى أربعة. تكلفتها شهر إضافي، وهي أرخص تأمين في هذه العملية كلها، وتتيح لك المقارنة إن بدا شيء مختلفًا.
قائمة تحقّق النقل
- نسخة احتياطية كاملة للملفات وقاعدة البيانات والبريد، محفوظة في مكانٍ لا يملكه أيٌّ من المستضيفين
- تصدير المنطقة من مزوّد DNS الحالي
- خفض قيم TTL إلى 300 قبل يوم على الأقل
- نسخ الموقع والتحقق منه على الخادم الجديد عبر ملف hosts
- إصدار شهادة SSL على المستضيف الجديد قبل التحويل
- إنشاء الصناديق مع العناوين البديلة، وإتمام أول مزامنة IMAP
- تغيير السجلات: A وMX وSPF وDKIM وDMARC والنطاقات الفرعية وسجلات التحقق
- مزامنة بريدية ثانية بعد التحويل
- اختبار الإرسال والاستقبال من خارج شبكتك
- إبقاء المستضيف القديم حيًّا من أسبوعين إلى أربعة
- إعادة رفع قيم TTL بعد الاستقرار
أو سلّمها لمن يقوم بها
هذا إجراء معروف، لكنه إجراء — وتعلّمه لأول مرة على عملك الحيّ مكانٌ مكلف للتعلّم. نقل موقعك إلى استضافة PearlFibers يشمل عملية النقل: نأخذ النسخة، ونجهّز الموقع، ونتولّى صناديق البريد، ونعدّ السجلات، ونحوّل في ساعة هادئة، مع إبقاء المستضيف القديم يعمل خلفنا.
وإن كنت ما زلت تقرّر إلى ماذا تنتقل، فالمقارنة الصادقة هنا: استضافة مشتركة أم خادم افتراضي. وإن كان سبب الانتقال أن لا أحد يستطيع إخبارك من يتحكّم بـ DNS اليوم، فابدأ بـإدارة DNS — فهي نقلة أصغر، وتجعل كل نقلةٍ لاحقة أسهل.