الاستعداد للنقل من cPanel دون توقف: قائمة تحقق خطوة بخطوة

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

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

ما الذي يجب جرده قبل أي نسخ؟

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

• المجالات: المجال الرئيسي وكل مجال إضافي مرتبط بالحساب، مع الجهة التي تدير سجلات DNS لكل منها.
• المجالات الفرعية: ومسار المجلد الجذري لكل منها، لأنه لا يتبع دائمًا النمط المتوقع.
• حسابات البريد الإلكتروني: العناوين، وحجم كل صندوق، وحصة التخزين.
• معيدو توجيه البريد الإلكتروني: ومعها عوامل تصفية البريد الإلكتروني والمستجيبون التلقائيون إن وجدت.
• قواعد البيانات: أسماء قواعد بيانات MySQL، وكل مستخدم قاعدة البيانات وصلاحياته، وترميز الجداول.
• وظائف Cron: التوقيت والأمر الكامل والمسارات المطلقة داخله.
• شهادات SSL: المجالات التي تغطيها كل شهادة وتاريخ "ينتهي في"، وهل هي شهادة تلقائية أم مثبتة يدويًا.
• إصدار PHP: لكل مجال، مع الإضافات المفعّلة وقيم مثل memory_limit وupload_max_filesize.
• سجلات DNS: نسخة كاملة من Zone Editor (محرر منطقة DNS)، خصوصًا سجلات TXT الخاصة بـSPF وDKIM والتحقق من الخدمات الخارجية.

إذا كان لديك الوصول إلى SSH أو Terminal في cPanel، فاستخرج معظم هذه القائمة بأوامر UAPI بدل النسخ اليدوي من الواجهة:

uapi --output=jsonpretty DomainInfo domains_data
uapi --output=jsonpretty Email list_pops
uapi --output=jsonpretty Email list_forwarders
uapi --output=jsonpretty Mysql list_databases
uapi --output=jsonpretty SSL list_certs
uapi --output=jsonpretty LangPHP php_get_vhost_versions
crontab -l

احفظ المخرجات في ملف يحمل تاريخ الجرد. ستحتاجه لاحقًا للمقارنة بعد التحويل.

لماذا يجب خفض TTL قبل النقل بيوم أو أكثر؟

قيمة TTL في كل سجل DNS تحدد المدة التي تحتفظ فيها المحللات (Resolvers) بالإجابة في ذاكرتها المؤقتة. إذا كانت القيمة الحالية لسجل A يومًا كاملًا ثم غيّرت العنوان، فقد يبقى جزء من الزوار على الخادم القديم حتى تنتهي تلك المدة.

القاعدة: اخفض TTL لسجلات A وAAAA وMX وCNAME المعنية إلى قيمة قصيرة، مثل 300 ثانية، ثم انتظر مدة لا تقل عن قيمة TTL القديمة قبل يوم التحويل. بعد ذلك تحقق من القيمة التي تراها المحللات العامة فعلًا:

dig +noall +answer example.com A
dig +noall +answer @1.1.1.1 example.com MX

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

كيف تأخذ نسخة احتياطية كاملة قبل أن تلمس أي شيء؟

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

خزّن هذه النسخة خارج الخادمين معًا، ولا تعتمد على نسخة موجودة على الخادم الذي ستغادره. للتفاصيل راجع استراتيجية النسخ الاحتياطي 3-2-1 لحسابات الاستضافة.

كيف تنسخ الملفات وقواعد البيانات دون إيقاف الموقع؟

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

# تجربة دون تنفيذ أولًا
rsync -avzn -e ssh user@old-server:/home/user/public_html/ /var/www/example.com/
# النسخ الفعلي
rsync -avz -e ssh user@old-server:/home/user/public_html/ /var/www/example.com/

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

لقواعد البيانات استخدم mysqldump مع الخيار --single-transaction حتى تحصل على لقطة متسقة لجداول InnoDB دون قفلها:

mysqldump --single-transaction --routines --triggers \
  --default-character-set=utf8mb4 -u dbuser -p dbname | gzip > dbname.sql.gz

# على الخادم الجديد
gunzip < dbname.sql.gz | mysql -u dbuser -p dbname

بعد الاستيراد، أنشئ مستخدم قاعدة البيانات بالصلاحيات نفسها، وحدّث ملف الإعدادات في التطبيق، مثل wp-config.php أو .env، إذا تغيّر اسم المستخدم أو المضيف. ثبّت إصدار PHP نفسه الذي جردته، ثم أعد إنشاء وظائف Cron بمسارات الخادم الجديد، واتركها معطلة حتى يوم التحويل.

كيف تختبر الموقع على الخادم الجديد قبل تغيير DNS؟

لا تغيّر DNS لتختبر. وجّه جهازك وحده إلى الخادم الجديد عبر ملف hosts. على macOS وLinux الملف هو /etc/hosts، وعلى Windows هو C:\Windows\System32\drivers\etc\hosts:

203.0.113.10  example.com  www.example.com

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

curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

ستحتاج شهادة SSL على الخادم الجديد قبل التحويل. إما أن تنقل الشهادة الحالية ومفتاحها، أو تصدر شهادة جديدة بتحقق DNS-01، لأن التحقق عبر HTTP لن ينجح قبل أن يشير المجال إلى الخادم الجديد. راجع وثائق Let's Encrypt لأنواع التحقق. احذف سطر hosts بعد الانتهاء حتى لا يضللك لاحقًا.

كيف تنقل البريد الإلكتروني دون فقدان رسائل؟

البريد أصعب جزء لأن الرسائل تصل باستمرار. الطريقة العملية هي مزامنة IMAP بين الخادمين بأداة مثل imapsync، على ثلاث مراحل:

1. أنشئ حسابات البريد الإلكتروني نفسها على الخادم الجديد.
2. شغّل مزامنة أولى كاملة قبل يوم التحويل.
3. بعد تغيير سجل MX، شغّل المزامنة مرة أخرى. الأداة تتجاوز الرسائل المنسوخة سابقًا وتنقل الجديد فقط.

imapsync --host1 mail.old-server.example --user1 info@example.com --passfile1 /root/p1 \
         --host2 mail.new-server.example --user2 info@example.com --passfile2 /root/p2 \
         --ssl1 --ssl2

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

حدّث سجل SPF ليشمل عنوان IP للخادم الجديد، وانقل مفتاح DKIM أو أنشئ مفتاحًا جديدًا وانشر سجله قبل التحويل. التفاصيل في وصول البريد إلى صندوق الوارد: SPF وDKIM وDMARC.

ما نافذة التجميد ومتى تحتاجها؟

الموقع الثابت لا يحتاج تجميدًا. أما الموقع الديناميكي، مثل متجر أو منتدى أو موقع WordPress يستقبل تعليقات وطلبات، فيكتب بيانات جديدة في قاعدة البيانات باستمرار. إذا حوّلت DNS دون تجميد، فقد تُكتب طلبات على الخادم القديم بعد آخر نسخة، فتضيع.

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

ما الترتيب الصحيح ليوم التحويل؟

1. تأكد أن TTL المنخفض أصبح فعّالًا لدى المحللات العامة.
2. ابدأ نافذة التجميد على الخادم القديم وأوقف وظائف Cron فيه.
3. شغّل rsync الأخير، وخذ نسخة mysqldump الأخيرة واستوردها.
4. اختبر الخادم الجديد عبر curl --resolve مرة أخيرة.
5. غيّر سجلات A وAAAA إلى عنوان الخادم الجديد.
6. غيّر سجل MX، أو سجل A الذي يشير إليه، ثم شغّل imapsync مجددًا.
7. فعّل وظائف Cron على الخادم الجديد وألغِ وضع الصيانة.

اكتب هذه الخطوات مع اسم من ينفذ كل خطوة ووقتها المتوقع، ولا ترتجل في يوم التحويل.

ما الذي تتحقق منه بعد التحويل؟

• استعلم من أكثر من محلل عام، مثل dig @1.1.1.1 وdig @8.8.8.8، وتأكد أن العنوان الجديد يظهر.
• راقب سجلات الوصول على الخادم القديم. استمرار الزيارات أمر طبيعي لفترة، لكن يجب أن يتناقص.
• راجع سجلات الأخطاء في الخادم الجديد بحثًا عن أخطاء PHP أو صلاحيات ملفات.
• أرسل رسالة واستقبل أخرى من كل صندوق مهم، وافحص رؤوس الرسالة لتتأكد من نجاح SPF وDKIM.
• تأكد من تشغيل وظائف Cron مرة واحدة على الأقل في موعدها وبالنتيجة المتوقعة.
• تحقق من صلاحية شهادة SSL لكل مجال ومجال فرعي، ومن تفعيل التجديد التلقائي.
• قارن قائمة الجرد الأولى بما هو موجود فعليًا على الخادم الجديد.

بعد أن يستقر كل شيء، أعد TTL إلى قيمة أطول.

كيف تكتب خطة التراجع؟

التراجع (Rollback) يجب أن يكون قرارًا محددًا مسبقًا، لا ردة فعل. لا تلغِ الخادم القديم ولا تحذف منه شيئًا لعدة أيام. حدّد مسبقًا معايير التراجع، مثل فشل الدفع أو عدم وصول البريد، ومن يملك قرار التراجع.

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

كيف يساعدك bPanel في النقل؟

ينقل bPanel الحسابات من cPanel بالترتيب الموضح هنا: الجرد، ثم الملفات وقواعد البيانات، ثم البريد، ثم التحويل، ويرافقك فريقنا في النقل إن أردت؛ تحدث معنا. وإذا لم تحسم بعد مكان الخادم الجديد، فراجع اختيار موقع الاستضافة وزمن الاستجابة لجمهور السعودية والخليج.

الخلاصة

• اجرد كل شيء قبل النسخ: المجالات والمجالات الفرعية والبريد وقواعد البيانات ووظائف Cron وشهادات SSL وإصدار PHP وسجلات DNS.
• اخفض TTL مبكرًا بمدة لا تقل عن قيمته القديمة.
• انسخ على دفعتين، واختبر عبر ملف hosts قبل تغيير DNS.
• زامن البريد قبل تبديل MX وبعده.
• جمّد الكتابة في المواقع الديناميكية أثناء النسخة الأخيرة.
• لا تحذف الخادم القديم، واكتب حد التراجع مسبقًا.