انتقال وردپرس به VPS با حداقل قطعی؛ از آماده‌سازی سرور تا Cutover

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

پاسخ سریع: ابتدا VPS را امن و سازگار آماده کنید، وب‌سرور، PHP، دیتابیس، TLS، Cron، ایمیل، Backup و Monitoring را بسازید و سپس کپی اولیه فایل و دیتابیس را انجام دهید. مقصد را با hostname واقعی و بدون تغییر DNS عمومی آزمایش کنید. در Cutover کنترل‌شده، نوشتن روی سایت قدیمی را متوقف، دیتابیس و فایل‌های متغیر را برای آخرین بار همگام، ترافیک را منتقل و هر دو مبدأ را تا پایان TTL مانیتور کنید.

حداقل قطعی با Zero Downtime یکسان نیست

برای یک وردپرس تک‌دیتابیسی، maintenance window کوتاه اغلب امن‌ترین راه است. Zero Downtime فقط با TTL پایین حاصل نمی‌شود؛ دو مبدأ باید session، upload، cache، cron و نوشتن دیتابیس را هماهنگ مدیریت کنند. در غیر این صورت سفارش و حساب کاربر میان دو دیتابیس تقسیم می‌شود.

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

مطمئن شوید VPS مسئله واقعی را حل می‌کند

VPS کنترل CPU، RAM، سیستم‌عامل، وب‌سرور، PHP Worker، دیتابیس و سیاست شبکه را می‌دهد، اما مسئولیت patch، دسترسی، ظرفیت، Backup و Incident را هم اضافه می‌کند. Query کند، افزونه ناامن یا Queue بدون سقف با انتقال خودبه‌خود اصلاح نمی‌شود.

پیش از مهاجرت، محدودیت فعلی را با شواهد ثبت کنید: throttling منابع، کمبود extension، رشد ترافیک، محدودیت deployment یا نیاز به تنظیم سرور. هدف قابل‌اندازه‌گیری از فرض «VPS همیشه سریع‌تر است» مفیدتر است.

معماری مقصد را پیش از خرید مشخص کنید

تصمیم بگیرید دیتابیس روی همان VPS است یا سرویس مدیریت‌شده، رسانه روی Disk محلی می‌ماند یا storage جدا و آیا CDN یا reverse proxy در جلو قرار دارد. یک VPS واحد برای وب، دیتابیس، Cache و Backup همه لایه‌ها را در یک failure domain قرار می‌دهد.

منابع را از روی ترافیک، concurrency و workload واقعی انتخاب کنید، نه تعداد صفحات. برای warm-up Cache، فشرده‌سازی Backup، جهش ترافیک و نگهداری دیتابیس headroom بگذارید.

Baseline امن سرور را بسازید

از سیستم‌عامل پشتیبانی‌شده شروع کنید و به‌روزرسانی امنیتی را اعمال کنید. حساب مدیریتی نام‌دار، SSH key، دسترسی privileged محدود، Firewall میزبان یا Provider، همگام‌سازی زمان و مسیر Recovery Console را پیش از محدودکردن SSH آماده کنید.

تا زمانی که ورود جایگزین در session دوم آزموده نشده، تنها روش ورود فعال را نبندید. چک‌لیست کانفیگ اولیه سرور و راهنمای امن‌سازی SSH این مراحل را با جزئیات پوشش می‌دهند.

Runtime سازگار وردپرس را نصب کنید

مقصد به وب‌سرور، PHP و extensionهای لازم و MySQL یا MariaDB سازگار نیاز دارد. راهنمای رسمی پیکربندی سرور WordPress وب‌سرور، permission، دیتابیس، ایمیل و routing دامنه را اجزای مستقل محیط معرفی می‌کند.

ابتدا رفتار Production را بازسازی کنید. ارتقای major PHP، تغییر engine دیتابیس و مهاجرت هم‌زمان، چند علت احتمالی برای هر خطا می‌سازد. مگر آنکه Runtime قبلی قابل‌استفاده امن نباشد، ارتقا را پس از تثبیت انتقال انجام دهید.

Permission را بدون Writable کردن همه‌چیز تنظیم کنید

کاربر deployment، وب‌سرور و PHP ممکن است مسئولیت متفاوت داشته باشند. Runtime فقط باید روی مسیرهای لازم مانند upload یا cache کنترل‌شده دسترسی نوشتن داشته باشد. از chmod 777 به‌عنوان راه‌حل انتقال استفاده نکنید.

پس از کپی مالکیت فایل‌ها را کنترل کنید. ممکن است سایت نمایش داده شود اما upload، update افزونه، purge cache یا ثبت log به‌علت permission اشتباه شکست بخورد.

دیتابیس، Cron، ایمیل، Cache و TLS را آماده کنید

• دیتابیس و کاربر اختصاصی با حداقل دسترسی لازم بسازید.
• اگر سایت به Cron واقعی وابسته است، آن را با زمان‌بندی مشخص تعریف کنید.
• مسیر SMTP یا Relay و سیاست Provider را بررسی کنید.
• Page Cache و Object Cache را آگاهانه بسازید و Cache قدیمی را کپی نکنید.
• صدور و تمدید TLS را برای hostname نهایی آماده کنید.
• Monitoring را پیش از Cutover فعال کنید، نه پس از اولین قطعی.

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

ابتدا Backup قابل‌بازیابی بسازید. فایل‌های ثابت و کم‌تغییر را به VPS کپی و یک snapshot اولیه از دیتابیس import کنید. برای uploads بزرگ، ابزار incremental مانند rsync می‌تواند زمان همگام‌سازی نهایی را کم کند.

rsync -aH --dry-run --itemize-changes /SOURCE/ USER@VPS:/DESTINATION/
rsync -aH /SOURCE/ USER@VPS:/DESTINATION/

مسیرها و حساب‌ها placeholder هستند. هر دو مقصد را کنترل و ابتدا خروجی dry run را بخوانید. Archive mode چند attribute را حفظ می‌کند، اما حفظ ownership باید با طراحی مقصد هماهنگ باشد. این نمونه عمداً گزینه حذف فایل ندارد.

دیتابیس را با scope روشن منتقل کنید

WP-CLI عملیات دیتابیس را با credential موجود در wp-config.php اجرا می‌کند. مرجع رسمی فرمان‌های دیتابیس WP-CLI export، import، check و size را پوشش می‌دهد. فرمان را از root درست وردپرس اجرا و dump را خارج از مسیر عمومی وب نگهداری کنید.

رمز دیتابیس را در command history مشترک قرار ندهید. پس از import تعداد جدول‌ها، خطاها و عملیات read/write وردپرس را بررسی کنید. اگر دامنه عمومی ثابت است، انتقال سرور نیازمند Search-Replace سراسری URL نیست.

VPS را پیش از تغییر DNS تست کنید

روی سیستم آزمون مجاز، hostname واقعی را موقتاً به IP جدید map کنید. hostname برای انتخاب Virtual Host، Cookie، Redirect، CORS و TLS مهم است؛ آزمون با IP خام همه این رفتارها را نشان نمی‌دهد.

صفحات، ورود، رسانه، جست‌وجو، REST API، loopback، Cron، ایمیل، Cache و مسیر اصلی کسب‌وکار را تست کنید. برای ووکامرس از sandbox استفاده کنید و اجازه ندهید نسخه آزمایشی webhook یا ایمیل واقعی بفرستد.

ظرفیت VPS را با بار نماینده بسنجید

پاسخ موفق یک درخواست، ظرفیت Production را ثابت نمی‌کند. هنگام آزمون مسیرهای cached و dynamic، صف PHP-FPM، latency دیتابیس، CPU، memory pressure، Disk I/O و نرخ خطا را ببینید. تست نباید سفارش واقعی بسازد یا مبدأ قبلی را تحت فشار قرار دهد.

Worker و connection limit را از روی مصرف حافظه و concurrency تعیین کنید. بالا بردن همه سقف‌ها ممکن است مشکل صف را به OOM تبدیل کند.

DNS و Runbook انتقال را آماده کنید

TTL رکوردهای مرتبط را حداقل به‌اندازه TTL قبلی پیش از انتقال کاهش دهید. مقادیر فعلی A، AAAA، مبدأ CDN و Rollback را ثبت کنید. مسئول شروع maintenance، تغییر ترافیک، آزمون‌های پذیرش و شرط بازگشت باید روشن باشد.

چک‌لیست انتقال وردپرس به هاست جدید توضیح می‌دهد چرا مبدأ قدیمی باید تا عبور پاسخ‌های DNS cache‌شده فعال بماند.

همگام‌سازی نهایی را اجرا کنید

1. سایت قدیمی را وارد maintenance یا حالت read-only کنترل‌شده کنید.
2. Cron، Worker، ایمیل و Webhookهایی را که ممکن است دوبار اجرا شوند متوقف کنید.
3. آخرین دیتابیس را export و روی VPS import کنید.
4. Upload و سایر فایل‌های متغیر تازه را همگام کنید.
5. Config، ownership، Cache و سلامت برنامه را دوباره بسنجید.
6. پردازش Production را فقط روی مبدأ منتخب فعال کنید.

زمان آخرین نوشتن موفق روی سیستم قدیمی را ثبت کنید؛ این زمان مرز داده برای Verification و Rollback است.

ترافیک را منتقل و هر دو مبدأ را مانیتور کنید

رکورد DNS یا Origin در CDN را با توجه به IPv6 تغییر دهید. گواهی عمومی، status code، canonical و پاسخ چند resolver یا شبکه را کنترل کنید. Access log دو سیستم نشان می‌دهد کاربران واقعی به کدام مقصد می‌رسند.

Availability از دید کاربر را کنار CPU، RAM، Disk، PHP-FPM، دیتابیس و Queue مانیتور کنید. راهنمای مانیتورینگ سرور سیگنال‌های ضروری را مشخص می‌کند.

Rollback را بر اساس داده تعریف کنید

بازگرداندن DNS فقط پیش از پذیرش write تازه روی VPS ساده است. پس از ثبت سفارش، upload یا حساب جدید، دیتابیس قدیمی stale است. برنامه بازگشت باید روش reconciliation داده و مسئول تصمیم میان rollback و fix forward را مشخص کند.

هاست قدیمی را بدون write تا پایان دوره مشاهده نگه دارید و صرف پاسخ‌دادن صفحه اصلی آن را حذف نکنید.

عملیات پس از مهاجرت

• Backup خودکار و Restore Test مستقل را تأیید کنید.
• مسئول Update سیستم‌عامل، PHP، دیتابیس و WordPress را مشخص کنید.
• تمدید TLS، هشدار Disk، uptime check بیرونی و log rotation را تست کنید.
• Firewall، portهای listening و حساب‌های مدیریتی را مرور کنید.
• پس از تثبیت، TTL را به مقدار عملیاتی برگردانید.
• مبدأ قبلی را فقط پس از پایان نیاز retention و rollback حذف کنید.

اشتباه‌های رایج انتقال به VPS

• دیدن VPS به‌عنوان هاست اشتراکی سریع‌تر
• تغییر هم‌زمان PHP، دیتابیس و وب‌سرور
• کپی Cache و Session قدیمی
• اجرای Cron، ایمیل یا Callback پرداخت روی هر دو مبدأ
• پنهان‌کردن مشکل ownership با permission گسترده
• تغییر DNS پیش از آزمون hostname نهایی
• نگهداری Backup فقط روی همان VPS
• برنامه‌ریزی Rollback DNS بدون reconciliation داده

چه زمانی مهاجرت مدیریت‌شده مناسب است؟

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

پرسش‌های متداول

آیا وردپرس روی VPS کوچک اجرا می‌شود؟

بله، اما اندازه مناسب به ترافیک dynamic، concurrency در PHP، بار دیتابیس، رفتار Cache و headroom عملیاتی وابسته است؛ نه صرفاً تعداد صفحات.

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

اگر دامنه، scheme و path عمومی ثابت‌اند، خیر. تغییر IP یا سرور به‌تنهایی نیازمند Search-Replace نیست.

آیا هر دو سرور می‌توانند هنگام انتشار DNS فعال باشند؟

برای read ممکن است، اما write مستقل بدون داده مشترک یا replication امن نیست. مرز کنترل‌شده نوشتن ضروری است.

دیتابیس روی همان VPS باشد؟

برای workload متوسط ممکن است منطقی باشد، اما رقابت منابع و failure domain را ترکیب می‌کند. تصمیم به ظرفیت، بازیابی و توان عملیاتی بستگی دارد.