نصب مجدد سیستم عامل سرور: چک‌لیست قبل و بعد

سرور بالا نمی‌آید، یا بالا می‌آید ولی آن‌قدر آلوده و به‌هم‌ریخته است که تعمیرش گران‌تر از نصب دوباره تمام می‌شود. تصمیم گرفته‌اید سیستم عامل را از صفر بریزید. قبل از اینکه دکمه Reinstall را بزنید، بدانید که بزرگ‌ترین ریسک این کار خودِ نصب نیست؛ چیزی است که فراموش می‌کنید ذخیره کنید و چیزی که یادتان نمی‌آید بعداً دوباره بسازید.

قبل از نصب مجدد سیستم عامل: چه چیزی واقعاً باید ذخیره شود

فایل‌های سایت را همه به یاد می‌آورند. آنچه معمولاً جا می‌ماند، چیزهایی است که بیرون از /var/www زندگی می‌کنند و کسی به‌عنوان «داده» به آن‌ها نگاه نمی‌کند.

• دیتابیس‌ها با ساختار و داده. یک mysqldump ساده کافی نیست اگر کاربران، گرنت‌ها و triggerها را از دست بدهید. دست‌کم این را اجرا کنید: mysqldump --single-transaction --routines --triggers --events -u root -p --all-databases > all.sql. برای PostgreSQL معادلش pg_dumpall -U postgres > all.sql است.
• کلیدهای SSH. پوشه /root/.ssh و /home/*/.ssh را کامل بردارید. اگر کلید میزبان (/etc/ssh/ssh_host_*) را نگه ندارید، بعد از نصب همه کلاینت‌ها هشدار REMOTE HOST IDENTIFICATION HAS CHANGED می‌گیرند و باید خط مربوطه را از known_hosts پاک کنند.
• گواهی‌های SSL. اگر Let's Encrypt دارید، بازسازی‌اش راحت است. اگر گواهی خریداری‌شده دارید، فایل .key و .crt را بردارید؛ صدور مجدد هزینه و زمان دارد.
• کرون‌ها و تایمرها. خروجی crontab -l -u root و محتوای /etc/cron.d/ و /etc/systemd/system/*.timer. این‌ها را کسی بکاپ نمی‌گیرد چون «تنظیمات» هستند، نه «داده».
• کانفیگ سرویس‌ها. /etc/nginx، /etc/apache2، /etc/php، /etc/postfix، /etc/fail2ban. حتی اگر از صفر بنویسید، دیدن نسخه قبلی نیم ساعت وقت صرفه‌جویی می‌کند.
• فایل‌های خارج از مسیر استاندارد. هر چیزی که خودتان جایی گذاشته‌اید: اسکریپت‌های بکاپ، فایل‌های env، داده‌های آپلودی که مسیرشان را در کد hardcode کرده‌اید.

یک راه سریع برای پیدا کردن چیزهایی که فراموش می‌کنید: قبل از نصب، خروجی du -xh --max-depth=2 / | sort -h | tail -40 را بگیرید و روی هر مسیری که بیش از ۱ گیگابایت است مکث کنید. اگر توضیح روشنی برایش ندارید، احتمالاً همان چیزی است که بعداً کم می‌آورید.

اگر دسترسی به سرور را از دست داده‌اید

وقتی سرور بوت نمی‌شود، راه معمول این است که از پنل، سرور را در حالت rescue بالا بیاورید و دیسک را mount کنید. اگر این مسیر برایتان تازه است، راهنمای بازنصب سرور و کار با حالت rescue؛ نجات داده‌ها وقتی دسترسی را از دست دادید گام‌به‌گام همین کار را توضیح می‌دهد. نکته‌ای که در عمل زیاد به آن برمی‌خورم: در حالت rescue، دیسک اصلی معمولاً روی /dev/sda1 یا /dev/vda1 است ولی همیشه این‌طور نیست. اول lsblk -f بزنید و بعد mount کنید.

تنظیماتی که بعد از نصب دوباره لازم می‌شوید

اینجا جایی است که بیشترین وقت تلف می‌شود، چون سرور تازه نصب‌شده از نظر فنی سالم است ولی از نظر کارکردی هنوز همان سرور قبلی نیست.

امنیت پایه، قبل از هر چیز دیگری

ترتیب کار مهم است. اول کاربر غیر root بسازید، بعد ورود root با رمز را ببندید، بعد پورت SSH را جابه‌جا کنید. اگر ترتیب را برعکس کنید و وسط کار قطع شوید، ممکن است بیرون بمانید. گزینه‌های دقیق sshd_config و اینکه کدام‌شان واقعاً ارزش تغییر دارند در پیکربندی SSH: گزینه‌های امنیتی مهم در sshd_config آمده است. حداقل کاری که باید بکنید: PermitRootLogin prohibit-password و PasswordAuthentication no.

بعد از آن فایروال. قاعده ساده‌ای که همیشه جواب می‌دهد: هر پورتی که در لیست مرجع پورت سرویس‌های پرکاربرد و پورت‌هایی که نباید باز باشند نیست، باید بسته باشد. یک ss -tulpn بزنید و ببینید واقعاً چه چیزی گوش می‌دهد، نه اینکه فرض کنید فقط SSH و وب سرور باز است.

سرویس‌ها و وابستگی‌هایشان

اگر سرویس سفارشی دارید، فایل unit را از بکاپ برگردانید و systemctl daemon-reload بزنید. خطای رایج بعد از نصب مجدد، سرویسی است که active (running) است ولی کار نمی‌کند، چون After= و Requires= درست تنظیم نشده و قبل از دیتابیس بالا آمده. جزئیات این بخش‌ها در فایل unit در systemd: بخش‌ها، ری‌استارت و وابستگی توضیح داده شده. برای دیباگ سریع: systemctl status myservice و بعد journalctl -u myservice -n 50 --no-pager.

انتخاب توزیع، اگر می‌خواهید این بار درست انتخاب کنید

نصب مجدد فرصت خوبی است که از توزیعی که فقط «چون همیشه بود» استفاده می‌کردید فاصله بگیرید. اگر تیم شما با apt راحت‌تر است، Debian پایدارترین گزینه است. اگر به نسخه‌های تازه‌تر kernel و بسته‌ها نیاز دارید، Ubuntu LTS تعادل بهتری می‌دهد. مقایسه عملی‌تر را در انتخاب توزیع لینوکس سرور: راهنمای عملی و بی‌حاشیه ببینید. توصیه من: اگر سرور در حال کار است و مشکل فقط نرم‌افزاری بود، توزیع را عوض نکنید. تغییر توزیع هم‌زمان با ریکاوری، دو متغیر را با هم عوض می‌کند و دیباگ را سخت می‌کند.

این‌جا اشتباه می‌کنند

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

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

بعد از نصب، این‌ها را چک کنید

1. uptime و free -m را ببینید. اگر بعد از نصب و قبل از برگرداندن سایت، لود غیرعادی است، مشکل از قبل وجود داشته و نصب مجدد حلش نکرده.
2. هر سرویس را با systemctl is-enabled چک کنید که بعد از ریبوت خودش بالا بیاید. سرویسی که الان running است ولی enabled نیست، در اولین ریبوت غافلگیرتان می‌کند.
3. یک ریبوت واقعی بزنید و بعد از بالا آمدن، همه چیز را دوباره تست کنید. این تنها راه اطمینان از این است که وابستگی‌ها درست چیده شده‌اند.
4. لاگ‌ها را برای ۲۴ ساعت اول زیر نظر بگیرید. اگر لود بالا رفت، راهنمای تشخیص علت لود بالای سرور؛ راهنمای عملی و گام‌به‌گام نقطه شروع خوبی است.

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

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

پرسش‌های پرتکرار

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

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

چطور بفهمم قبل از نصب مجدد همه چیز را بکاپ گرفته‌ام؟

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

بعد از نصب مجدد، چرا سایت بالا نمی‌آید ولی سرویس‌ها running هستند؟

معمولاً یکی از این سه چیز است: مجوز فایل‌ها و مالکیت پوشه‌ها اشتباه است، کانفیگ وب سرور به مسیر یا نسخه PHP قدیمی اشاره می‌کند، یا سرویس به‌خاطر وابستگی درست بالا نیامده و فقط ظاهراً فعال است. با journalctl -u nginx -n 50 و tail -f /var/log/nginx/error.log شروع کنید.

آیا می‌توانم بدون نصب مجدد، سیستم عامل را ارتقا بدهم؟

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