حالت نجات سرور: وقتی سیستم بالا نمی‌آید

سرور ریبوت شده و برنگشته. پینگ می‌خورد ولی SSH روی پورت 22 تایم‌اوت می‌شود، یا کنسول روی emergency mode گیر کرده و منتظر رمز root است. اگر این تصویر آشناست، احتمالاً مشکل بوت است نه شبکه، و راه‌حل از داخل خود سیستم‌عامل در حال اجرا نمی‌گذرد. باید سرور را در حالت نجات بالا بیاورید، دیسک اصلی را دستی مانت کنید، خرابی را بردارید و بعد به بوت عادی برگردید. این متن همان مسیر است، با دستورهایی که واقعاً اجرا می‌شوند.

حالت نجات سرور دقیقاً چه چیزی را بالا می‌آورد

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

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

قبل از هر کاری: پیدا کردن نام دیسک درست

اولین دستوری که در حالت نجات می‌زنید این است:

lsblk -f

خروجی چیزی شبیه این می‌دهد:

NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
vda
└─vda1 ext4         4f9c1e2a-...                          /mnt
vdb    swap         8a3b7d10-...

روی سرورهای مجازی معمولاً vda یا sda دیسک اصلی است و پارتیشن ریشه vda1. اگر LVM دارید، lsblk فقط vda2 را نشان می‌دهد و باید یک مرحله جلوتر بروید:

vgscan
vgchange -ay
lvs

بعد از vgchange -ay، ولوم لاجیکال با نامی مثل ubuntu-vg/ubuntu-lv ظاهر می‌شود و همان چیزی است که باید مانت کنید. اگر این مرحله را رد کنید و مستقیم سراغ مانت بروید، خطای special device /dev/mapper/... does not exist می‌گیرید و فکر می‌کنید دیسک از دست رفته. نرفته.

مانت کردن دیسک اصلی و ورود به آن

یک نقطه مانت بسازید و پارتیشن ریشه را وصل کنید:

mkdir -p /mnt/root
mount /dev/vda1 /mnt/root

اگر پیام unknown filesystem type 'LVM2_member' گرفتید، یعنی روی پارتیشن LVM مانت زده‌اید؛ برگردید به مرحله vgchange. اگر خطای Structure needs cleaning یا bad superblock دیدید، فایل‌سیستم آسیب دیده و باید قبل از مانت تعمیرش کنید:

fsck -y /dev/vda1

روی فایل‌سیستم‌های XFS به‌جای fsck از xfs_repair /dev/vda1 استفاده کنید؛ fsck روی XFS کار نمی‌کند و فقط خطا می‌دهد. این یکی از آن جاهایی است که انتخاب فایل‌سیستم، وسط بحران، تفاوت ایجاد می‌کند.

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

mount --bind /dev  /mnt/root/dev
mount --bind /proc /mnt/root/proc
mount --bind /sys  /mnt/root/sys
chroot /mnt/root /bin/bash

از این لحظه پرامپت شما داخل سیستم‌عامل خراب است. هر دستوری که می‌زنید روی همان دیسک اثر می‌گذارد.

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

۱. خطای fstab و افتادن در emergency mode

اگر بعد از اضافه کردن یک دیسک جدید یا تغییر UUID، سیستم در emergency mode بالا می‌آید، مقصر تقریباً همیشه /etc/fstab است. یک خط اشتباه کافی است تا systemd نتواند ریشه را کامل مانت کند. داخل chroot فایل را باز کنید و خط مشکوک را با # کامنت کنید. برای دیدن UUID واقعی:

blkid

و بعد خط را با مقدار درست بنویسید:

UUID=4f9c1e2a-... / ext4 errors=remount-ro 0 1

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

۲. کرنل یا initramfs ناقص بعد از آپدیت

اگر بوت روی Kernel panic - not syncing: VFS: Unable to mount root fs می‌ایستد، احتمالاً initramfs با ماژول‌های درست ساخته نشده. داخل chroot:

ls /boot
update-initramfs -u -k all
update-grub

روی توزیع‌های خانواده RHEL دستور معادل dracut -f و grub2-mkconfig -o /boot/grub2/grub.cfg است. اگر /boot پر شده باشد، ساخت initramfs نیمه‌کاره می‌ماند و همین خطا برمی‌گردد؛ با df -h /boot چک کنید.

۳. سرویسی که بوت را قفل می‌کند

گاهی سیستم‌عامل سالم است ولی یک unit خراب، بوت را دقیقه‌ها معطل می‌کند و شما فکر می‌کنید سرور مرده. داخل chroot ببینید کدام unit در حال انتظار است:

systemctl list-jobs
systemctl status networking

اگر سرویسی روی پورتی گیر کرده که سرویس دیگری آن را گرفته، یا وابستگی حلقه‌ای دارد، با systemctl disable موقتاً از مسیر بوت خارجش کنید. ساختار درست unit و وابستگی‌ها را در فایل unit در systemd: بخش‌ها، ری‌استارت و وابستگی می‌توانید ببینید؛ همان‌جا توضیح داده شده چرا After= بدون Requires= بوت را قفل نمی‌کند ولی Requires= می‌کند.

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

شایع‌ترین خطا این است که آدم در حالت نجات، دیسک را مانت می‌کند، فایل را درست می‌کند، و بعد بدون umount سرور را ریبوت می‌کند. نتیجه: فایل‌سیستم dirty می‌ماند، یا بدتر، تغییرات در کش نوشته نشده و بعد از بوت عادی می‌بینید فایل هنوز خراب است. علامتش هم این است که همه‌چیز درست به نظر می‌رسید ولی مشکل برگشت. ترتیب خروج درست این است:

exit
umount -R /mnt/root
sync
reboot

خطای دوم: کسی fsck را روی فایل‌سیستم مانت‌شده اجرا می‌کند. fsck روی فایل‌سیستم mount شده می‌تواند داده را واقعاً خراب کند، نه فقط هشدار بدهد. اگر پیام filesystem is mounted دیدید، اول unmount کنید.

بازگشت به بوت عادی و چک‌های بعد از آن

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

• dmesg -T | tail -50 برای دیدن خطاهای دیسک یا I/O در لحظه بوت
• systemctl --failed برای دیدن unitهایی که بالا نیامده‌اند
• df -h و free -m برای اطمینان از اینکه پارتیشن‌ها درست مانت شده‌اند

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

یک محدودیت را هم صریح بگویم: حالت نجات برای خرابی نرم‌افزاری است، نه سخت‌افزاری. اگر smartctl -a /dev/vda خطای Reallocated_Sector_Ct بالا نشان می‌دهد یا دیسک در lsblk اصلاً دیده نمی‌شود، تعمیر فایل‌سیستم فقط وقت می‌گیرد. آن‌جا اولویت، کپی داده است نه تعمیر. اگر دسترسی به سرور را کامل از دست داده‌اید، مسیر بازنصب سرور و کار با حالت rescue؛ نجات داده‌ها وقتی دسترسی را از دست دادید را بخوانید.

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

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

حالت نجات سرور چه تفاوتی با بوت عادی دارد؟

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

چرا بعد از فعال کردن حالت نجات، SSH به IP قبلی وصل نمی‌شود؟

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

آیا با حالت نجات داده‌هایم پاک می‌شود؟

خود حالت نجات به داده‌ها دست نمی‌زند. خطر واقعی از دستورهای اشتباهی می‌آید که داخل chroot اجرا می‌کنید؛ مثلاً mkfs روی پارتیشن اشتباه یا fsck روی فایل‌سیستم مانت‌شده. قبل از هر دستور مخرب، با lsblk -f مطمئن شوید روی کدام دستگاه کار می‌کنید.

بعد از تعمیر، چطور مطمئن شوم مشکل برنمی‌گردد؟

یک ریبوت آزمایشی بزنید و بعد از بالا آمدن، systemctl --failed و dmesg -T | tail -50 را چک کنید. اگر خطای دیسک یا unit شکست‌خورده دیدید، ریشه مشکل هنوز باقی است و فقط علامتش پنهان شده.