مهاجرت به سرور مجازی؛ چک لیست انتقال از هاست بدون غافلگیری

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

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

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

مهاجرت به سرور مجازی از کجا شروع می شه؟ اول فهرست برداری (اولویت: بحرانی)

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

بعد یه فایل ساده بساز و هر چیزی که روی هاست فعلی داری توش بنویس:

• سایت ها و زیردامنه ها
• دیتابیس ها و کاربرهاشون
• حساب های ایمیل و فورواردرها
• کرون جاب ها
• گواهی SSL
• ریدایرکت ها و تنظیمات .htaccess
• رکوردهای DNS فعلی، مخصوصاً MX و TXT

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

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

آخر کار هم نسخه ها رو ثبت کن: نسخه PHP، افزونه های فعال PHP و نسخه MySQL یا MariaDB. یه قانون ساده هم هست: تغییر نسخه و مهاجرت رو هم زمان انجام نده. اگه همزمان جابه جا بشی و PHP رو هم بالا ببری و سایت خطا بده، نمی دونی مقصر کدومه.

سرور رو آماده کن، نه فقط روشنش (اولویت: بحرانی)

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

• سیستم عامل و بسته ها رو آپدیت کن.
• یه کاربر معمولی با دسترسی sudo بساز و ورود مستقیم root رو ببند.
• ورود با کلید SSH رو فعال کن و اگه می شه، ورود با رمز عبور رو برای SSH ببند.
• فایروال رو فقط برای پورت های لازم باز بذار، مثلاً SSH، 80 و 443.
• اگه دوست داری لاگ ها و کرون ها با ساعت ایران خونده بشن، منطقه زمانی رو روی تهران بذار.

اگه پشت CDN هستی و می خوای فقط CDN به سرور برسه، یه نکته هست که زیاد غافلگیر می کنه. Docker قانون های ufw رو دور می زنه. پس اگه از Docker استفاده می کنی، باید محدودیت ها رو توی زنجیره DOCKER-USER هم بذاری و فقط ufw کافی نیست. درباره اینکه CDN اصلاً جای هاست قوی رو می گیره یا نه، توی CDN برای سایت؛ آیا جای هاست قوی را می گیرد؟ بیشتر نوشتیم.

با پنل یا بدون پنل؟

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

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

داده ها رو کپی کن، ولی هنوز چیزی رو قطع نکن (اولویت: بحرانی)

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

بعد دو مسیر داری:

• انتقال از طریق پنل: اگه مقصد هم cPanel داره، بکاپ کامل حساب رو منتقل و روی سرور جدید بازیابی کن. برای سایت های معمولی ساده ترین راهه.
• انتقال دستی: برای سرور بدون پنل یا ساختار سفارشی. فایل ها رو با rsync و دیتابیس رو با dump منتقل می کنی. اگه هاست قدیمی دسترسی SSH نمی ده، فایل ها رو با FTP یا از بکاپ پنل بگیر.

نمونه ای از انتقال دستی:

# روی سرور جدید: کپی فایل ها از هاست قدیمی
rsync -avz -e ssh user@old-host:/home/user/public_html/ /var/www/example.ir/

# روی هاست قدیمی: خروجی گرفتن از دیتابیس
mysqldump -u dbuser -p dbname > dbname.sql

# روی سرور جدید: وارد کردن دیتابیس
mysql -u dbuser -p dbname < dbname.sql

قبل از وارد کردن دیتابیس، دیتابیس و کاربرش رو روی سرور جدید بساز و فایل dbname.sql رو هم با scp یا rsync به همون سرور ببر.

یه نکته مهم: این کپی اولین بار فقط برای تسته. تا لحظه تغییر DNS هنوز سفارش ها، کامنت ها و ثبت نام ها روی هاست قدیمی ثبت می شن. پس موقع سوئیچ نهایی باید یه بار دیگه همگام سازی کنی. یعنی چند دقیقه سایت رو در حالت تعمیر بذار، دیتابیس و فایل های تغییر کرده رو دوباره بگیر و بعد DNS رو عوض کن. فروشگاهی که این مرحله رو رد کنه، ممکنه چند سفارش رو گم کنه.

اگه سرور داخل ایرانه و از Docker استفاده می کنی، یه مورد دیگه هم هست. دریافت ایمیج از Docker Hub و بعضی بسته ها از داخل ایران ممکنه به خاطر محدودیت های دسترسی جواب نده. راه امن تر اینه که ایمیج ها رو روی سیستم توسعه بسازی و با SSH به سرور منتقل کنی. این رو از قبل چک کن تا وسط شب غافلگیر نشی.

روی سرور جدید تست کن، بدون اینکه DNS رو عوض کنی (اولویت: بحرانی)

این مرحله ارزشمندترین بخش چک لیسته. می تونی دامنه رو فقط روی سیستم خودت به سرور جدید وصل کنی، بدون اینکه کس دیگه ای چیزی ببینه. فایل hosts رو ویرایش کن:

203.0.113.10 example.ir www.example.ir

(IP بالا فقط نمونه ست، IP سرور خودت رو بذار.) حالا مرورگرت سایت رو از سرور جدید باز می کنه و بقیه دنیا هنوز هاست قدیمی رو می بینن. تست که تموم شد، این خط رو پاک کن تا یادت نره.

چیزهایی که باید دستی امتحان کنی:

• صفحه اصلی و صفحه های داخلی: لینک ها، تصویرها و ریدایرکت ها درست کار کنن.
• ورود به پنل مدیریت: مخصوصاً اگه نسخه PHP عوض شده.
• فرم ها و سبد خرید: یه سفارش آزمایشی کامل ثبت کن.
• درگاه پرداخت: این یکی خیلی ها رو غافلگیر می کنه. بعضی درگاه ها و بانک ها IP سرور پذیرنده رو ثبت می کنن و از IP ثبت نشده پاسخ نمی دن. نتیجه اش خطایی مثل «آدرس سرور پذیرنده نامعتبر است» می شه. این خطا با تغییر کد حل نمی شه و فقط با ثبت IP جدید از طرف بانک یا شرکت درگاه درست می شه. پس IP جدید رو همین الان بهشون بده، نه روز انتقال.
• ارسال ایمیل: اگه ایمیل های سایت قبلاً از هاست قدیمی می رفتن، با IP جدید ممکنه نرسن یا اسپم بشن. رکورد SPF رو هم با IP جدید هماهنگ کن. مشکل رایجش رو توی ارسال ایمیل وردپرس؛ چرا پیام موفق است ولی نمی رسد؟ توضیح دادیم.
• کرون جاب ها و کارهای زمان بندی شده: بکاپ خودکار، سایت مپ و بقیه.
• SSL: گواهی باید روی سرور جدید صادر یا منتقل شده باشه. اگه تا لحظه تغییر DNS منتظرش بمونی، کاربرها هشدار امنیتی می بینن. اگه صدور گواهی به دامنه ای نیاز داره که هنوز به سرور جدید نرسیده، گواهی رو منتقل کن یا از روش تایید با DNS استفاده کن.
• اینماد و نمادهای اعتماد: مطمئن شو کدشون توی صفحه ها هست و روی دامنه درست باز می شه.

سرعت رو هم با هاست قبلی مقایسه کن، ولی زیاد خوش بین نباش. دیسک سریع به تنهایی همه چیز نیست و هاست NVMe؛ چرا دیسک سریع برای سایت کافی نیست؟ دقیقاً همین رو باز کرده. اگه صفحه ها هنوز دیر باز می شن، باید سراغ کش و تنظیمات PHP بری. سرور جدید خودش معجزه نمی کنه.

DNS رو آخر و با برنامه عوض کن (اولویت: مهم)

حالا که همه چیز سالمه، نوبت DNS رسیده. چند روز قبل از انتقال، TTL رکوردها رو کم کن، مثلاً به چند دقیقه. این کار باعث می شه بعد از تغییر، اطلاعات جدید زودتر به کاربرها برسه. اگه TTL بالا باشه، بخشی از کاربرها ساعت ها به سرور قدیمی می رن.

چند چیز رو یادت نره:

• رکورد A دامنه و www رو به IP جدید ببر.
• رکوردهای MX و TXT (مثل SPF) رو دقیقاً از فهرست اول کپی کن. اگه ایمیل سازمانیت جای دیگه ای میزبانی می شه، به MX دست نزن.
• اگه پشت CDN هستی، فقط آدرس مبدأ رو عوض کن و بقیه تنظیمات رو دست نزن.

اگه تفاوت رکوردها برات گنگه، رکورد DNS چیست؟ تفاوت A، CNAME، MX و TXT با مثال رو سریع بخون.

دامنه .ir یه نکته جدا داره. اگه DNS دامنه روی خود هاست قدیمی بود و می خوای نیم سرورها رو عوض کنی، اول رکوردها رو جایی که قراره بمونن بساز و بعد نیم سرورها رو عوض کن. این تغییر از پنل دامنه انجام می شه و گاهی چند ساعت طول می کشه. اگه تازه دامنه گرفتی یا نمی دونی کجا مدیریت می شه، ثبت دامنه ir قدم به قدم؛ از انتخاب نام تا فعال شدن کمکت می کنه.

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

بعد از انتقال، هاست قدیمی رو فوری نبند (اولویت: مهم)

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

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

کارهای تکمیلی

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

اگه چند سایت روی یه حساب مشترک داشتی، فرصت خوبیه که جداشون کنی. میزبانی چند سایت؛ حساب مشترک چه خطرهایی دارد؟ دلیلش رو توضیح داده.

سوالات متداول

مهاجرت به سرور مجازی چقدر طول می کشه؟

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

سایتم موقع انتقال قطع می شه؟

اگه همین ترتیب رو رعایت کنی، قطعی واقعی لازم نیست. فقط ممکنه برای همگام سازی نهایی چند دقیقه سایت رو در حالت تعمیر بذاری. بعد از تغییر DNS هم بعضی کاربرها برای مدتی هنوز نسخه قدیمی رو می بینن. برای همین نگه داشتن هاست قدیمی مهمه.

ایمیل های دامنه هم منتقل می شن؟

فقط اگه ایمیل ها روی همون هاست باشن و اون ها رو هم جدا منتقل کنی. رکوردهای MX و TXT رو با فهرست اول چک کن، چون اشتباه توی اون ها باعث گم شدن یا اسپم شدن ایمیل می شه. برای ریشه یابی مشکل، اسپم شدن ایمیل؛ مشکل از هاست است یا فرستنده؟ می تونه کمکت کنه.

بعد از مهاجرت، خطای درگاه پرداخت می گیرم. مشکل از کده؟

معمولاً نه. اگه خطا درباره نامعتبر بودن آدرس سرور پذیرنده باشه، احتمالاً IP جدید سرور برای درگاه ثبت نشده. این ثبت باید از طرف بانک یا شرکت ارائه دهنده درگاه انجام بشه و تغییر کد سایت مشکل رو حل نمی کنه.

قبل از شروع، این سه کار رو بکن

اگه وقت نداری همه مراحل رو دنبال کنی، حداقل این سه کار رو بکن: فهرست دارایی ها رو بنویس، سایت رو با فایل hosts روی سرور جدید تست کن و IP جدید رو پیش از انتقال به بانک بده. بقیه کارها هم کمک می کنن، ولی این سه تا بیشترین غافلگیری رو حذف می کنن. اگه هم نمی خوای درگیر جزئیات بشی، با مشاوره و معماری می تونی قبل از شروع، مسیر رو با کسی که این کار رو زیاد انجام داده بررسی کنی.