غيّر مزود الاستضافة: ننقل موقعك مجانًا

النقل وفق الترتيب الذي يتم به

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

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

1. قبل 7 أيام — جرد ما يعمل فعلا. المواقع ونطاقاتها، وإصدار PHP المستخدم، وقواعد البيانات ومحركاتها، وصناديق البريد الإلكتروني وحجمها، والمهام المجدولة، والشهادات وتواريخ انتهائها، والخدمات الخارجية التي تعرف عنوان IP الحالي (بوابة الدفع، مرحل SMTP، webhooks). هذه القائمة، وليس ذاكرتك، هي ما سيستخدم للتحقق النهائي.
2. قبل 7 أيام — تحديد حجم الاستضافة الجديدة وفق الاستخدام الفعلي، لا وفق العرض الذي تدفع ثمنه اليوم. سجّل مساحة القرص المستخدمة، وحجم قواعد البيانات، والذاكرة المستهلكة فعليًا. موقع يتسع في 6 Go لا يحتاج إلى عرض بسعة 200 Go لمجرد أن العرض القديم كان يعلن عنها.
3. قبل 5 أيام — فتح الاستضافة الجديدة وإنشاء النسخة. تُنقل الملفات وقواعد البيانات مرة أولى بالكامل، دون أي تغيير على الجانب العام. لا يلزم أن تكون هذه النسخة محدّثة لحظة بلحظة: فهي تُستخدم للتحقق من أن التطبيق يعمل.
4. قبل 3 أيام — تجميد التغييرات على الخادم القديم. لا نشر لمقالات، ولا تحديث لإضافات، ولا تعديل للقالب حتى التحويل. كل ما يُكتب بعد هذه النقطة سيتعيّن مزامنته يدويًا.
5. قبل يومين — خفض TTL للسجلات التي ستتغير إلى 300 ثانية. تتم هذه الخطوة قبل 48 ساعة على الأقل من التحويل، للسبب الموضح في قسم DNS أدناه. إنها الخطوة التي تنفذ متأخرة في أغلب الأحيان، والوحيدة التي لا يمكن تداركها.
6. قبل يوم — اختبار النسخة باسم النطاق الحقيقي، دون المساس بـ DNS العام: عدل ملف hosts في جهازك لتوجيه النطاق إلى عنوان IP الجديد. سترى حينها بالضبط ما سيراه زوارك، بما في ذلك الروابط المطلقة وعمليات إعادة التوجيه.
7. قبل يوم — تحضير منطقة DNS الجديدة دون نشرها. دوّن القيم الدقيقة لسجلات A وAAAA وMX وSPF وDKIM وDMARC وCAA التي ستضيفها. كتابتها مسبقًا تجنّبك ارتجالها يوم التحويل، حين يكون الموقع قد حُوّل جزئيًا.
8. يوم التحويل — مزامنة الفارق. تنقل جولة نسخ ثانية ما تغيّر فقط منذ اليوم الخامس قبل التحويل، ثم يحل تصدير جديد لقاعدة البيانات محل السابق. هذه الجولة الثانية القصيرة هي التي تحدد فترة عدم التوفر الفعلية.
9. يوم التحويل — نشر سجلات DNS الجديدة. مع قيمة TTL عند 300 ثانية مضبوطة قبل يومين، يصبح التحويل فعّالًا خلال دقائق لدى معظم الزوار، لا خلال أربع وعشرين ساعة.
10. يوم التحويل — إجراء التحققات وفق الترتيب الوارد أدناه. لا تؤشر على أي بند من الذاكرة: افتح القائمة واختبر فعليًا.
11. اليوم +1 — أعد رفع قيمة TTL إلى قيمتها المعتادة؛ 3 600 ثانية مناسبة في معظم الحالات. إبقاء TTL قصيرًا بشكل دائم يضاعف دون فائدة عدد الاستعلامات الموجهة إلى خوادم الأسماء الخاصة بك.
12. اليوم +7 — ألغِ العقد القديم، وليس قبل ذلك. انتظر حتى تتلقى رسائل على صناديق البريد الجديدة، وتستعيد نسخة احتياطية لدى المستضيف الجديد، وتراجع سجلات الأخطاء. فالإلغاء غالبًا ما يحذف البيانات في اليوم نفسه.

ما ننقله، وبأي وسيلة

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

• الملفات. rsync عبر SSH عندما يسمح الطرفان بذلك، وإلا فـ SFTP. مرحلتان أفضل من واحدة: الأولى كاملة أثناء عمل الموقع، والثانية قبيل التحويل مباشرة لنقل الفروقات فقط. تحقق بعد ذلك من سلامة الصلاحيات والمالكين والروابط الرمزية — فإعداد FTP غير السليم يمحوها دون إنذار.
• قواعد البيانات. mysqldump --single-transaction --quick لـ MySQL وMariaDB، وpg_dump -Fc لـ PostgreSQL. سجل ترميز الأحرف والترتيب (collation) لقاعدة البيانات الأصلية، وأنشئ القاعدة الهدف بالإعدادات نفسها: فهذا التفصيل هو ما يحول الأحرف الخاصة إلى رموز غير مقروءة بعد الاستيراد.
• النسخة الاحتياطية للوحة التحكم. إذا كانت استضافتك الحالية تدار بلوحة تحكم، فإن أداة التصدير المدمجة فيها — الملفات وقواعد البيانات وصناديق البريد والإعدادات في أرشيف واحد — هي غالبا الطريق الأكثر أمانا. تأتي عروض استضافة الويب لدينا مع لوحة Plesk، التي تملك أدواتها الخاصة للنسخ الاحتياطي والاستعادة.
• صورة القرص لخادم كامل. على VPS أو خادم مخصص، هناك طريقان: نسخ القرص كما هو (صورة raw أو qcow2، أو نسخ كتلة بكتلة من نظام إنقاذ)، أو البدء من نظام نظيف وإعادة نشر التطبيق عليه. إذا لم يتح مزودك الحالي الوصول إلى صورة القرص، فالطريق الثاني هو الوحيد الممكن — وهو على أي حال ما ننصح به لنظام عمره عدة سنوات.
• الشهادات. لا تنقلها: تُعاد إصدار شهادة Let's Encrypt في بضع ثوانٍ على الخادم الجديد بعد توجيه النطاق إليه. إذا كنت تدفع مقابل شهادة ذات تحقق موسّع، فصدّر المفتاح الخاص قبل الإلغاء، وإلا فسيتعين عليك شراؤها من جديد.
• صناديق البريد الإلكتروني. تنسخ مزامنة IMAP الرسائل وبنية المجلدات وحالات القراءة من خادم إلى آخر. شغّلها مرتين، كما في الملفات: مرة قبل التحويل ومرة بعده، لاستدراك الرسائل التي وصلت بينهما.
• المهام المجدولة والخدمات. مهام cron ومؤقتات systemd وطوابير الانتظار والعمليات الدائمة لا تظهر في أي نسخة احتياطية للموقع. انسخها يدويا، ثم تحقق من أنها تعمل بعد التحويل، لا أنها معرفة فقط.
• الأسرار. مفاتيح SSH المصرح بها، ورموز API، ومفاتيح التشفير الخاصة بالتطبيقات، وبيانات اعتماد الخدمات: كثيرا ما توجد خارج مجلد الموقع وتضيع دون أن يلاحظ أحد. التطبيق الذي يعمل لكنه لم يعد يفك تشفير بياناته، سببه دائما تقريبا مفتاح بقي على الخادم القديم.

DNS: ما يُحضَّر مسبقًا، وما يُحوَّل يوم التنفيذ

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

ومن هنا القاعدة: يخفض TTL قبل التحويل، وليس أثناءه أبدا. إذا كانت قيمة TTL لديك اليوم 86 400 ثانية وخفضتها إلى 300 صباح يوم التحويل، فإن خوادم التحليل التي تحتفظ بالقيمة القديمة ستواصل الالتزام بها لمدة أربع وعشرين ساعة. أما بخفضها قبل 48 ساعة، فتترك القيمة القديمة تنتهي تلقائيا، ويصبح التحويل مسألة دقائق.

1. قبل 48 ساعة: خفض TTL إلى 300 ثانية لجميع السجلات التي ستعدلها — على الأقل A وAAAA، إضافة إلى MX وسجلات CNAME المرتبطة إذا انتقل البريد أيضا. يضبط TTL في منطقة DNS، لدى الجهة التي تستضيف هذه المنطقة: مسجل النطاقات في أغلب الحالات.
2. سجّل حالة المنطقة الحالية قبل تعديلها. يمنحك استعلام dig votredomaine.fr ANY، أو تصدير المنطقة من الواجهة، حالة البداية. احتفظ بها: فهي نقطة العودة إذا حدث خطأ ما.
3. A وAAAA. يحمل سجل A عنوان IPv4 للاستضافة الجديدة، وسجل AAAA عنوان IPv6 إن وجد. لا تنس www ولا النطاقات الفرعية المستخدمة فعلا: webmail أو api أو بيئة ما قبل الإنتاج. فالنطاقات المنسية هي تلك التي لا نزورها بأنفسنا أبدا.
4. MX: السجل الذي يُنسى. يحدد الخادم الذي يستقبل بريدك، وهو مستقل عن الخادم الذي يستضيف الموقع. إذا بقي بريدك الإلكتروني في مكانه، فلا تغيّره: هذا هو الخطأ الشائع في عملية التحويل «نستبدل جميع عناوين IP في المنطقة»، إذ يحوّل البريد إلى خادم لا يعرفه. وإذا انتقل البريد الإلكتروني، فلا تغيّر سجل MX إلا بعد إنشاء صناديق البريد ومزامنتها.
5. SPF. هو سجل TXT واحد يعدّد الخوادم المصرّح لها بإرسال البريد باسمك. إذا ظل يشير إلى الاستضافة القديمة، فستُصنَّف الرسائل المرسلة من الخادم الجديد كرسائل غير مرغوب فيها أو تُرفض. أضف الخادم الجديد قبل التحويل، واحذف القديم بعد تأكيد النقل، واحتفظ بسجل SPF واحد فقط: فوجود سجلين يُبطل كلًّا منهما.
6. DKIM. ينتج خادم الإرسال التوقيع، ويُتحقق منه بواسطة مفتاح عام منشور في منطقتك تحت محدِّد (selector). انشر محدِّد الخادم الجديد قبل التحويل واترك القديم بضعة أيام: يمكن لمحدِّدين أن يتعايشا دون تعارض، وهذا لا ينطبق على SPF.
7. DMARC. يخبر المستلمين بما يجب فعله بالرسائل التي تفشل في عمليات التحقق السابقة. أثناء النقل، أبقِ الإعداد على p=none مع عنوان لتلقي التقارير: تراقب دون أن تعطّل شيئًا، ثم تشدّد السياسة عندما يصبح SPF وDKIM سليمين في الجانبين.
8. CAA، إن وُجد. يسرد هذا السجل الجهات المصرّح لها بإصدار شهادة لنطاقك. إذا لم يذكر الجهة التي يستخدمها مزوّد الاستضافة الجديد، يفشل الإصدار بصمت ويبقى الموقع بشهادة HTTPS غير صالحة، دون أي رسالة خطأ واضحة.
9. Reverse DNS (PTR). لا يُضبط في منطقتك بل على عنوان IP، أي لدى مزوّد الاستضافة الذي يملكه. ويصبح مهمًّا بمجرد أن يرسل خادمك البريد بنفسه: فبدون PTR متوافق مع الاسم المُعلَن، يرفض جزء من المستلمين الرسالة. لدينا، يمكن تخصيص reverse DNS عند الطلب.

مدة الانقطاع الفعلية، وكيف تقلصها إلى شبه لا شيء

الانقطاع الذي يخشاه معظم الناس، أي «سيتعذر الوصول إلى موقعي أثناء انتشار DNS»، لا وجود له إذا كانت الاستضافتان تعملان في الوقت نفسه. أثناء الانتشار، يصل جزء من الزوار إلى الخادم القديم والجزء الآخر إلى الجديد، وكلاهما يعرض الموقع. لا أحد يرى خطأ.

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

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

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

تُتبع هذه القائمة من الأعلى إلى الأسفل يوم التحويل. الترتيب ليس شكليا: كل نقطة تفترض التحقق من سابقتها، والفشل في النقطة 2 يجعل كل ما يليها غير قابل للتفسير.

1. تحليل DNS. استعلم من محلل عام ومن محلل مزود خدمة الإنترنت لديك: يجب أن يعيد كلاهما العنوان الجديد. وما لم يتحقق ذلك، فما تراه في متصفحك لا يثبت شيئا.
2. الموقع يستجيب من الجهاز الصحيح. يجب أن يعيد curl -I https://votredomaine.fr الرمز 200؛ وعند الشك، يتيح curl --resolve فرض العنوان ومقارنة الخادمين جنبا إلى جنب.
3. الشهادة. صالحة، وبالاسم الصحيح، وتغطي www أيضا. احسب بضع دقائق بعد الانتشار للإصدار التلقائي؛ وإذا تجاوز الأمر ساعة، فافحص سجل CAA.
4. عمليات إعادة التوجيه. من HTTP إلى HTTPS، ومن www إلى النطاق المجرد أو العكس — لكن في اتجاه واحد فقط، وبرمز 301 لا 302، ودون سلسلة من إعادتي توجيه متتاليتين.
5. الصفحات الداخلية. الصفحة الرئيسية تعمل دائما تقريبا. افتح خمسة أو ستة عناوين URL داخلية عشوائيا: هناك تظهر قواعد إعادة الكتابة المفقودة والروابط المطلقة التي بقيت على النطاق القديم.
6. النماذج. أرسل رسالة اختبار من نموذج الاتصال وتحقق من وصولها. النموذج الذي يعرض «شكرا» دون إرسال أي شيء هو أكثر الأعطال شيوعا بعد النقل.
7. الدفع، إن وجد. طلب اختباري في وضع الاختبار (sandbox)، حتى التأكيد والبريد الإلكتروني المرتبط به. وتحقق في الأثناء من أن بوابة الدفع لا تملك قائمة عناوين IP مسموح بها تحتاج إلى تحديث.
8. البريد الصادر. أرسل رسالة من الموقع إلى عنوان خارجي، وافتح ترويسة الرسالة المستلمة واقرأ نتائج SPF وDKIM. يجب أن تكون «pass» في الحالتين؛ وإلا فراجع قسم DNS.
9. البريد الوارد. راسل من الخارج أحد العناوين المنقولة، واستمر في مراقبة الصندوق القديم لبضعة أيام.
10. المهام المجدولة. انتظر حتى يتم تنفيذ واحد وتحقق من أثره، بدلا من الاكتفاء بوجود السطر في جدول المهام.
11. سجلات الأخطاء. راجعها خلال أول 48 ساعة. فالامتداد المفقود أو المسار المطلق المكتوب بشكل ثابت يظهر فيها فورا، وغالبا قبل أن يشتكي أي أحد.
12. نسخة احتياطية أولى لدى مزود الاستضافة الجديد. أنشئها، ثم استعدها مرة للتحقق من أنها قابلة للاستخدام. هذا هو الشرط الواجب استيفاؤه قبل إلغاء العقد القديم.

الأفخاخ التي تضيع يوما كاملا

• خفض TTL في اليوم نفسه. لا فائدة منه: فالقيمة القديمة الطويلة مخزنة مؤقتا بالفعل. يبقى جزء من زوارك على الخادم القديم طوال اليوم، وتبحث عن عطل لا وجود له.
• تغيير MX بشكل تلقائي. استبدال «كل عناوين IP في المنطقة» ينقل البريد مع الموقع. إذا لم تنتقل خدمة البريد، فلا يتغير MX.
• ترك SPF على الخادم القديم. الموقع يعمل، والرسائل ترسل، ولا أحد يستلمها — أو تصل إلى البريد غير المرغوب فيه. إنه أصعب عطل يمكن تشخيصه لاحقا، لأن لا شيء يفشل بشكل ظاهر.
• إلغاء العقد القديم مبكرا. الإلغاء يمحو البيانات، غالبا في اليوم نفسه، ويأخذ معه الرسائل الواصلة بعد التحويل والنسخة الحديثة الوحيدة المتبقية من الملفات.
• طلب الشهادة قبل أن يشير DNS إلى الخادم الجديد. يفشل التحقق، ويظهر الموقع مع تحذير أمني، ويحتفظ المتصفح بالخطأ في ذاكرته. انتظر الانتشار، ثم اطلب الإصدار.
• نسخ ملف robots.txt الخاص ببيئة ما قبل الإنتاج كما هو. سطر Disallow: / موروث من بيئة الاختبار يزيل فهرسة الموقع في غضون أيام. راجع هذا الملف مباشرة بعد التحويل.
• تغير إصدار PHP دون قرار منك. غالبا ما تقترح الاستضافة الجديدة إصدارا أحدث افتراضيا. أعد أولا الإصدار الأصلي، ثم حدّثه لاحقا بعد إتمام النقل.
• نسيان ذاكرة التخزين المؤقت وCDN. إذا كان موقعك خلف CDN، فليس السجل A العام هو ما يجب تغييره، بل المصدر المعرّف في CDN. وامسح ذاكرة التخزين المؤقت بعد التحويل، وإلا ستواصل تقديم الموقع القديم.
• قوائم عناوين IP المسموح بها لدى الأطراف الأخرى. بوابة الدفع، مرحّل SMTP، API الشريك، قاعدة البيانات البعيدة: كل ما يرشّح حسب عنوان IP يجب أن يعرف العنوان الجديد قبل التحويل، لا بعده.

نقل خادم ليس كنقل موقع

تحمل العمليتان الاسم نفسه لكن مضمونهما مختلف. نقل موقع يعني نقل الملفات وقاعدة البيانات وصناديق البريد إلى استضافة مُدارة مسبقًا: النظام والتحديثات الأمنية ولوحة التحكم مُوفَّرة. وهذا ما يشمله النقل الذي نتولاه إلى عروض استضافة المواقع لدينا.

نقل خادم يعني إعادة بناء جهاز: النظام والحزم والخدمات والجدار الناري والمستخدمون والشهادات والنسخ الاحتياطية. على VPS KVM، تحصل على عنوان IPv4 مخصص ووصول root عبر SSH ولوحة تحكم تتيح إعادة التشغيل وإعادة التثبيت واللقطات والوحدة الطرفية. وتكون هذه الوحدة الطرفية مهمة يوم التحويل: فهي التي تتيح لك استعادة التحكم إذا أغلقت قاعدة في الجدار الناري باب SSH أمامك.

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

تحسين محركات البحث أثناء النقل

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

• روابط تتغير دون إعادة توجيه. إذا تغيرت البنية مع تغيير الاستضافة، فجهّز جدول المطابقة قبل التحويل واستخدم 301 لا 302. واحتفظ بها اثني عشر شهرا على الأقل.
• منع فهرسة غير مقصود. robots.txt، الترويسة X-Robots-Tag، الوسم noindex الموروث من بيئة اختبار: تحقق من الثلاثة في اليوم نفسه.
• موقع أبطأ من السابق. غالبا ما يلزم إعادة تفعيل ذاكرة التخزين المؤقت للتطبيق والضغط على الاستضافة الجديدة. قارن زمن الاستجابة قبل النقل وبعده بدلا من افتراضه.
• خريطة موقع معطلة. تحقق من أنها ما زالت متاحة ومحدّثة، ثم دع المحرك يعود من تلقاء نفسه. يستعيد إيقاع الزحف وضعه خلال أيام قليلة؛ ولا داعي لفرض أي شيء إذا لم تتغير الروابط.