مهاجرت وردپرس به سرور جدید؛ انتقال امن فایل، دیتابیس و DNS

مهاجرت یک تغییر زیرساختی است

انتقال وردپرس به سرور جدید فقط کپی پوشه public_html نیست. فایل‌ها، دیتابیس، نسخه PHP، افزونه‌ها، زمان‌بندی‌ها، ایمیل، گواهی SSL، تنظیمات وب‌سرور و سرویس‌های بیرونی ممکن است در اجرای سایت نقش داشته باشند. اگر یکی از این اجزا فراموش شود، سایت ممکن است باز شود اما فرم، پرداخت یا ارسال ایمیل کار نکند. برنامه مهاجرت باید وابستگی‌ها و معیار پذیرش را پیش از تغییر DNS مشخص کند.

تهیه فهرست دارایی‌ها

ابتدا نسخه وردپرس، PHP، دیتابیس، وب‌سرور، قالب، افزونه‌ها، حجم فایل و دیتابیس و مسیرهای سفارشی ثبت شوند. cron، SMTP، درگاه پرداخت، CDN، DNS و اتصال‌های API نیز بررسی شوند. برخی افزونه‌ها فایل یا داده خارج از مسیر معمول وردپرس نگهداری می‌کنند. فهرست دارایی‌ها مانع می‌شود انتقال فقط بر اساس پوشه اصلی انجام شود و سرویس جانبی پس از جابه‌جایی از کار بیفتد.

انتخاب زمان مهاجرت

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

آماده‌سازی سرور مقصد

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

پشتیبان‌گیری کامل

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

انتقال فایل‌ها

فایل‌های وردپرس، uploads، قالب، افزونه و فایل‌های سفارشی منتقل شوند. انتقال باید با ابزار قابل اعتماد و همراه بررسی خطا انجام شود. تعداد و حجم فایل‌ها و در صورت امکان checksum مقایسه شوند. فایل‌های cache و موقت ممکن است قابل بازسازی باشند، اما حذف آن‌ها باید با شناخت وابستگی انجام شود. مسیرهای خارج از webroot و فایل‌های پشتیبان نیز در صورت نیاز جداگانه منتقل شوند.

انتقال دیتابیس

از دیتابیس dump سازگار تهیه و در مقصد import شود. charset، collation، نسخه موتور و حجم داده بررسی شوند. import ناقص یا قطع‌شده ممکن است جداولی را جا بگذارد و خطا فقط در بخش خاصی از سایت ظاهر شود. تعداد جدول‌ها و رکوردهای مهم با مبدأ مقایسه شوند. در سایت پویا، داده‌های جدید پس از backup اولیه باید در مرحله نهایی همگام‌سازی شوند.

تنظیم اتصال دیتابیس

اطلاعات DB_NAME، DB_USER، DB_PASSWORD و DB_HOST در تنظیمات مقصد با حسابی دارای حداقل مجوز لازم وارد شوند. استفاده از حساب root مناسب نیست. اتصال باید از همان محیط PHP آزمایش شود. رمز دیتابیس در log یا فایل قابل دانلود قرار نگیرد. پس از مهاجرت، credentialهای قدیمی در صورت عدم نیاز لغو شوند تا دسترسی غیرضروری باقی نماند.

تغییر URL و آدرس سایت

اگر دامنه تغییر می‌کند، مقدار siteurl و home و ارجاع‌های ذخیره‌شده باید بررسی شوند. جست‌وجو و جایگزینی مستقیم در دیتابیس ممکن است داده‌های serialize شده را خراب کند. از ابزار سازگار با ساختار وردپرس استفاده و قبل از تغییر backup تهیه شود. آدرس‌های قدیمی در محتوای صفحه، تنظیمات افزونه و فایل‌های CSS نیز ممکن است باقی مانده باشند.

DNS و TTL

پیش از تغییر رکوردها، مقدار فعلی A، AAAA، CNAME، MX و TXT ثبت شود. TTL پایین‌تر می‌تواند زمان همگرایی را کاهش دهد، اما تغییر آن باید از قبل انجام شده باشد. همه رکوردها فقط به وب‌سایت مربوط نیستند؛ تغییر اشتباه MX یا SPF ممکن است ایمیل سازمان را مختل کند. مقصد جدید باید پیش از تغییر DNS با فایل hosts یا دامنه آزمایشی بررسی شود.

آزمون با دامنه موقت

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

گواهی SSL و HTTPS

گواهی دامنه باید روی سرور جدید صادر یا منتقل و زنجیره آن معتبر باشد. تمدید خودکار و دسترسی سرویس به فایل‌های گواهی بررسی شوند. پس از فعال‌سازی HTTPS، redirect و محتوای mixed content آزمایش شود. گواهی منقضی یا نام دامنه ناهماهنگ می‌تواند دسترسی مرورگر و API را مختل کند. اعتبارسنجی TLS را برای رفع موقت خطا خاموش نکنید.

تنظیم وب‌سرور و PHP

قواعد rewrite، محدودیت آپلود، timeout، memory limit و مسیرهای fastcgi باید با سایت سازگار باشند. تنظیمات مبدأ را بدون بررسی کپی نکنید؛ ممکن است شامل مسیر یا نسخه نامعتبر باشند. فایل .htaccess یا پیکربندی Nginx باید با ساختار مقصد هماهنگ شود. پس از reload، log وب‌سرور و PHP بررسی و خطاهای ۴۰۴ یا ۵۰۰ در مسیرهای مهم آزمون شوند.

Cron و وظایف زمان‌بندی‌شده

وظایف زمان‌بندی‌شده وردپرس ممکن است با بازدید کاربران اجرا شوند یا از cron سیستم استفاده کنند. پس از انتقال، زمان‌بندی‌ها و مسیر اجرای PHP بررسی شوند. اجرای هم‌زمان cron قدیمی و جدید می‌تواند پیام یا کار تکراری ایجاد کند. پس از تأیید مقصد، وظایف مبدأ غیرفعال شوند. زمان آخرین اجرای موفق و خروجی jobهای مهم ثبت گردد.

ایمیل و ارسال پیام

تنظیمات SMTP، SPF، DKIM و DMARC ممکن است به IP یا سرویس مبدأ وابسته باشند. پس از انتقال، ایمیل آزمایشی به چند سرویس مقصد ارسال و سربرگ‌ها بررسی شوند. پیامک و webhook نیز باید از سرور جدید تست شوند. بازبودن پورت خروجی یا مجازبودن IP جدید نزد ارائه‌دهنده ضروری است. ارسال موفق از محیط توسعه تضمین نمی‌کند سرور تولید نیز مجاز باشد.

درگاه پرداخت و callback

درگاه پرداخت ممکن است IP، دامنه callback یا گواهی مقصد را بررسی کند. نشانی بازگشت باید با دامنه نهایی هماهنگ باشد و endpoint از بیرون قابل دسترس باشد. پرداخت آزمایشی یا مبلغ کنترل‌شده انجام و نتیجه در backend تأیید شود. بازگشت مرورگر به صفحه موفقیت به‌تنهایی اثبات پرداخت نیست. پس از تغییر IP، محدودیت‌های سمت ارائه‌دهنده نیز بازبینی شوند.

افزونه‌های وابسته به IP

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

همگام‌سازی نهایی داده

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

تغییر DNS و کنترل انتشار

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

پایش پس از مهاجرت

پس از تغییر، خطای HTTP، زمان پاسخ، مصرف منابع، خطای PHP، ارسال ایمیل، callback پرداخت و نرخ خطا پایش شوند. مانیتورینگ صرف صفحه اصلی کافی نیست. آزمون‌های تراکنشی و فرم باید تکرار شوند. افزایش ناگهانی ۴۰۴ ممکن است نشانه باقی‌ماندن URL قدیمی باشد. وضعیت DNS از چند resolver و منطقه بررسی شود تا مشکل محدود به یک شبکه اشتباه تفسیر نشود.

برنامه بازگشت

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

امنیت پس از انتقال

پس از مهاجرت، حساب‌های موقت، کلیدهای انتقال و دسترسی‌های بازشده برای عملیات باید حذف یا محدود شوند. مجوز فایل، تنظیمات دیتابیس، firewall و backup مقصد بازبینی شوند. فایل‌های dump و آرشیو ممکن است حاوی اطلاعات حساس باشند و نباید در webroot باقی بمانند. نسخه نرم‌افزار و افزونه‌ها نیز پس از تثبیت در برنامه به‌روزرسانی قرار گیرند.

مستندسازی و تحویل

گزارش مهاجرت باید زمان تغییر DNS، نسخه‌ها، مسیرهای مهم، سرویس‌های منتقل‌شده، آزمون‌ها و موارد باز را ثبت کند. اطلاعات دسترسی در محل امن تحویل داده شود، نه در متن عمومی گزارش. مسئول نگهداری سرور جدید و مسیر escalation مشخص باشند. مستندات باید به‌گونه‌ای باشند که تیم دیگر بتواند وضعیت را بفهمد و در رخداد بعدی به وابستگی‌های ناشناخته متکی نباشد.

جمع‌بندی

مهاجرت امن وردپرس با فهرست وابستگی‌ها و backup معتبر آغاز می‌شود و با انتقال فایل و دیتابیس، تنظیم سرور، DNS، SSL و آزمون کامل ادامه می‌یابد. سرویس‌های جانبی مانند ایمیل، پیامک و پرداخت باید جداگانه بررسی شوند. برای سایت پویا، همگام‌سازی داده و برنامه بازگشت حیاتی‌اند. مبدأ تا پایان دوره پایش نگهداری شود و موفقیت انتقال بر اساس عملکرد واقعی کسب‌وکار تأیید گردد.