آموزش گام‌به‌گام انتقال هاست بدون قطعی

این مقاله یک نوع خاص از مهاجرت را می‌بیند: جابه‌جایی هاست با همان دامنه و همان آدرس‌ها — بدون ریدایرکت و نگاشت ۳۰۱. اگر دامنه یا ساختار آدرس‌ها هم عوض می‌شود، پروژهٔ شما کلان‌تر است و نقشهٔ کاملش در نقشهٔ مهاجرت سایت با تغییر آدرس‌ها آمده؛ آن مقاله ستون‌های نگاشت و پایش بلندمدت سئو را باز می‌کند. موضوع این متن کوچک‌تر است: سوییچِ بی‌درنگ بین دو سرور.

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

انتقال هاست بدون قطعی چرا به ترتیب کارها بستگی دارد؟

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

قطعی‌های واقعی تقریباً همیشه از سه الگو می‌آیند: سوییچ قبل از تست کامل، TTL بلندی که تغییر را دیر اعمال می‌کند، و حذف هاست قدیمی در روز سوییچ که راه بازگشت را می‌بندد. به تجربهٔ ما ترتیبِ «کپی، تست، سوییچ، پایش» هر سه را حذف می‌کند، چون هیچ گامی پیش از تکمیل گام قبلی شروع نمی‌شود و هاست قدیمی تا پایان پایش زنده می‌ماند.

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

هفت گام انتقال در یک نگاه

هفت گام به هم وصل‌اند: بکاپ کامل از هاست فعلی، بازگردانی پیش‌نویس روی هاست جدید، هم‌تراز‌کردن نسخهٔ PHP و SSL، تست با فایل hosts یا دامنهٔ موقت، تنزل TTL، سوییچ رکورد A با پاک‌سازی کش، و پایش ۴۸ ساعت با آماده‌باش بازگشت. هر گام پیش‌نیاز گام بعدی است؛ از گامی پریدن یعنی تستِ گام بعدی معتبر نیست. نقش‌ها هم همین‌جا روشن می‌شود: چه کسی بکاپ را می‌گیرد، چه کسی تست را اجرا می‌کند و چه کسی مجاز است رکورد را تغییر دهد؛ در تیم‌های کوچک هر سه نقش یک نفر است، اما هر سه باید اسم داشته باشند.

زمان‌بندی به حجم سایت بستگی دارد، اما برای یک وردپرس معمولی به تجربهٔ ما این‌طوری می‌شود: بکاپ و بازگردانی یک روز، تست یک روز، تنزل TTL چهار تا شش ساعت قبل، سوییچ در ساعت کم‌ترافیک و پایش دو روزه. عجله گران‌ترین قیمت این پروژه است؛ فاصلهٔ «دو روز» تا «همین امروز» همان قطعی است که نمی‌خواهید بخرید.

پیش‌نویس روی هاست جدید؛ انتقال فایل و دیتابیس

برای وردپرس مسیر استاندارد حساب‌شده‌ای هست، چون حدود ۴۳٪ سایت‌های دنیا با همین سیستم کار می‌کنند (W3Techs، تاریخ گردآوری: آبان ۱۴۰۵) و مهاجرتش جاافتاده است. سه بسته منتقل می‌شود: کل پوشهٔ فایل‌ها (قالب، افزونه‌ها، آپلودها)، خروجی کامل دیتابیس، و wp-config که با مشخصات دیتابیس هاست جدید بازنویسی می‌شود. بکاپ قبل از هر دست‌کاری، هم روی هاست فعلی و هم بیرون از هر دو هاست.

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

هم‌تراز‌کردن PHP خودش رویهٔ امن می‌خواهد؛ اگر نسخهٔ هاست جدید بالاتر است، اول مسیر رویهٔ امن به‌روزرسانی PHP وردپرس را روی کپی اجرا کنید — بکاپ، چک سازگاری، تست — بعد سراغ سوییچ بروید. دو پروژهٔ تغییر را در یک روز جمع نکنید.

تست پیش از سوییچ؛ فایل hosts و دامنهٔ موقت

سؤال کلیدی: چطور سایتی را تست کنیم که هنوز آدرس ندارد؟ دو راه جاافتاده هست. اول، فایل hosts روی سیستم خودتان: دامنه را به IP هاست جدید می‌بندید تا فقط برای همان سیستم، دامنه به سرور جدید برود؛ بقیهٔ دنیا هنوز سرور قدیمی را می‌بینند. دوم، دامنهٔ موقت: زیردامنهٔ آزمایشی روی هاست جدید. راه اول معتبرتر است، چون آدرس‌های واقعی سایت تست می‌شوند.

با دامنهٔ موقت یک دام هست: آدرس وردپرس را برای تست عوض نکنید و بعد از تست جا نگذارید؛ سوییچ با آدرسِ اشتباه همان قطعی است که از آن فرار می‌کنیم. تست با hosts این ریسک را ندارد، چون آدرس‌ها از اول واقعی‌اند؛ فقط بعد از سوییچ آن خط را بردارید تا تست‌های بعدی گمراه نشوند.

سناریوی تست مکتوب باشد: صفحات کلیدی، ارسال فرم، ورود و خروج کاربر، چرخهٔ خرید با درگاه تستی، لینک‌های داخلی و قفل سبز SSL. تستی که فهرست ندارد به «نگاهی انداختیم» تبدیل می‌شود؛ و نگاه، قطعی را نمی‌گیرد.

تنزل TTL و سوییچ DNS؛ لحظه‌ای که نباید قطع شود

TTL مدت کش‌شدن رکورد DNS است: تا وقتی TTL رکورد A مثلاً یک روز است، بخشی از کاربرها تا یک روز بعد از سوییچ هنوز آدرس قدیمی می‌گیرند — و اگر هاست قدیمی بسته باشد، همان‌جا قطعی می‌شود. راه‌حل زمانی است: چند ساعت قبل از سوییچ TTL را به حدود ۳۰۰ ثانیه (پنج دقیقه) پایین بیاورید تا تغییر در چند دقیقه به کل شبکه اعمال شود؛ بعد از ۴۸ ساعت پایش به مقدار عادی برگردانید.

خود سوییچ یک عمل کوچک است: تغییر رکورد A (و AAAA اگر دارید) به IP جدید، در ساعت کم‌ترافیک، همراه با پاک‌سازی کش سرور و CDN. هاست قدیمی در همین لحظه دست‌نخورده و روشن می‌ماند؛ نه خاموش، نه حذف. حذفِ زودهنگام تنها خطای این مسیر است که بازگشت ندارد.

مرز ایمیل را هم بگوییم: این راهنما رکورد A را سوییچ می‌کند، نه MX. اگر صندوق ایمیل روی هاست قدیمی است با سوییچ سایت خراب نمی‌شود، اما هاست قدیمی تا انتقال ایمیل باید زنده بماند و تغییر MX پروژهٔ جدا با پایش خودش است.

پایش ۴۸ ساعت؛ سنجه‌ها و بازگشت به عقب

پنجرهٔ ۴۸ ساعت پایش را نیمهٔ دوم پروژه ببینید. سنجه‌ها از قبل تعریف می‌شوند: پایش بیرونی آپ‌تایم از چند نقطه، خطاهای ۵xx در لاگ‌ها، ارسال فرم‌ها و چرخهٔ خرید، و مقایسهٔ ترافیک با دورهٔ مشابه پیش از سوییچ. خطای DNS-محور سبک خاصی دارد: گزارش‌های پراکنده از کاربرهایی که هنوز رکورد قدیمی می‌گیرند؛ با TTL کوتاه در چند ساعت تمام می‌شود.

بازگشت به عقب شرط دارد و شرطش را روز اول آماده می‌کنید: هاست قدیمی زنده، دیتای آن از لحظهٔ سوییچ یخ‌زده و بکاپ دوم ثبت‌شده. تا این شرایط برقرار است، بازگشت فقط برگرداندن رکورد A به IP قبلی است که با TTL کوتاه چند دقیقه اعمال می‌شود. پرسش کلیدی: اگر برگردیم، سفارش‌ها و فرم‌های این چند ساعت کجا رفته‌اند؟ پاسخش مرز واقعی بازگشت است، نه ترس از سوییچ.

بعد از ۴۸ ساعت بدون خطا: TTL به مقدار عادی برمی‌گردد، بکاپ دوم از هاست جدید گرفته می‌شود و هاست قدیمی وارد دورهٔ حوصله‌مندی می‌شود؛ به تجربهٔ ما چند هفته نگه داشتنش بی‌ضرر است، چون هزینه‌اش مشخص و کم است و ریسک حذفِ زودهنگام گران.

سه خطای رایجی که مهاجرت را قطعی می‌کند

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

دو خطای ریزتر: جابه‌جایی‌نکردن کرون‌جاب‌ها که روی هاست قدیمی بی‌صدا کار می‌کردند، و فراموش‌کردن کلیدهای سرویس‌های جانبی — درگاه، پیامک، آنالیتیکس — که به تنظیمات سرور قدیمی وصل‌اند. هر دو با یک مرور چک‌لیست پیش از سوییچ گرفته می‌شوند.

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

رصد ما، رشد شما.