مجله ایرانیکاسرورآموزش سرور، هاست، وردپرس و شبکه
آموزش هاست

Rescue Mode چیست؟ آموزش نجات سرور لینوکس و VPS

Rescue Mode چیست؟ راهنمای نجات سرور لینوکس تصور کنید سرور مجازی شما بعد از یک ری‌استارت بالا نمی‌آید. نه SSH کار می‌کند، نه سایت باز می‌شود. فقط یک پیام خطا روی کنسول مانده و…

Rescue Mode چیست؟ آموزش نجات سرور لینوکس و VPS
خلاصه سریع این آموزش

Rescue Mode چیست؟ راهنمای نجات سرور لینوکس تصور کنید سرور مجازی شما بعد از یک ری‌استارت بالا نمی‌آید. نه SSH کار می‌کند، نه سایت باز می‌شود. فقط یک پیام خطا…

۱۳ دقیقه مطالعه ۰ دیدگاه ۲۱ مهر ۱۴۰۵ آخرین به‌روزرسانی

Rescue Mode چیست؟ راهنمای نجات سرور لینوکس

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

این حالت مخصوص مواقعی است که سیستم‌عامل اصلی شما قادر به بالا آمدن نیست؛ مثلاً وقتی فایل fstab اشتباه ویرایش شده، فایل‌سیستم خراب شده، GRUB از کار افتاده، یا رمز Root را فراموش کرده‌اید. در چنین شرایطی Rescue Mode مثل یک اتاق عمل عمل می‌کند: سیستم اصلی خوابیده، اما شما می‌توانید با خیال راحت داخل آن را بررسی و تعمیر کنید.

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

قبل از هر تعمیری: اگر داده‌های مهمی روی سرور دارید، حتماً یک Snapshot یا نسخه پشتیبان بگیرید. در Rescue Mode شما دسترسی کامل Root دارید و یک دستور اشتباه می‌تواند خرابی را بسیار بیشتر کند. چند دقیقه صبر برای پشتیبان‌گیری، می‌تواند ساعت‌ها دردسر را کم کند.

دو مفهوم متفاوت که نباید اشتباه بگیرید

وقتی از Rescue Mode حرف می‌زنیم، در واقع دو چیز کاملاً متفاوت وجود دارد که بسیاری از افراد آن‌ها را با هم اشتباه می‌گیرند. اول systemd rescue.target که داخل همان سیستم‌عامل نصب‌شده روی سرور شما اجرا می‌شود. دوم Rescue Environment یا محیط نجات ارائه‌دهنده سرور که یک سیستم‌عامل موقت و کاملاً جدا را بوت می‌کند و به شما امکان می‌دهد دیسک اصلی را از بیرون Mount کنید.

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

Rescue Mode و Emergency Mode: کدام را انتخاب کنیم؟

systemd به شما اجازه می‌دهد با پارامترهای systemd.unit=rescue.target یا systemd.unit=emergency.target سیستم را بوت کنید. اما این دو با هم فرق دارند و انتخاب اشتباه می‌تواند وقت شما را تلف کند.

Rescue Mode یک محیط چند کاربره است که سرویس‌های ضروری سیستم را بالا می‌آورد، اما سرویس‌های غیرضروری مثل وب‌سرور، دیتابیس و شبکه را متوقف نگه می‌دارد. این حالت برای وقتی مناسب است که سیستم‌عامل تقریباً سالم است و فقط چند سرویس مشکل دارند.

Emergency Mode حداقلی‌تر است. در این حالت فقط ریشه فایل‌سیستم Mount می‌شود و تقریباً هیچ سرویسی بالا نمی‌آید. حتی ممکن است فایل‌سیستم به‌صورت فقط-خواندنی (Read-only) Mount شود. این حالت برای خرابی‌های جدی‌تر مثل خطا در Mount شدن فایل‌سیستم یا خرابی‌های شدید Boot به کار می‌آید. اگر نمی‌دانید کدام را انتخاب کنید، همیشه با Rescue شروع کنید و اگر جواب نداد، به Emergency بروید.

چه زمانی باید از Rescue Mode استفاده کنیم؟

Rescue Mode برای موقعیت‌های خاصی طراحی شده است. اگر با یکی از این موارد روبه‌رو شدید، احتمالاً وقت آن رسیده که سراغ Rescue Mode بروید:

  • خطای fstab: فایل /etc/fstab اشتباه ویرایش شده و سیستم نمی‌تواند دیسک‌ها را Mount کند.
  • خطای ext4: فایل‌سیستم به دلیل قطع برق یا خرابی سخت‌افزار آسیب دیده و نیاز به fsck دارد.
  • خرابی GRUB: بوت‌لودر خراب شده و سیستم اصلاً بالا نمی‌آید.
  • فراموشی رمز Root: رمز عبور Root را فراموش کرده‌اید و راهی برای ورود ندارید.
  • قطع SSH بعد از تغییر Port یا Firewall: تنظیمات SSH یا فایروال را طوری تغییر داده‌اید که دیگر نمی‌توانید وصل شوید.
  • سرویس خراب هنگام Boot: یک سرویس معیوب باعث می‌شود سیستم در فرایند بوت گیر کند.
  • پر شدن دیسک: دیسک ۱۰۰٪ پر شده و سیستم نمی‌تواند کارهای عادی خود را انجام دهد.
  • مشکل در Mount شدن LVM: منطق Volume Management به‌درستی Mount نمی‌شود و سیستم بوت نمی‌شود.

ورود به Rescue Mode از GRUB

ساده‌ترین راه ورود به Rescue Mode، استفاده از منوی GRUB هنگام بوت است. وقتی سیستم را روشن می‌کنید، در منوی GRUB کلید e را بزنید تا وارد ویرایشگر شوید. سپس در خطی که با linux شروع می‌شود، پارامتر زیر را به انتهای خط اضافه کنید:

systemd.unit=rescue.target

اگر به حالت حداقلی‌تر نیاز دارید، از پارامتر زیر استفاده کنید:

systemd.unit=emergency.target

سپس با Ctrl+X یا F10 بوت را ادامه دهید. سیستم با حالت انتخابی شما بالا می‌آید و از شما رمز Root می‌خواهد. اگر رمز Root را دارید، وارد می‌شوید. اگر ندارید، از روش ریست رمز Root که در ادامه توضیح می‌دهیم استفاده کنید.

تغییر Target از سیستم در حال اجرا

اگر سیستم شما هنوز در حال اجراست و می‌خواهید بدون ری‌استارت وارد Rescue Mode شوید، می‌توانید از دستور زیر استفاده کنید:

sudo systemctl isolate rescue.target

این دستور تمام سرویس‌های عادی را متوقف می‌کند و سیستم را به حالت Rescue می‌برد. اما حتماً توجه کنید که این کار تمام سرویس‌های فعال شما را قطع می‌کند. اگر روی سرور Production هستید، این دستور را بدون یک Maintenance Window برنامه‌ریزی‌شده اجرا نکنید، چون ممکن است کاربران شما را غافلگیر کند. برای برگشت به حالت عادی، کافی است دستور systemctl isolate multi-user.target یا systemctl isolate graphical.target را اجرا کنید.

Rescue Provider: پیدا کردن Disk اصلی

اگر از Rescue Environment ارائه‌دهنده استفاده می‌کنید، بعد از بوت شدن وارد یک سیستم‌عامل موقت می‌شوید. اولین کاری که باید انجام دهید، پیدا کردن نام دقیق دیسک اصلی است. هرگز نام Device را حدس نزنید، چون ممکن است روی دیسک اشتباه کار کنید و داده‌ها را از دست بدهید. برای پیدا کردن دیسک‌ها از این دستورها استفاده کنید:

lsblk -f
blkid
fdisk -l

خروجی lsblk -f به شما نشان می‌دهد که هر پارتیشن چه فایل‌سیستمی دارد و UUID آن چیست. دستور blkid هم همین اطلاعات را با جزئیات بیشتر نمایش می‌دهد. بعد از پیدا کردن نام دیسک، آن را Mount کنید:

sudo mkdir -p /mnt/root
sudo mount /dev/vda2 /mnt/root
ls -lah /mnt/root

توجه کنید که /dev/vda2 فقط یک مثال است. نام دیسک شما ممکن است /dev/sda1، /dev/nvme0n1p2 یا چیز دیگری باشد. اگر از LVM استفاده می‌کنید، ممکن است لازم باشد اول Volume Group را فعال کنید:

sudo vgscan
sudo vgchange -ay
sudo lvs

سپس Logical Volume را Mount کنید، مثلاً /dev/vg0/root. اگر از فایل‌سیستم رمزنگاری‌شده LUKS استفاده می‌کنید، باید اول آن را باز کنید:

sudo cryptsetup luksOpen /dev/vda3 cryptroot
sudo mount /dev/mapper/cryptroot /mnt/root

تعمیر fstab

یکی از رایج‌ترین دلایل بوت نشدن سرور، اشتباه در فایل /etc/fstab است. اگر این فایل خراب باشد، سیستم نمی‌تواند دیسک‌ها را Mount کند و در فرایند بوت گیر می‌کند. برای تعمیر، فایل را باز کنید:

sudo nano /mnt/root/etc/fstab

UUIDهای نوشته‌شده در این فایل را با خروجی blkid مقایسه کنید. اگر UUID اشتباه است، آن را اصلاح کنید. اگر یک Mount مشکل‌دار دارید که باعث گیر کردن بوت می‌شود، می‌توانید آن خط را موقتاً با # کامنت کنید تا سیستم بوت شود و بعداً مشکل را ریشه‌ای حل کنید. همچنین گزینه‌های Mount مثل defaults، noatime یا errors=remount-ro را بررسی کنید.

تعمیر SSH

اگر بعد از تغییر تنظیمات SSH یا فایروال، دسترسی خود را از دست داده‌اید، Rescue Mode بهترین فرصت برای برگرداندن تنظیمات است. فایل تنظیمات SSH را باز کنید:

sudo nano /mnt/root/etc/ssh/sshd_config

مطمئن شوید که پورت درست است، احراز هویت با کلید یا رمز به‌درستی تنظیم شده و IPهای مجاز اشتباه وارد نشده‌اند. برای تست صحت Syntax فایل، باید داخل محیط Chroot بروید. Chroot یعنی تغییر ریشه فایل‌سیستم به دیسک اصلی شما، طوری که دستورات به‌جای دیسک Rescue، روی دیسک اصلی اجرا شوند. برای این کار:

sudo mount --bind /dev /mnt/root/dev
sudo mount --bind /proc /mnt/root/proc
sudo mount --bind /sys /mnt/root/sys
sudo chroot /mnt/root
sshd -t
exit

دستور sshd -t فقط فایل تنظیمات را بررسی می‌کند و اگر خطایی باشد، به شما می‌گوید. بعد از اصلاح، از Chroot خارج شوید و تغییرات را ذخیره کنید.

ریست رمز Root

اگر رمز Root را فراموش کرده‌اید، Rescue Mode راه‌حل سریع و امنی است. بعد از Mount کردن دیسک اصلی و ورود به Chroot، دستور زیر را اجرا کنید:

sudo chroot /mnt/root
passwd root
exit

سیستم از شما رمز جدید می‌خواهد. حتماً یک رمز قوی انتخاب کنید و آن را در جای امنی نگه دارید. اگر رمز Root را روی یک سرور Production تغییر می‌دهید، مطمئن شوید که سایر اعضای تیم هم از رمز جدید باخبر شوند، یا از سیستم مدیریت رمز مشترک استفاده کنید.

تعمیر ext4 و سایر فایل‌سیستم‌ها

اگر فایل‌سیستم شما به دلیل قطع برق یا خرابی سخت‌افزار آسیب دیده، می‌توانید با fsck آن را تعمیر کنید. اما قبل از هر کاری، مطمئن شوید که فایل‌سیستم Mount نشده است:

mount | grep vda2
sudo umount /dev/vda2
sudo fsck -f /dev/vda2

پارامتر -f باعث می‌شود fsck حتی اگر فایل‌سیستم سالم به نظر برسد، باز هم بررسی کامل انجام دهد. اگر fsck از شما سؤال پرسید، با دقت پاسخ دهید. در بیشتر موارد، پاسخ y برای تعمیر خودکار مناسب است، اما اگر داده‌های مهمی دارید و مطمئن نیستید، بهتر است اول یک نسخه پشتیبان بگیرید.

هشدار مهم: هرگز fsck را روی فایل‌سیستمی که Mount شده اجرا نکنید. این کار می‌تواند به داده‌ها آسیب جدی بزند. همچنین توجه کنید که XFS، ZFS و Btrfs ابزارهای تعمیر متفاوتی دارند و نباید از fsck برای آن‌ها استفاده کنید. برای XFS از xfs_repair، برای Btrfs از btrfs check و برای ZFS از zpool scrub استفاده کنید.

وقتی دیسک ۱۰۰٪ پر شده است

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

df -h
du -xhd1 /mnt/root/var | sort -h
du -xhd1 /mnt/root | sort -h

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

تعمیر GRUB

اگر GRUB خراب شده و سیستم اصلاً بوت نمی‌شود، بعد از ورود به Rescue Environment و Mount کردن دیسک اصلی، باید Chroot کنید و GRUB را دوباره نصب کنید. مراحل به این صورت است:

sudo mount --bind /dev /mnt/root/dev
sudo mount --bind /proc /mnt/root/proc
sudo mount --bind /sys /mnt/root/sys
sudo chroot /mnt/root
grub-install /dev/vda
update-grub
exit

دستور grub-install بوت‌لودر را روی دیسک نصب می‌کند و update-grub فایل تنظیمات GRUB را بازسازی می‌کند. توجه کنید که /dev/vda باید نام دیسک اصلی شما باشد، نه پارتیشن. بعد از این کارها، از Chroot خارج شوید و سیستم را ری‌استارت کنید.

بعد از تعمیر: کارهایی که باید انجام دهید

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

  1. Configها را بازبینی کنید: مطمئن شوید که فایل‌هایی مثل fstab و sshd_config درست ذخیره شده‌اند و هیچ خطای نگارشی ندارند.
  2. از Chroot خارج شوید: اگر داخل Chroot هستید، با دستور exit خارج شوید.
  3. Mountها را Unmount کنید: با دستور umount /mnt/root و در صورت نیاز umount -R /mnt/root برای Unmount کردن تمام Mountهای داخلی.
  4. Rescue Provider را غیرفعال کنید: اگر از Rescue Environment ارائه‌دهنده استفاده می‌کردید، آن را غیرفعال کنید تا سیستم دوباره از دیسک اصلی بوت شود.
  5. Reboot و تست کنید: سیستم را ری‌استارت کنید و مطمئن شوید که Console و SSH هر دو کار می‌کنند.
  6. مستندسازی کنید: بنویسید چه مشکلی پیش آمده و چه تغییری دادید. این کار در آینده به شما و هم‌تیمی‌هایتان کمک می‌کند.

اشتباهات رایج در Rescue Mode

Rescue Mode ابزار قدرتمندی است، اما اگر با دقت استفاده نشود، می‌تواند خرابی را بیشتر کند. این اشتباهات را جدی بگیرید:

  • حدس زدن نام دیسک: هرگز بدون بررسی با lsblk و blkid روی دیسکی کار نکنید.
  • اجرای fsck روی فایل‌سیستم Mount شده: این کار می‌تواند داده‌ها را نابود کند.
  • ویرایش فایل‌ها بدون پشتیبان: قبل از ویرایش fstab یا sshd_config، یک کپی از نسخه سالم بگیرید.
  • فراموش کردن Unmount: اگر Mountها را Unmount نکنید، تغییرات ممکن است ذخیره نشوند یا فایل‌سیستم آسیب ببیند.
  • استفاده از fsck برای XFS یا Btrfs: هر فایل‌سیستم ابزار تعمیر مخصوص خودش را دارد.
  • اجرای دستورات روی Production بدون هماهنگی: اگر سرور در حال سرویس‌دهی است، اول با تیم هماهنگ کنید.

قبل از تغییرات پرریسک، مسیر نجات داشته باشید

داشتن Console، نسخه پشتیبان و ثبت تغییرات SSH و fstab برای هر VPS Production ضروری است. اگر سرور شما به Rescue Mode نیاز پیدا کرد، بهتر است بدانید که کدام نسخه سیستم‌عامل، کدام پارتیشن‌بندی و کدام تنظیمات شبکه را دارید تا سریع‌تر مشکل را حل کنید.

تماس با پشتیبانی ایرانیکاسرور: 021-91302467

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

Rescue Mode چیست؟

یک محیط حداقلی برای تعمیر لینوکس که یا داخل همان سیستم‌عامل با systemd rescue.target اجرا می‌شود، یا توسط ارائه‌دهنده سرور به‌صورت یک محیط جداگانه بوت می‌شود.

Rescue و Emergency چه فرقی دارند؟

Emergency حداقلی‌تر است و ممکن است ریشه فایل‌سیستم را فقط-خواندنی Mount کند. Rescue کمی کامل‌تر است و سرویس‌های ضروری را بالا می‌آورد.

آیا Rescue Mode فایل‌ها را پاک می‌کند؟

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

وقتی SSH بالا نمی‌آید، Rescue Mode مفید است؟

بله. اگر Console یا Rescue Provider دارید، می‌توانید sshd_config، فایروال یا fstab را تعمیر کنید و دسترسی SSH را برگردانید.

آیا می‌توان fsck را روی فایل‌سیستم Mount شده اجرا کرد؟

برای ext4 بهتر است فایل‌سیستم Unmount باشد. برای XFS و Btrfs هم ابزارهای متفاوتی وجود دارد و نباید از fsck استفاده کرد.

بعد از تعمیر چه کارهایی باید انجام داد؟

تنظیمات را بررسی کنید، از Chroot خارج شوید، Mountها را Unmount کنید، Rescue Provider را غیرفعال کنید و سیستم را ری‌استارت کنید تا بوت عادی برگردد.

اگر رمز Root را فراموش کرده‌ام چه کنم؟

با ورود به Rescue Mode، Mount کردن دیسک اصلی، Chroot و اجرای دستور passwd root می‌توانید رمز جدید تنظیم کنید.

منابع

مستندات رسمی systemd درباره rescue.target و emergency.target و روش‌های عیب‌یابی بوت.
مستندات کامل GRUB برای تعمیر بوت‌لودر و بازسازی تنظیمات.
مستندات رسمی fsck و نکات مهم درباره تعمیر فایل‌سیستم‌های مختلف.

جمع‌بندی

Rescue Mode یک ابزار نجات حیاتی برای هر مدیر سرور است. ابتدا نوع خرابی و دیسک واقعی را مشخص کنید، بعد کمترین تغییر لازم را انجام دهید. برای بوت کامل خراب، Rescue Provider ارائه‌دهنده معمولاً امن‌تر از دستکاری مستقیم سیستم‌عامل است. و مهم‌تر از همه، همیشه قبل از تعمیر، پشتیبان بگیرید و بعد از تعمیر، تغییرات را مستند کنید.

سرور بالا نمی‌آید؟

خروجی Console، خروجی lsblk و پیام خطای بوت را ذخیره کنید. با داشتن این اطلاعات می‌توانیم سریع‌تر به شما کمک کنیم.

تماس با پشتیبانی ایرانیکاسرور: 021-91302467

اشتراک‌گذاری مقاله
گفت‌وگو درباره آموزش

دیدگاه‌ها (۰)

هنوز دیدگاهی ثبت نشده است.

دیدگاه یا سؤال خود را بنویسید

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