مهاجرت سرور اختصاصی بدون قطعی؛ نقشه راه گام‌به‌گام انتقال از VPS

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

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

فرمول یک جابه‌جایی موفق: برنامه‌ریزی + همگام‌سازی + آزمون پیش از تغییر DNS. سرور قدیم را هم تا وقتی ترافیکش به صفر نرسیده خاموش نکنید.

مهاجرت سرور اختصاصی چیست و چه زمانی ضرورت پیدا می‌کند؟

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

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

علائمی که نشان می‌دهد وقت مهاجرت رسیده است

• اشغال دائمی منابع: در ساعات پرترافیک، پردازنده یا حافظه بیشتر اوقات نزدیک به حداکثر ظرفیت کار می‌کند.
• انتظار طولانی دیسک: مقدار بالای iowait نشانهٔ آن است که دیسک اشتراکی به گلوگاه سیستم تبدیل شده است.
• نیاز به سخت‌افزار ویژه: حافظهٔ زیاد، دیسک NVMe اختصاصی یا پورت شبکهٔ پرسرعت لازم دارید.
• الزامات امنیتی و انطباق: باید تضمین کنید سخت‌افزار با هیچ مشتری دیگری مشترک نیست.
• مجازی‌سازی اختصاصی: قصد دارید خودتان چند ماشین مجازی را روی یک سرور فیزیکی بسازید و مدیریت کنید.

تمرکز این مقاله روی «چگونگی» انجام کار است؛ یعنی فرض می‌کنیم تصمیم مهاجرت گرفته شده و حالا به یک روش مطمئن و قابل تکرار برای اجرای آن نیاز دارید.

TTL چیست و چرا در مهاجرت اهمیت دارد؟

بر اساس RFC 1035، مقدار TTL مشخص می‌کند یک رکورد DNS چه مدت می‌تواند در حافظهٔ موقت سرورهای واسط باقی بماند تا دوباره از منبع اصلی پرسیده شود. اگر TTL رکورد A شما یک روز باشد، بخشی از کاربران ممکن است تا یک روز پس از تغییر همچنان به IP قبلی هدایت شوند.

نتیجهٔ عملی این است که کاهش TTL را باید دست‌کم به اندازهٔ همان TTL قبلی، زودتر از روز جابه‌جایی انجام دهید تا مقدار کوچک جدید در همه‌جا جایگزین شده باشد.

---

چک‌لیست آماده‌سازی پیش از انتقال سرور و کاهش TTL

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

• نسخهٔ پشتیبان کامل و آزموده: از فایل‌ها و دیتابیس بکاپ کامل بگیرید و بازگردانی آن را واقعاً امتحان کنید؛ بکاپی که آزموده نشده قابل اتکا نیست.
• سیاههٔ سرویس‌ها: وب‌سرور، نسخهٔ PHP و ماژول‌های آن، دیتابیس، Redis، کران‌جاب‌ها، سرویس‌های systemd و پورت‌های باز را ثبت کنید.
• فهرست دامنه‌ها و رکوردها: همهٔ رکوردهای A، MX، TXT و CNAME و محل مدیریت DNS هر دامنه را مشخص کنید.
• ظرفیت کافی در مقصد: فضای دیسک باید برای دادهٔ فعلی، بکاپ موقت و رشد آینده جا داشته باشد و حاشیهٔ اطمینان اضافه هم در نظر بگیرید.
• یکسان بودن نسخه‌ها: نسخهٔ سیستم‌عامل، PHP و MySQL یا MariaDB را تا جای ممکن مثل سرور مبدا نگه دارید.
• توقف تغییرات: در روز انتقال، افزونهٔ تازه نصب نکنید و حساب کاربری یا سایت جدید نسازید.

کاهش TTL؛ نخستین قدم برای جابه‌جایی بدون قطعی

راهنمای رسمی Google Search Central برای تغییر میزبانی بدون تغییر نشانی‌ها پیشنهاد می‌کند TTL را دست‌کم یک هفته پیش از جابه‌جایی به مقداری کم و محافظه‌کارانه، مثلاً چند ساعت، برسانید. بسیاری از مدیران سرور در روز آخر این عدد را باز هم کوچک‌تر می‌کنند تا تغییر نهایی سریع‌تر منتشر شود.

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

ریسک‌هایی که باید از ابتدا بشناسید

در دیتابیس‌های پرتراکنش، هیچ روشی بدون یک بازهٔ کوتاه توقف نوشتن، سازگاری کامل داده را تضمین نمی‌کند؛ مگر اینکه تکرار (Replication) راه‌اندازی کنید که پیچیدگی بیشتری به همراه دارد.

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

جدول زمان‌بندی مهاجرت بدون قطعی

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

---

آموزش گام‌به‌گام انتقال فایل، دیتابیس، ایمیل و DNS

در این بخش، فرایند انتقال سایت به سرور اختصاصی را در شش گام پیش می‌بریم. مثال‌ها برای سرور لینوکسی با Nginx یا Apache و پایگاه‌دادهٔ MySQL یا MariaDB نوشته شده‌اند. هر جا NEW_IP دیدید، نشانی سرور جدید را قرار دهید و همهٔ دستورها را ابتدا روی یک نسخهٔ آزمایشی اجرا کنید.

گام ۱: آماده کردن سرور مقصد

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

گام ۲: همگام‌سازی اولیهٔ فایل‌ها با rsync

بر پایهٔ مستندات rsync، گزینهٔ -a معادل -rlptgoD است و لینک‌های سخت، ACL و ویژگی‌های گسترده را پوشش نمی‌دهد؛ به همین دلیل -H، -A و -X را جداگانه اضافه می‌کنیم. گزینهٔ –numeric-ids نیز شناسهٔ کاربر و گروه را بدون تبدیل به نام منتقل می‌کند.

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

گام ۳: انتقال دیتابیس با حفظ سازگاری

طبق مستندات MariaDB، گزینهٔ –single-transaction از جداول InnoDB خروجی سازگار می‌گیرد بی‌آنکه برنامه‌ها را مسدود کند؛ البته این سازگاری فقط برای جداول InnoDB برقرار است. تریگرها به‌صورت پیش‌فرض در خروجی قرار می‌گیرند، اما رویه‌های ذخیره‌شده و رویدادها به گزینه‌های –routines و –events نیاز دارند. ابزار mysqldump در MySQL هم همین گزینه‌ها را دارد.

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

گام ۴: ایمیل، گواهی SSL و کران‌جاب‌ها

اگر ایمیل روی همان VPS میزبانی می‌شود، صندوق‌ها را با ابزار انتقال IMAP یا امکانات کنترل پنل منتقل کنید و رکوردهای MX، SPF و DKIM را برای IP جدید به‌روز کنید. رکورد PTR نشانی جدید را نیز تنظیم کنید تا ایمیل‌های خروجی به پوشهٔ اسپم نروند. کران‌جاب‌ها را هم با crontab -l از سرور قبلی کپی کنید.

دربارهٔ SSL دقت کنید: بر اساس مستندات Let’s Encrypt، در روش HTTP-01 فایل تأیید باید روی وب‌سرور همان دامنه در دسترس باشد. بنابراین تا وقتی DNS به سرور جدید اشاره نکند، این روش روی مقصد کار نمی‌کند. راه ساده، کپی گواهی فعلی و صدور دوباره پس از تغییر DNS است؛ روش DNS-01 هم مستقل از IP سرور عمل می‌کند.

گام ۵: حالت نگهداری و همگام‌سازی پایانی

در ساعتی که ترافیک کمترین مقدار را دارد، سایت را به حالت نگهداری ببرید یا عملیات نوشتن را متوقف کنید. سپس rsync پایانی را همراه با –delete اجرا کنید تا فایل‌های حذف‌شده نیز هماهنگ شوند، و خروجی تازهٔ دیتابیس را روی سرور جدید بازگردانی کنید. چون بیشتر داده در گام دوم جابه‌جا شده، این مرحله معمولاً کوتاه است.

گام ۶: آزمون با فایل hosts و تغییر DNS

پیش از تغییر DNS، دامنه را در فایل hosts رایانهٔ خودتان به NEW_IP اشاره دهید و صفحات، ورود کاربران، فرایند پرداخت و فرم‌ها را روی سرور جدید بیازمایید. اگر همه‌چیز درست بود، رکورد A را تغییر دهید.

Google Search Central توصیه می‌کند زیرساخت قبلی را تا زمانی که ترافیکش به صفر برسد روشن نگه دارید و لاگ هر دو سرور را زیر نظر بگیرید. طبیعی است که پس از جابه‌جایی، نرخ خزش Googlebot برای مدتی کاهش یابد و طی چند روز بعد کم‌کم به حالت عادی برگردد؛ گزارش‌های پوشش ایندکس در Search Console را هم بررسی کنید.

برنامهٔ بازگشت در صورت بروز مشکل

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

به همین دلیل، در هر انتقال سرور مهلت تصمیم‌گیری برای بازگشت را از قبل تعیین کنید؛ برای نمونه یک ساعت پس از تغییر DNS.

---

مقایسهٔ روش‌های انتقال سرور

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

بر اساس مستندات cPanel، ابزار Transfer Tool با دسترسی root حساب‌ها، بسته‌ها و پیکربندی‌ها را از سرور مبدا به مقصد کپی می‌کند. قابلیت Live Transfer آن فقط میان دو سرور cPanel و WHM کار می‌کند و تأکید شده که پیش از حذف حساب از سرور قبلی، DNS باید به‌روز شده باشد.

---

آزمون‌های پس از مهاجرت و یک سناریوی واقعی

تغییر DNS پایان کار نیست. در ۴۸ ساعت نخست، موارد زیر را بررسی کنید تا مشکلات پنهان پیش از آنکه کاربران متوجه شوند شناسایی شوند.

• صفحات اصلی، ورود کاربران، سبد خرید و درگاه پرداخت
• ارسال و دریافت ایمیل و وضعیت رکوردهای SPF، DKIM و PTR
• اجرای کران‌جاب‌ها، صف‌های پردازش و بکاپ خودکار روی سرور جدید
• لاگ خطای وب‌سرور و دیتابیس روی هر دو سرور
• گزارش‌های Search Console و روند نرخ خزش

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

یک سناریوی رایج

فروشگاهی را در نظر بگیرید که روی VPS با کمبود رم و iowait بالا روبه‌روست و مدیرش برای ارتقا به سرور اختصاصی نگران از دست رفتن سفارش‌هاست. در این وضعیت ابتدا TTL کاهش می‌یابد، فایل‌ها چند روز زودتر همگام می‌شوند و در ساعت کم‌ترافیک، فروشگاه چند دقیقه در حالت نگهداری قرار می‌گیرد تا دیتابیس منتقل شود. پس از آزمون با فایل hosts، DNS تغییر می‌کند و سرور قدیم تا اطمینان کامل روشن می‌ماند.

---

پرسش‌های پرتکرار دربارهٔ انتقال سرور

آیا انتقال سایت به سرور اختصاصی واقعاً بدون قطعی شدنی است؟

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

ارتقا از VPS به سرور اختصاصی چقدر طول می‌کشد؟

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

آیا جابه‌جایی سرور به سئو آسیب می‌زند؟

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

در جریان انتقال، ایمیل‌ها چه می‌شوند؟

اگر ایمیل روی سرویس جداگانه‌ای مثل ایمیل سازمانی است، فقط رکوردهای وب تغییر می‌کنند و MX دست‌نخورده می‌ماند. اگر ایمیل روی همان VPS است، صندوق‌ها باید منتقل و رکوردهای MX، SPF و PTR برای IP جدید به‌روز شوند. تا پایان انتشار DNS، سرور قبلی را برای دریافت ایمیل روشن نگه دارید.

آیا نسخهٔ سیستم‌عامل سرور جدید باید با قبلی یکی باشد؟

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

اگر بعد از تغییر DNS مشکلی پیش آمد، چگونه برگردم؟

تا وقتی سرور قدیم روشن است، کافی است رکورد A را به IP قبلی برگردانید؛ با TTL پایین این تغییر سریع دیده می‌شود. داده‌هایی که در این فاصله روی سرور جدید ثبت شده‌اند، مثل سفارش‌ها، باید دستی منتقل شوند؛ پس مهلت تصمیم برای بازگشت را از قبل تعیین کنید.

آیا می‌توان به جای rsync از بکاپ کنترل پنل استفاده کرد؟

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

---

اشتباهات رایج در انتقال سرور و راه پیشگیری از آن‌ها

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

• کاهش دیرهنگام TTL: اگر TTL را همان روز جابه‌جایی کم کنید، مقدار قبلی هنوز در حافظهٔ موقت سرورهای DNS باقی است و بخشی از کاربران مدت‌ها به IP قدیم می‌روند.
• اعتماد به بکاپ آزموده‌نشده: نسخهٔ پشتیبانی که هرگز بازگردانی نشده، ممکن است درست در لحظهٔ نیاز ناقص یا خراب از آب درآید.
• فراموش کردن کارهای زمان‌بندی‌شده: کران‌جاب‌ها، صف‌ها و بکاپ خودکار اگر روی سرور جدید تعریف نشوند، مشکل تا چند روز بعد دیده نمی‌شود.
• اجرای هم‌زمان کران‌جاب روی دو سرور: اگر هر دو سرور هم‌زمان ایمیل بفرستند یا داده را پردازش کنند، کاربران پیام تکراری می‌گیرند یا داده دوبار ثبت می‌شود؛ کارهای زمان‌بندی‌شدهٔ سرور قدیم را پس از تغییر DNS غیرفعال کنید.
• جا ماندن تنظیمات نسخهٔ آزمایشی: تگ noindex یا محدودیت‌های robots.txt محیط تست نباید به سرور اصلی برسد.
• خاموش کردن زودهنگام سرور مبدا: تا وقتی در لاگ سرور قدیم درخواست تازه دیده می‌شود، بخشی از کاربران یا ربات‌ها هنوز به آن مراجعه می‌کنند.

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

---

جمع‌بندی

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

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