دسته بندی:

نصب مجدد سیستم عامل (Rebuild) کردن سرور مجازی

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

ریبیلد دقیقاً چه چیزی را از بین می‌برد

ریبیلد یک عملیات در سطح دیسک است، نه یک «ریست نرم». پس از آن:

  • کل فایل‌سیستم شامل /home، /var/www، /etc و دیتابیس‌ها پاک می‌شود.
  • کاربران، کلیدهای SSH، تنظیمات وب‌سرور و کران‌جاب‌ها از بین می‌روند.
  • کلید میزبان (host key) سرویس SSH عوض می‌شود؛ بنابراین در اولین اتصال بعدی با هشدار «REMOTE HOST IDENTIFICATION HAS CHANGED» روبه‌رو می‌شوید. این هشدار در چنین موقعیتی طبیعی است و با اجرای دستور ssh-keygen -R به همراه نشانی آی‌پی سرور، روی سیستم خودتان برطرف می‌شود.
  • معمولاً رمز عبور روت تازه‌ای صادر می‌شود که باید آن را از پنل تحویل بگیرید. بلافاصله پس از اولین ورود آن را عوض کنید؛ روش کار در تغییر رمز عبور سرور لینوکس آمده است.

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

چه زمانی ریبیلد کار درستی است

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

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

پیش از ریبیلد: چک‌لیست بکاپ

هر چه را می‌خواهید نگه دارید فهرست کنید و از سرور خارج کنید. موارد پرتکرار:

  • فایل‌های سایت و اپلیکیشن؛ برای نمونه tar -czf /root/www.tar.gz /var/www
  • دیتابیس‌ها؛ در MySQL و MariaDB: mysqldump -u root -p --single-transaction --routines --all-databases > /root/all-db.sql
  • پیکربندی‌ها: /etc/nginx، /etc/apache2 یا /etc/httpd، تنظیمات PHP و خروجی بکاپ کنترل‌پنل میزبانی
  • گواهی‌ها و کلیدهای خصوصی SSL، برای نمونه /etc/letsencrypt
  • کران‌جاب‌ها: crontab -l > /root/crontab.txt و محتوای /etc/cron.d
  • فهرست بسته‌های نصب‌شده، ایمیل‌ها و هر داده دیگری که فقط روی همین سرور است

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

انتخاب نسخه سیستم‌عامل

خودِ عملیات ریبیلد را از پنل انجام می‌دهید؛ مسیر آن در ناحیه کاربری در نصب سیستم عامل سرور مجازی از طریق ناحیه کاربری تصویری توضیح داده شده و در پنل‌های مجازی‌سازی مانند پنل solusvm همین گزینه با نام Reinstall در اختیار کاربر است.

در فهرست ایمیج‌ها معمولاً چند خانواده می‌بینید: دبیان و اوبونتو، خانواده RHEL مانند AlmaLinux و Rocky Linux، و نسخه‌های ویندوز سرور. چند نکته در انتخاب:

  • نسخه‌های پایدار و بلندمدت (LTS یا Stable) را ترجیح دهید تا زود ناچار به مهاجرت دوباره نشوید؛ تاریخ پایان پشتیبانی هر نسخه را از سایت رسمی همان توزیع ببینید.
  • اگر قصد نصب کنترل‌پنل میزبانی دارید، اول مستندات همان پنل را بخوانید و سیستم‌عاملی را انتخاب کنید که رسماً پشتیبانی می‌شود. این نکته برای پنل‌هایی مانند دایرکت‌ادمین و سی‌پنل اهمیت زیادی دارد و نصب روی نسخه پشتیبانی‌نشده معمولاً به بن‌بست می‌رسد.
  • ایمیج ساده و خام را به نسخه‌های از پیش آماده ترجیح دهید، و سازگاری آن را با نیازمندی‌های نرم‌افزار خودتان (نسخه PHP، پایتون، دیتابیس) بسنجید.

مسیر کلی در کنترل‌پنل

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

نیم‌ساعت اول پس از ریبیلد

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

  • به‌روزرسانی: در دبیان و اوبونتو apt update && apt upgrade و در AlmaLinux و Rocky دستور dnf upgrade. اگر کرنل به‌روز شد، سرور را یک‌بار ری‌استارت کنید.
  • کاربر غیر روت: یک کاربر معمولی بسازید، او را به گروه sudo (در خانواده RHEL گروه wheel) اضافه کنید و از این پس کارها را با همان کاربر انجام دهید.
  • ورود با کلید به‌جای رمز: کلید عمومی خود را با ssh-copy-id منتقل کنید، ورود با کلید را در یک ترمینال دوم تست کنید و تنها پس از موفقیت، در /etc/ssh/sshd_config مقادیر PasswordAuthentication no و PermitRootLogin prohibit-password را تنظیم و سرویس SSH را ری‌لود کنید. هشدار: اگر پیش از تست موفق، نشست فعلی را ببندید ممکن است دسترسی خود را از دست بدهید و ناچار شوید از کنسول پنل استفاده کنید.
  • فایروال: اول پورت SSH را مجاز کنید، بعد فایروال را فعال کنید؛ نه برعکس. با ufw یعنی نخست ufw allow OpenSSH (یا شماره پورت سفارشی خودتان) و سپس ufw enable؛ معادل آن در firewalld دستورهای firewall-cmd --permanent --add-service=ssh و firewall-cmd --reload است. فعال کردن فایروال بدون رعایت این ترتیب، رایج‌ترین راه قفل شدن بیرون سرور است.
  • ادامه مسیر: تنظیم نام میزبان و منطقه زمانی، نصب ابزاری مانند fail2ban، فعال کردن به‌روزرسانی خودکار امنیتی، و راه‌اندازی پایش و بکاپ منظم.

بازگرداندن اطلاعات

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

جمع‌بندی

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