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

💡 ترتیب کار: همگام‌سازی زودهنگام، تست روی سرور جدید و در آخر تغییر DNS

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

🔶 انتقال رایگان به سرور اختصاصی وب‌داده

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

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

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

نشانه‌هایی که زمان مهاجرت به سرور اختصاصی رسیده است

◀️ مصرف مداوم منابع: در ساعت‌های اوج، پردازنده یا رم بیشتر وقت‌ها نزدیک سقف است.
◀️ زمان انتظار دیسک: مقدار بالای iowait یعنی پردازنده مدام منتظر دیسک اشتراکی می‌ماند و دیسک گلوگاه شده است.
◀️ نیاز به سخت‌افزار خاص: رم زیاد، دیسک NVMe اختصاصی یا پورت شبکه پرسرعت می‌خواهید.
◀️ الزامات امنیتی و انطباق: باید مطمئن باشید سخت‌افزار با مشتری دیگری مشترک نیست.
◀️ مجازی‌سازی شخصی: می‌خواهید چند ماشین مجازی را خودتان روی یک سرور فیزیکی بسازید.
اگر هنوز مطمئن نیستید، مقاله ۷ نشانه کلیدی برای مهاجرت به سرور داخل ایران دلایل را بررسی کرده است. اینجا فرض بر این است که تصمیم را گرفته‌اید و فقط سراغ روش انجام کار می‌رویم.
[ VPS (old) ] --rsync + db dump--> [ Dedicated (new) ]
      |                                   |
   DNS A record (low TTL) ---- switch ----+
      |
   keep running until traffic = 0  (rollback path)

🔸 نکته فنی: TTL چطور کار می‌کند؟

طبق RFC 1035، مقدار TTL مدت زمانی است که یک رکورد DNS می‌تواند در حافظه موقت (کش) رزالورها بماند، پیش از آنکه دوباره از منبع پرسیده شود. یعنی اگر TTL رکورد A دامنه یک روز باشد، برخی کاربران تا یک روز بعد از تغییر هنوز به IP قدیم می‌روند. خود کاهش TTL هم همین تأخیر را دارد: رزالوری که رکورد را با TTL قبلی ذخیره کرده، تا پایان همان مدت مقدار جدید را نمی‌بیند. پس TTL را دست‌کم به اندازه مقدار قبلی‌اش زودتر از روز جابه‌جایی کم کنید. مبانی DNS را در مقاله DNS چیست ببینید.

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

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

بیشتر مشکلات انتقال سرور از چیزی شروع می‌شود که فراموش شده است: یک کران‌جاب، یک ماژول PHP یا یک رکورد DNS. پس پیش از هر فرمانی، فهرست کاملی از سرویس‌ها تهیه کنید و موارد زیر را یکی‌یکی تیک بزنید.
✅ بکاپ کامل و تست‌شده: پیش از شروع، از فایل‌ها و دیتابیس نسخه پشتیبان کامل بگیرید و بازیابی‌اش را یک بار امتحان کنید. روش‌ها را در راهنمای بکاپ سرور اختصاصی و قانون ۳-۲-۱ ببینید.
✅ فهرست سرویس‌ها: وب‌سرور، نسخه PHP و ماژول‌ها، دیتابیس، Redis، کران‌جاب‌ها، سرویس‌های systemd و پورت‌های باز.
✅ فهرست دامنه‌ها و رکوردها: همه رکوردهای A، MX، TXT و CNAME و محل مدیریت DNS هر دامنه.
✅ ظرفیت سرور مقصد: فضای دیسک کافی برای داده فعلی، بکاپ موقت و رشد؛ صفحه انتقال وب‌داده حدود ۲۰ درصد ظرفیت دیسک اضافه را توصیه می‌کند.
✅ هم‌نسخه بودن نرم‌افزارها: نسخه سیستم‌عامل، PHP و MySQL یا MariaDB را تا حد امکان یکسان نگه دارید.
✅ توقف تغییرات: در روز انتقال، افزونه جدید نصب نکنید و حساب یا سایت تازه نسازید.

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

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

⚠️ دو محدودیت که باید از قبل بدانید

در دیتابیس پرتراکنش، بدون یک پنجره کوتاه توقف نوشتن نمی‌شود سازگاری کامل داده را تضمین کرد، مگر اینکه تکرار (Replication) میان دو سرور راه‌اندازی شود که پیچیدگی خودش را دارد. محدودیت دوم IP است: سرور جدید IP دیگری دارد، پس فایروال‌ها، لیست سفید درگاه‌های پرداخت و هر سرویسی را که به IP فعلی وابسته است، از قبل به‌روز کنید.

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

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

جدول زیر یک برنامه نمونه برای مهاجرت بدون قطعی یک سایت یا فروشگاه متوسط است؛ زمان‌ها را با حجم داده و TTL فعلی دامنه‌تان تنظیم کنید.
زمانکار اصلینتیجه
۷ روز قبلکاهش TTL و گرفتن بکاپ کاملآمادگی برای جابه‌جایی سریع DNS
۲ تا ۳ روز قبلآماده‌سازی سرور مقصد و همگام‌سازی اولیه فایل‌هابیشتر داده بدون قطعی منتقل می‌شود
روز انتقالحالت نگهداری، همگام‌سازی نهایی و انتقال دیتابیسپنجره قطعی کوتاه و کنترل‌شده
همان روزتست با فایل hosts و سپس تغییر رکورد Aترافیک به سرور جدید می‌رود
تا صفر شدن ترافیک قدیمپایش لاگ هر دو سرور و Search Consoleخاموش کردن امن سرور قدیم

آموزش انتقال سایت به سرور اختصاصی؛ فایل، دیتابیس، ایمیل و DNS

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

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

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

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

طبق مستندات rsync، گزینه -a معادل -rlptgoD است و لینک‌های سخت، ACL و ویژگی‌های گسترده را شامل نمی‌شود؛ برای همین در دستور زیر -H، -A و -X جداگانه آمده‌اند. گزینه --numeric-ids هم شناسه کاربر و گروه را بدون تبدیل به نام منتقل می‌کند. این همگام‌سازی اول در حالی انجام می‌شود که سایت روشن است و بیشتر حجم داده را جابه‌جا می‌کند؛ رمز مهاجرت بدون قطعی همین است، چون برای روز آخر فقط تغییرات باقی می‌ماند.
# first pass (site stays online)
rsync -aHAX --numeric-ids --info=progress2 \
  /var/www/ root@NEW_IP:/var/www/

# dry run of the final pass: -n shows what would change
rsync -aHAXn --numeric-ids --delete /var/www/ root@NEW_IP:/var/www/

۳- انتقال دیتابیس بدون ناسازگاری

طبق مستندات MariaDB، گزینه --single-transaction وضعیت سازگار جداول InnoDB را بدون مسدود کردن برنامه‌ها خروجی می‌گیرد، اما فقط جداول InnoDB را سازگار نگه می‌دارد. تریگرها به‌طور پیش‌فرض خروجی گرفته می‌شوند، ولی رویه‌های ذخیره‌شده و رویدادها به --routines و --events نیاز دارند. در MySQL هم ابزار mysqldump همین گزینه‌ها را دارد.
# on the old server, inside the maintenance window
mariadb-dump --single-transaction --routines --events \
  --databases shopdb > shopdb.sql
rsync -z shopdb.sql root@NEW_IP:/root/

# on the new server
mariadb < /root/shopdb.sql
📌 در دیتابیس‌های چندده‌گیگابایتی، گرفتن و به‌خصوص بازیابی خروجی متنی زمان زیادی می‌برد؛ در این حالت ابزار پشتیبان‌گیری فیزیکی مثل mariadb-backup یا راه‌اندازی تکرار دیتابیس گزینه بهتری است. کاربران و دسترسی‌های دیتابیس همراه این خروجی منتقل نمی‌شوند؛ آن‌ها را روی سرور جدید بسازید و نام کاربر، رمز و میزبان دیتابیس را در فایل تنظیمات برنامه بررسی کنید.

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

اگر ایمیل روی همان VPS است، صندوق‌ها را با ابزار انتقال IMAP (مثل imapsync) یا ابزار کنترل پنل منتقل کنید. سپس رکورد A میزبانی را که MX به آن اشاره می‌کند و رکورد SPF را برای IP جدید به‌روز کنید؛ رکورد DKIM به IP وابسته نیست و فقط وقتی تغییر می‌کند که کلیدش روی سرور جدید از نو ساخته شود. رکورد PTR را هم برای IP جدید تنظیم کنید؛ در وب‌داده این کار از پنل کاربری انجام می‌شود و روش آن در مقاله تنظیم رکورد PTR آمده است. فهرست کران‌جاب‌ها را برای هر کاربر با crontab -l از سرور قدیم دربیاورید و فایل‌های /etc/cron.d را هم از قلم نیندازید.
برای SSL دقت کنید: طبق مستندات Let’s Encrypt، در روش HTTP-01 فایل تأیید باید روی وب‌سرور همان دامنه در دسترس باشد. پس تا زمانی که DNS به سرور جدید اشاره نکند، این روش روی سرور جدید جواب نمی‌دهد. راه ساده این است که گواهی فعلی را به سرور جدید کپی کنید و پس از تغییر DNS دوباره صادر کنید. روش DNS-01 هم به IP سرور وابسته نیست و از همان ابتدا روی سرور جدید جواب می‌دهد.

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

در ساعت کم‌ترافیک، سایت را در حالت نگهداری بگذارید یا نوشتن را متوقف کنید. سپس rsync نهایی را با --delete اجرا کنید تا فایل‌هایی که روی سرور قدیم حذف شده‌اند، روی مقصد هم حذف شوند. این گزینه برگشت‌پذیر نیست؛ پس اول خروجی اجرای آزمایشی با -n را ببینید و از درستی مسیر مقصد مطمئن شوید. بعد خروجی دیتابیس را بگیرید و روی سرور جدید بازیابی کنید. چون بیشتر داده در گام دوم منتقل شده، این مرحله معمولاً کوتاه است.

۶- تست با فایل hosts و تغییر DNS

پیش از تغییر DNS، در فایل hosts رایانه خودتان دامنه را به NEW_IP اشاره دهید و سایت، ورود کاربران، پرداخت و فرم‌ها را روی سرور جدید آزمایش کنید. اگر همه‌چیز درست بود، رکورد A را تغییر دهید. راهنمای Google Search Central هم می‌گوید زیرساخت قدیم را تا وقتی ترافیکش به صفر نرسیده خاموش نکنید و در این مدت لاگ هر دو سرور را زیر نظر داشته باشید.
# Linux / macOS: /etc/hosts   Windows: C:\Windows\System32\drivers\etc\hosts
NEW_IP   example.com   www.example.com

# after the switch, check what resolvers return
dig +short example.com A

📚 آنچه راهنمای گوگل می‌گوید

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

برنامه بازگشت؛ اگر چیزی درست کار نکرد

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

آموزش انتقال سایت به سرور اختصاصی؛ فایل، دیتابیس، ایمیل و DNS

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

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

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

پایان تغییر DNS، پایان انتقال سایت به سرور اختصاصی نیست. در ۴۸ ساعت اول، این موارد را بررسی کنید تا مشکلات پنهان پیش از آنکه کاربران ببینند، پیدا شوند.
✅ صفحه‌های اصلی، ورود کاربران، سبد خرید و درگاه پرداخت
✅ ارسال و دریافت ایمیل و وضعیت SPF، DKIM و PTR
✅ اجرای کران‌جاب‌ها، صف‌ها و بکاپ خودکار روی سرور جدید
✅ لاگ خطای وب‌سرور و دیتابیس روی هر دو سرور
✅ گزارش‌های Search Console و نرخ خزش
سلامت سخت‌افزار و کارایی سرور جدید را هم بسنجید؛ روش آن را در راهنمای تست سلامت و بنچمارک سرور اختصاصی آورده‌ایم. برای هشدار به‌موقع، ابزارهای مانیتورینگ سرور را راه‌اندازی کنید و اگر از ماشین‌های مجازی بکاپ می‌گیرید، مقاله Veeam Backup چیست را ببینید.

سناریوی نمونه؛ انتقال فروشگاه با دیتابیس پرتراکنش

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

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

طبق صفحه انتقال به وب‌داده، این خدمت برای همه پلن‌ها رایگان است و در پنج گام انجام می‌شود: آماده‌سازی، انتقال داده، اعتبارسنجی، کنترل کیفیت به دست خود شما و به‌روزرسانی DNS. برای مشتریان فعلی وب‌داده، پیکربندی DNS را ما انجام می‌دهیم، اما مشتریان جدید باید رکوردها را خودشان به‌روز کنند.
✅ سرور اختصاصی HPE با پلن آماده PRIME 9: دو پردازنده Xeon E5-2680 v4، رم 64GB از نوع ECC و 1TB دیسک NVMe
✅ نصب خودکار سیستم‌عامل و تحویل آنی پس از پرداخت؛ مناسب برای آماده‌سازی سرور مقصد پیش از روز انتقال
✅ پورت 10Gbit/s و ترافیک محاسبه‌شده فقط روی دانلود؛ آپلود رایگان است
✅ تنظیم PTR از پنل کاربری و امکان خرید IP اضافه
✅ پشتیبانی ۲۴ ساعته پس از مهاجرت
🚀 بیشتر بدانید: اگر نمی‌خواهید پس از مهاجرت مدیریت روزمره سرور را خودتان انجام دهید، مقاله سرور اختصاصی مدیریت‌شده یا مدیریت‌نشده را بخوانید.

سوالات متداول درباره انتقال سرور

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

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

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

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

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

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

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

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

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

جمع‌بندی؛ ترتیب درست کار در مهاجرت سرور

مهاجرت به سرور اختصاصی کار پیچیده‌ای نیست، به شرط آنکه ترتیب درست را رعایت کنید: بکاپ و فهرست کامل، کاهش زودهنگام TTL، همگام‌سازی اولیه با rsync، پنجره کوتاه برای همگام‌سازی نهایی و انتقال دیتابیس، تست با فایل hosts و در پایان تغییر DNS.
چند کار هم هست که معمولاً جا می‌ماند: سرور قدیم را تا صفر شدن ترافیکش روشن نگه دارید، برای بازگشت مهلت مشخص تعیین کنید و پس از جابه‌جایی، ایمیل، SSL، کران‌جاب‌ها و Search Console را بررسی کنید. حتی در مهاجرت بدون قطعی، سرویس پرتراکنش به یک پنجره کوتاه توقف نوشتن نیاز دارد؛ زمانش را از اول در برنامه بگذارید و به کاربران اطلاع دهید.
اگر ترجیح می‌دهید این مسیر را با کمک متخصص طی کنید، تیم وب‌داده انتقال رایگان را انجام می‌دهد و سرور اختصاصی HPE با تحویل آنی و پنل مدیریت آماده است. آخرین توصیه هم این است: درست پیش از تغییر DNS، بکاپ و نتیجه تست‌ها را یک بار دیگر مرور کنید.
اگر در مهاجرت سرورتان به مرحله‌ای رسیدید که در این راهنما نیامده، در بخش نظرات بپرسید؛ کارشناسان وب‌داده پاسخ می‌دهند.
منابع: Google Search Central, Move a site with no URL changes؛ IETF RFC 1035, Domain Names: Implementation and Specification؛ rsync(1) manual page؛ MariaDB Documentation, mariadb-dump؛ cPanel Documentation, WHM Transfer Tool؛ Let's Encrypt, Challenge Types
به اشتراک بگذارید
وب داده
وب داده

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

مقاله‌ها: 259

نوشته‌ای مرتبط

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *