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

برای انتقال سایت وردپرس به سرور جدید، ابتدا نسخه‌ای از فایل‌ها و دیتابیس را روی مقصد آماده و آزمایش کنید. سپس ثبت داده‌های تازه را در مبدأ موقتاً متوقف کنید، آخرین تغییرات را منتقل کنید و مسیر دسترسی کاربران را به مقصد ببرید. تغییر DNS آخرین بخش این فرایند است؛ خودش سفارش‌ها، فرم‌ها یا فایل‌های تازه را منتقل نمی‌کند.

این راهنما انتقال یک سایت وردپرسی معمولی با دامنه و نشانی‌های ثابت را پوشش می‌دهد. مقصد می‌تواند سرور مجازی آماده‌شده باشد و مبدأ، هاست یا سرور قبلی. انتقال شبکهٔ وردپرس، تغییر هم‌زمان دامنه یا جابه‌جایی دیتابیس مشترک چند برنامه، به برنامهٔ جداگانه نیاز دارد. همچنین کاهش قطعی با تضمین «انتقال بدون قطعی» یکسان نیست؛ برای بسیاری از سایت‌ها، توقف کوتاه و برنامه‌ریزی‌شدهٔ ثبت داده امن‌تر است.

۱. پیش از انتقال، وابستگی‌های سایت را مشخص کنید

فقط حجم فایل‌ها را ملاک انتخاب مقصد قرار ندهید. نسخهٔ PHP، افزونه‌های موردنیاز، تنظیمات وب‌سرور و روش اجرای کارهای زمان‌بندی‌شده بر عملکرد سایت اثر دارند. اگر مقصد هنوز آماده نیست، ابتدا محیط اجرای سازگار با وردپرس را آماده کنید؛ هنگام بازیابی سایت موجود، نصب‌کنندهٔ وردپرس را روی دیتابیس منتقل‌شده اجرا نکنید.

برای انتقال، ارتقای هم‌زمان PHP، تغییر قالب و تعویض چند افزونه را به برنامه اضافه نکنید؛ مگر اینکه ناسازگاری مشخصی مانع انتقال باشد. هر تغییر اضافه، تشخیص علت خطا را دشوارتر می‌کند. وضعیت سفارش‌ها و فرم‌ها، خطاهای فعلی و زمان تهیهٔ نسخهٔ پشتیبان را نیز ثبت کنید تا مبنای مقایسه داشته باشید.

۲. نسخهٔ پشتیبان قابل بازیابی تهیه کنید

نسخهٔ پشتیبان وردپرس باید فایل‌ها و دیتابیس را پوشش دهد. خروجی بخش «ابزارها > برون‌بری» به‌تنهایی جایگزین این نسخه نیست. فایل تنظیمات، افزونه‌ها، قالب‌ها، بارگذاری‌های کاربران و فایل‌های مخفی مانند .htaccess را فراموش نکنید. اگر رسانه‌ها در فضای ذخیره‌سازی بیرونی قرار دارند، روش دسترسی و پشتیبان‌گیری آن‌ها را جداگانه بررسی کنید.

نسخهٔ پشتیبان را خارج از پوشهٔ عمومی سایت نگه دارید و یک نسخهٔ مستقل نیز ذخیره کنید. فایل SQL و آرشیو سایت ممکن است اطلاعات کاربران و رمزهای اتصال را در خود داشته باشند؛ آن‌ها را از مسیر امن منتقل کنید. مستندات پشتیبان‌گیری وردپرس اجزای اصلی این نسخه را توضیح می‌دهد.

در هاست اشتراکی می‌توانید از امکانات پنل یا ابزار انتقال سازگار با سایت استفاده کنید. پیش از انتخاب افزونه، محدودیت حجم، سازگاری نسخه‌ها و امکان بازیابی خروجی آن را بررسی کنید. داشتن دکمه «پشتیبان‌گیری» کافی نیست؛ باید بتوانید نسخه را در مقصد بازیابی کنید و زمان لازم برای این کار را بدانید.

۳. نسخهٔ اولیه را به مقصد منتقل کنید

در انتقال دستی، ابتدا فایل‌ها را با حفظ ساختار پوشه‌ها منتقل کنید، سپس دیتابیس را خروجی بگیرید و در یک دیتابیس جداگانه در مقصد وارد کنید. اطلاعات اتصال جدید را در wp-config.php قرار دهید و پیشوند جدول‌ها را مطابق نسخهٔ اصلی نگه دارید. فایل تنظیمات و رمزهای آن را در تیکت عمومی یا مخزن عمومی قرار ندهید.

اگر WP-CLI در هر دو محیط نصب است، نمونهٔ زیر برای یک نصب مستقل قابل استفاده است. مسیرها نمونه‌اند؛ آن‌ها را با مسیر واقعی سایت جایگزین کنید. دستورها را با حساب مالک فایل‌های سایت اجرا کنید و پوشهٔ خصوصی مقصدِ خروجی را از قبل بسازید؛ پوشه نباید از وب قابل دسترسی باشد.

wp --path=/var/www/wordpress db export /home/deploy/migration/site.sql
tar -czf /home/deploy/migration/site-files.tar.gz -C /var/www/wordpress .

در این مثال، دستور tar آرشیو را بیرون از پوشهٔ سایت می‌سازد و فایل‌های مخفی هم در آن قرار می‌گیرند. اگر دیتابیس بین چند سایت یا برنامه مشترک است، این دستور خروجی عمومی را بدون تعیین دامنهٔ انتقال اجرا نکنید؛ خروجی می‌تواند جدول‌های برنامه‌های دیگر را هم شامل شود. همچنین خروجی فایل‌ها و SQL روی سایت فعال الزاماً متعلق به یک لحظه نیست؛ این نسخه برای آماده‌سازی است و انتقال نهایی بعداً انجام می‌شود.

بازیابی فایل‌ها و دیتابیس در مقصد

آرشیو و SQL را با SFTP یا روش امن معادل به مقصد ببرید. فایل‌ها را در مسیر سایت مقصد بازیابی کنید و مالکیت و مجوزها را با حساب اجرای وب‌سرور هماهنگ کنید. ابتدا دیتابیس و کاربر آن را بسازید و تنظیمات مقصد را به همان دیتابیس متصل کنید. سپس SQL را با WP-CLI یا ابزار پنل وارد کنید:

wp --path=/var/www/wordpress db import /home/deploy/migration/site.sql

این دستور دیتابیس را ایجاد نمی‌کند و محتوای فایل SQL را در دیتابیس تعیین‌شده اجرا می‌کند. پیش از اجرا، میزبان و نام دیتابیس را کنترل کنید تا به مبدأ متصل نباشید. مقصد این مرحله باید دیتابیس خالی و اختصاصی نسخهٔ آزمایشی باشد. جزئیات این رفتار در مستندات واردکردن دیتابیس با WP-CLI آمده است.

در انتقال با دامنهٔ ثابت، آدرس سایت را به IP سرور جدید تغییر ندهید. اگر دامنه یا مسیر نصب نیز عوض می‌شود، جایگزینی سادهٔ متن در SQL ممکن است داده‌های سریال‌شدهٔ افزونه‌ها را خراب کند. آن سناریو را جداگانه و با ابزار آگاه از ساختار داده، مانند search-replace در WP-CLI، ابتدا در حالت dry-run بررسی کنید.

۴. مقصد را با دامنه واقعی و بدون اثر جانبی آزمایش کنید

بازکردن IP سرور برای آزمون کافی نیست؛ تنظیمات دامنه، HTTPS و نشانی‌های وردپرس باید با نام واقعی سایت کار کنند. می‌توانید روی رایانهٔ خود، نگاشت موقت دامنه به IP مقصد را در فایل hosts قرار دهید. این تغییر فقط روی همان رایانه اثر دارد و DNS عمومی را عوض نمی‌کند. در ویندوز، فایل hosts در مسیر زیر قرار دارد و ویرایش آن به دسترسی مدیر نیاز دارد:

C:\Windows\System32\drivers\etc\hosts
203.0.113.20 example.com www.example.com

دامنه و IP بالا نمونه‌اند. پس از ذخیره، مطمئن شوید مرورگر به مقصد وصل می‌شود؛ کش DNS یا DNS امن مرورگر ممکن است بر آزمون اثر بگذارد. برای بررسی پاسخ HTTPS با curl نیز می‌توانید IP مقصد را فقط برای همان درخواست تعیین کنید:

curl --resolve example.com:443:203.0.113.20 -I https://example.com/

طبق مستندات curl، گزینهٔ resolve امکان تعیین مقصد اتصال برای نام و پورت مشخص را می‌دهد. این آزمون اعتبار گواهی را دور نمی‌زند. دریافت پاسخ موفق نیز به‌تنهایی ثابت نمی‌کند که ثبت سفارش یا بارگذاری فایل درست کار می‌کند.

گواهی معتبر دامنه را پیش از تغییر عمومی مسیر آماده کنید. برای نمونه، اعتبارسنجی DNS-01 در مستندات Let’s Encrypt می‌تواند بدون تغییر رکورد A انجام شود؛ اجرای آن به کنترل DNS و ابزار سازگار نیاز دارد. هشدار گواهی را برای عبور از آزمون نادیده نگیرید.

نسخهٔ آزمایشی را با کنترل دسترسی محافظت کنید. noindex ابزار محدودکردن دسترسی نیست. ارسال واقعی ایمیل و پیامک، برداشت وجه و اجرای صف‌ها را در این نسخه غیرفعال یا به محیط آزمایشی منتقل کنید. غیرفعال‌کردن WP-Cron نیز به‌تنهایی کرون سیستم و پردازشگرهای بیرونی را متوقف نمی‌کند.

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

۵. انتقال نهایی را با توقف کنترل‌شدهٔ ثبت داده انجام دهید

برای سایت معرفی کم‌تغییر، این مرحله معمولاً ساده‌تر است. برای فروشگاه، عضویت یا سایتی با فرم‌های فعال، باید دقیقاً بدانید چه مسیرهایی داده می‌نویسند. نمایش صفحهٔ تعمیرات به‌تنهایی تضمین نمی‌کند که API، کرون، وب‌هوک یا پنل مدیریت دیگر چیزی ثبت نکند.

پیش از زمان انتقال، TTL رکوردهای مرتبط را کاهش دهید و به اندازهٔ TTL قبلی فرصت بدهید تا کش‌های قبلی منقضی شوند. مقدار مناسب به سرویس DNS و برنامهٔ شما بستگی دارد. TTL کوتاه، تکمیل هم‌زمان تغییر در همهٔ شبکه‌ها را تضمین نمی‌کند؛ توضیح TTL در مستندات Cloudflare نیز به نقش کش اشاره دارد.

ترتیب توقف نوشتن و انتقال نسخه نهایی

برای انتقال نهایی، این ترتیب را اجرا کنید:

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

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

پس از توقف کامل نویسنده‌ها، خروجی نهایی دیتابیس و تغییرات فایل‌ها، به‌ویژه uploads، را منتقل کنید. نسخهٔ اولیه برای انتشار کافی نیست.

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

آخرین سفارش، رکورد فرم و فایل‌های تازه را با مبدأ مقایسه کنید و آزمون کوتاه مقصد را تکرار کنید. تعداد جدول‌ها یا اندازهٔ فایل SQL به‌تنهایی معیار صحت نیست.

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

۶. DNS و مسیر CDN را تغییر دهید؛ فقط یک نسخه داده ثبت کند

رکوردهای مربوط به وب‌سایت را به مقصد تغییر دهید. اگر AAAA فعال است، مسیر IPv6 را هم بررسی کنید؛ تغییر A به‌تنهایی می‌تواند بخشی از کاربران را روی مبدأ نگه دارد. در سایت دارای CDN، ممکن است لازم باشد IP مبدأ در تنظیمات CDN تغییر کند. رکوردهای ایمیل مانند MX و TXT را بی‌دلیل دست‌کاری نکنید؛ انتقال سایت لزوماً انتقال ایمیل نیست. برای مرور نقش این رکوردها، راهنمای DNS ابر آراد را ببینید.

مقصد را تنها محل ثبت دادهٔ واقعی قرار دهید. مبدأ نباید پس از تغییر مسیر، دوباره سفارش یا فرم را در دیتابیس قدیمی ثبت کند. برخی کاربران هنوز از کش قبلی به آن می‌رسند؛ برای آن‌ها پاسخ موقتِ مناسب با وضعیت انتقال در نظر بگیرید.

اگر تیم فنی انتقال درخواست‌ها از مبدأ به مقصد را طراحی می‌کند، اتصال باید به مقصد ثابت و آزموده‌شده باشد و نام دامنه و HTTPS را درست حفظ کند؛ ارجاع ساده به همان دامنه ممکن است مشکل کش را حل نکند یا حلقه بسازد.

مبدأ را بلافاصله حذف نکنید. لاگ‌های هر دو سرور، رسیدن درخواست‌ها و وضعیت سرویس‌های بیرونی را بررسی کنید؛ نگه‌داشتن مبدأ تا کاهش ترافیک باقی‌مانده فرصت رسیدگی به خطا را فراهم می‌کند. یک عدد ثابت مانند «چند ساعت» برای همهٔ سایت‌ها معیار قابل اتکایی نیست.

۷. برنامهٔ بازگشت را قبل از شروع بنویسید

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

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

۸. چه زمانی انتقال را تمام‌شده بدانیم؟

پس از تغییر مسیر، فقط صفحهٔ اصلی را بررسی نکنید. HTTPS، ورود، پیوندها، فرم‌ها، رسانه‌ها، سفارش‌ها و بازگشت پرداخت را از مسیر عمومی آزمایش کنید. ارسال ایمیل را نیز با پیام واقعیِ کنترل‌شده بررسی کنید؛ در صورت نیاز، راهنمای تنظیم SMTP وردپرس را بخوانید.

کرون و پردازشگرهای لازم را فقط در مقصد فعال کنید و وضعیت آزمون یا محدودیت موقت مقصد را بردارید. نسخهٔ پشتیبان خودکار مقصد را تنظیم و بازیابی آن را بررسی کنید. آرشیوهای انتقال را از مسیر عمومی حذف کنید و نسخهٔ امن موردنیاز را طبق برنامهٔ نگهداری حفظ کنید.

اگر دامنه و مسیر صفحه‌ها ثابت مانده‌اند، انتقال سرور به‌خودی‌خود به ریدایرکت نشانی‌ها نیاز ندارد. canonical، robots و تنظیمات جلوگیری از ایندکس نسخهٔ آزمایشی را کنترل کنید تا محدودیت آزمون وارد سایت اصلی نشود. راهنمای گوگل برای تغییر میزبانی بدون تغییر URL نیز بر آزمون مقصد و پایش بعد از انتقال تاکید دارد؛ این کار تضمین حفظ رتبه نیست.

انتقال زمانی قابل تایید است که داده‌های آخرین لحظه حفظ شده باشند، فقط مقصد دادهٔ تازه ثبت کند و مسیرهای اصلی سایت از بیرون درست کار کنند. تاریخ حذف مبدأ را پس از این بررسی‌ها تعیین کنید، نه صرفاً پس از ذخیرهٔ رکورد DNS.

اگر مقصد انتقال شما سرور مجازی است، منابع موردنیاز، روش مدیریت سرور و مسئولیت انتقال را پیش از خرید مشخص کنید. سرویس سرور مجازی ابر آراد را بررسی کنید و برای روشن‌شدن نیاز زیرساختی و محدودهٔ خدمات، از مسیر پشتیبانی ابر آراد کمک بگیرید. اجرای انتقال وردپرس و آزمون داده‌ها را به‌عنوان کاری مشخص در برنامهٔ خود قرار دهید؛ صرف تهیهٔ سرور، انجام این مراحل را تضمین نمی‌کند.

چک‌لیست انتقال وردپرس به سرور جدید