انتقال وردپرس به هاست جدید با کمترین قطعی

برای انتقال وردپرس به هاست جدید با کمترین قطعی ابتدا یک کپی کامل از فایل‌ها و دیتابیس روی مقصد بسازید، مقصد را پیش از تغییر DNS با دامنه واقعی آزمایش کنید، سپس در یک بازه کوتاه سایت مبدأ را روی حالت نگهداری ببرید، آخرین تغییرات را همگام کنید و DNS را به IP جدید تغییر دهید. هاست قدیمی را تا پایان اطمینان از مهاجرت حذف نکنید؛ این سرور مسیر بازگشت شماست.

این راهنما برای سروری است که روی هر دو سمت SSH و WP-CLI دارید. در هاست اشتراکی می‌توانید همین منطق را با ابزار مهاجرت میزبان اجرا کنید، اما نام مسیرها و روش ساخت دیتابیس متفاوت است. انتقال یک سایت شامل فایل‌ها و دیتابیس است؛ کپی‌کردن فقط wp-content نوشته‌ها، تنظیمات، کاربران و سفارش‌ها را منتقل نمی‌کند.

قبل از انتقال چه چیزهایی را بررسی کنیم؟

نسخه PHP، دیتابیس، فضای دیسک، HTTPS، cron، ایمیل و extensionهای PHP مقصد را با سایت فعلی مقایسه کنید. وردپرس در حال حاضر PHP 8.3 یا جدیدتر، MySQL 8.0 یا MariaDB 10.11 به بالا و HTTPS را به‌عنوان پایه مدرن توصیه می‌کند. اگر قالب یا افزونه قدیمی دارید، سازگاری آن را ابتدا روی staging بسنجید.

cd /var/www/example.com/public
wp core version
wp cli info
wp db check
wp plugin list --status=active
wp theme list --status=active
df -h

فرمان‌ها را در ریشه وردپرس مبدأ اجرا کنید. خروجی افزونه و قالب فعال را نگه دارید تا بعداً با مقصد مقایسه شود. اگر فروشگاه یا سایت عضویتی دارید، بازه نهایی را در کم‌ترافیک‌ترین زمان انجام دهید و زمان نگهداری را از قبل اطلاع‌رسانی کنید.

مرحله اول: بکاپ مستقل و قابل بازیابی بگیرید

فایل SQL را خارج از مسیر عمومی سایت بسازید و فایل‌های برنامه را جداگانه آرشیو کنید:

cd /var/www/example.com/public
wp db export "$HOME/wordpress-before-migration.sql" --add-drop-table
tar -czf "$HOME/wordpress-files-before-migration.tar.gz" \
  --exclude='wp-content/cache' \
  --exclude='wp-content/upgrade' \
  .

WP-CLI اطلاعات اتصال دیتابیس را از wp-config.php می‌خواند. وجود فایل‌ها را با ls -lh و فضای آزاد را با df -h کنترل کنید. حداقل یک کپی را خارج از هر دو سرور نگه دارید و پس از مهاجرت، SQL را در پوشه قابل دانلود باقی نگذارید. مستندات رسمی وردپرس تأکید می‌کند که برای بازیابی کامل به هر دو بخش فایل و دیتابیس نیاز دارید.

انتقال کم‌ریسک با کپی اولیه، تست مستقل، همگام‌سازی نهایی و حفظ مسیر بازگشت انجام می‌شود.

مرحله دوم: کپی اولیه فایل‌ها را به مقصد بفرستید

در مقصد، دامنه و document root را بسازید و مالکیت فایل‌ها را مطابق وب‌سرور همان هاست تنظیم کنید. سپس از مبدأ، فایل‌ها را با rsync منتقل کنید:

cd /var/www/example.com/public
rsync -aH --info=progress2 \
  --exclude='wp-content/cache/' \
  --exclude='wp-content/upgrade/' \
  ./ deploy@NEW_SERVER_IP:/var/www/example.com/public/

deploy، IP و مسیر مقصد را جایگزین کنید. گزینه -a زمان و ساختار فایل‌ها را حفظ می‌کند و -H hard linkها را نگه می‌دارد. مالکیت را کورکورانه از سرور قبلی کپی نکنید؛ کاربر PHP-FPM در مقصد ممکن است متفاوت باشد. از chmod -R 777 نیز استفاده نکنید.

مرحله سوم: دیتابیس مقصد را آماده و وارد کنید

یک دیتابیس و کاربر مجزا در مقصد بسازید و مقادیر DB_NAME، DB_USER، DB_PASSWORD و DB_HOST را در wp-config.php مقصد قرار دهید. سپس SQL اولیه را با کانال امن منتقل و import کنید:

scp "$HOME/wordpress-before-migration.sql" \
  deploy@NEW_SERVER_IP:/home/deploy/

ssh deploy@NEW_SERVER_IP
cd /var/www/example.com/public
wp db import /home/deploy/wordpress-before-migration.sql
wp db check

فرمان wp db import دیتابیس را ایجاد نمی‌کند؛ دیتابیس و دسترسی کاربر باید از قبل وجود داشته باشد. رمز دیتابیس را داخل command history ننویسید. اگر WP-CLI به‌دلیل یک افزونه ناسازگار بالا نمی‌آید، ابتدا خطا را رفع کنید؛ استفاده دائمی از --skip-plugins می‌تواند یک مشکل واقعی در مقصد را پنهان کند.

آیا باید URLها را تغییر دهیم؟

اگر دامنه و پروتکل همان قبلی است، search-replace لازم نیست. مقصد را با همان URL نگه دارید و برای تست، resolve محلی انجام دهید. اگر دامنه یا مسیر واقعاً تغییر می‌کند، WP-CLI داده‌های serialize شده را امن‌تر از جایگزینی خام SQL مدیریت می‌کند. ابتدا dry-run بزنید:

wp search-replace 'https://old.example.com' 'https://new.example.com' \
  --all-tables-with-prefix --skip-columns=guid --dry-run

گزارش را بررسی و سپس همان فرمان را بدون --dry-run اجرا کنید. ستون guid را تغییر ندهید؛ راهنمای رسمی وردپرس می‌گوید GUID باید برای حفظ هویت نوشته در feed ثابت بماند. در Multisite از دستور و برنامه مهاجرت مخصوص شبکه استفاده کنید؛ این راهنما برای نصب معمولی است.

مرحله چهارم: مقصد را پیش از تغییر DNS تست کنید

اگر گواهی معتبر روی مقصد نصب شده، می‌توانید بدون تغییر DNS درخواست را مستقیماً به IP جدید بفرستید:

curl --resolve example.com:443:NEW_SERVER_IP \
  -I https://example.com

curl --resolve example.com:443:NEW_SERVER_IP \
  -I https://example.com/wp-login.php

از -k برای نادیده‌گرفتن خطای TLS استفاده نکنید؛ مشکل گواهی باید پیش از cutover حل شود. برای آزمون مرورگر، نگاشت موقت دامنه و IP جدید را فقط روی رایانه خود در فایل hosts اضافه کنید. صفحه اصلی، مدیریت، ورود، فرم‌ها، آپلود تصویر، جست‌وجو، خرید آزمایشی و ارسال ایمیل را کنترل کنید. سپس این بررسی‌ها را روی مقصد اجرا کنید:

wp option get home
wp option get siteurl
wp core verify-checksums
wp cron test
wp rewrite flush

Checksum فقط فایل‌های هسته را با WordPress.org مقایسه می‌کند و سلامت افزونه یا فایل‌های آپلودی را تضمین نمی‌کند. پس از تست، ورودی hosts را حذف کنید تا نتیجه DNS عمومی را اشتباه نبینید.

مرحله پنجم: همگام‌سازی نهایی و تغییر DNS

کپی اولیه یک snapshot است؛ نوشته، سفارش یا دیدگاهی که بعد از آن ساخته شده باید در انتقال نهایی وارد شود. روی مبدأ حالت نگهداری را فعال، SQL نهایی را صادر و فایل‌ها را دوباره همگام کنید:

cd /var/www/example.com/public
wp maintenance-mode activate
wp db export "$HOME/wordpress-final.sql" --add-drop-table
rsync -aH --exclude='wp-content/cache/' \
  --exclude='wp-content/upgrade/' \
  ./ deploy@NEW_SERVER_IP:/var/www/example.com/public/
scp "$HOME/wordpress-final.sql" deploy@NEW_SERVER_IP:/home/deploy/

در مقصد SQL نهایی را وارد، cache را خالی و سلامت را دوباره بررسی کنید:

cd /var/www/example.com/public
wp db import /home/deploy/wordpress-final.sql
wp cache flush
wp db check
curl --resolve example.com:443:NEW_SERVER_IP -I https://example.com

اکنون رکورد A و در صورت استفاده AAAA را به سرور جدید تغییر دهید. اگر TTL را از یک روز قبل کاهش داده‌اید، انتشار سریع‌تر می‌شود؛ پس از پایدارشدن سرویس آن را به مقدار عادی برگردانید. Nameserverها را فقط وقتی عوض کنید که کل zone، شامل MX، SPF، DKIM و رکوردهای دیگر، روی DNS جدید بازسازی شده باشد.

مرحله ششم: بعد از انتقال چه چیزهایی را پایش کنیم؟

• از چند شبکه، IP دامنه و پاسخ HTTPS را بررسی کنید.
• لاگ PHP و وب‌سرور را برای 404، 500 و خطای permission بخوانید.
• فرم تماس، ایمیل تراکنشی، cron، صف و webhookهای پرداخت را آزمایش کنید.
• فایل‌های SQL را از مقصد حذف یا به فضای بکاپ محدود منتقل کنید.
• هاست قدیمی را حداقل ۴۸ ساعت سالم اما بدون پذیرش محتوای جدید نگه دارید.

اگر انتقال خراب شد چگونه برگردیم؟

رکورد DNS را به IP قبلی برگردانید و روی مبدأ wp maintenance-mode deactivate اجرا کنید. تا وقتی مقصد تأیید نشده، فایل یا دیتابیس مبدأ را حذف نکنید. هم‌زمان writable نگه‌داشتن هر دو سایت خطر split-brain دارد؛ سفارش و دیدگاه می‌تواند بین دو دیتابیس پخش شود. پس از بازگشت، علت را از لاگ مقصد پیدا و migration را با snapshot تازه تکرار کنید.

جمع‌بندی

انتقال مطمئن وردپرس با کپی اولیه و آزمون مقصد شروع می‌شود، نه با تغییر فوری DNS. بکاپ مستقل بگیرید، فایل و دیتابیس را منتقل کنید، URL را فقط در صورت تغییر واقعی و با dry-run اصلاح کنید، سپس با یک توقف کوتاه snapshot نهایی را وارد و DNS را جابه‌جا کنید. حفظ هاست قدیمی و جلوگیری از نوشتن هم‌زمان روی دو سایت، مسیر بازگشت را ساده نگه می‌دارد.

پیش از انتخاب مقصد، راهنمای خرید هاست وردپرس را ببینید. برای cutover دقیق، آموزش رکوردهای DNS و برای HTTPS مقصد، نصب SSL روی Nginx مفید است. اگر پس از انتقال پاسخ داخلی سرور دیدید، مسیر رفع خطای 500 وردپرس را دنبال کنید.

منابع رسمی: راهنمای مهاجرت وردپرس، راهنمای بکاپ وردپرس، دستور wp db export، دستور wp db import، دستور wp search-replace و حالت نگهداری WP-CLI.