VPS 救援模式Rescue Mode怎么用：SSH 进不去时用 Rescue Mode、chroot、fsck、GRUB 自救
-
VPS 出问题时，最让人慌的不是网站 502，而是 SSH 完全进不去。比如你改错了
/etc/fstab，重启后系统卡在启动界面；或者防火墙规则写错，SSH 端口被自己挡住；再或者 root 密码忘了、GRUB 损坏、文件系统需要fsck。这类问题用普通 SSH 排查不了，因为系统根本没正常起来。这时候不要第一反应就重装。很多 VPS 控制台都有 Rescue Mode / 救援模式：它会从一个临时系统启动，把你原来的系统盘挂出来，让你站在“外部系统”的角度修复原系统。用得好，可以救回配置、重置密码、修复启动项，甚至把重要数据先拷出来。
救援模式不是你的原系统，也不是简单的网页终端。它通常是服务商提供的一个临时 Linux 环境，启动后会把原来的 VPS 磁盘当作数据盘呈现出来。
你可以把它理解成：
原系统坏了，先不从原系统启动。
服务商给你启动一个干净的小系统。
你在这个小系统里挂载原来的磁盘。
然后修改原系统里的文件、修复启动、拷贝数据。
它和 VNC/控制台也不一样。VNC 是看原系统屏幕；Rescue Mode 是换一个临时系统来修原盘。很多时候这两者要配合用：先用 VNC 看启动卡在哪里，再进救援模式修。
下面这些场景适合用 Rescue Mode：
场景 是否适合 SSH 密码忘了，需要重置 root 密码 适合 /etc/fstab写错，系统启动失败适合 GRUB / initramfs 异常，VPS 进不了系统 适合 文件系统损坏，需要离线 fsck 适合 防火墙/SSH 配置写错，自己锁在外面 适合 网站 502、Nginx 配置错误 通常不需要，先普通 SSH 排查 磁盘满了但还能 SSH 不一定需要，先在线清理 一个简单判断：如果原系统还能 SSH 进去，就优先在线排查；如果原系统进不去、启动不了、根分区不能安全修，就考虑救援模式。
第一，能做快照就先做快照。救援模式里会改原系统文件，一旦你误删或
fsck操作不当，可能造成数据损失。第二，先看控制台/VNC。确认系统是卡在启动、密码问题、防火墙问题，还是文件系统问题。不要一上来就乱跑
fsck。如果是疑似入侵事件，先保留证据：不要立刻重启，不要清日志，尽量先做快照或磁盘镜像。救援模式会改变挂载状态和部分时间戳，取证场景要更谨慎。
不同服务商入口不一样，但名称通常类似：
Rescue Mode
Boot to rescue
Recovery mode
Rescue ISO
VNC + ISO
启用后，VPS 会重启到临时系统。部分服务商会把临时 root 密码发到邮箱，部分会在控制台里显示登录信息。进入救援系统后，先看磁盘：
lsblk fdisk -l
常见磁盘名包括：
/dev/vda/dev/sda/dev/nvme0n1
分区可能是
/dev/vda1、/dev/sda1、/dev/nvme0n1p1。不要照抄命令里的设备名，先用lsblk确认。假设根分区是
/dev/vda1：mkdir -p /mnt/sysroot mount /dev/vda1 /mnt/sysroot
如果系统有单独的
/boot分区，也要挂载：mount /dev/vda2 /mnt/sysroot/boot
如果是 LVM，需要先激活卷组：
vgscan vgchange -ay lsblk
然后再挂载对应的逻辑卷。
挂载后先确认是不是原系统：
ls /mnt/sysroot cat /mnt/sysroot/etc/os-release
如果能看到
etc、var、home、usr，基本就是原系统根目录。很多修复操作需要在原系统环境里执行，这时要绑定几个系统目录：
mount --bind /dev /mnt/sysroot/dev mount --bind /proc /mnt/sysroot/proc mount --bind /sys /mnt/sysroot/sys mount --bind /run /mnt/sysroot/runchroot /mnt/sysroot /bin/bash
进入后，你看到的
/就是原系统根目录。现在可以像登录原系统一样改配置。在 chroot 里执行：
passwd root
如果系统禁用了 root SSH 登录，还要检查：
nano /etc/ssh/sshd_config
重点看：
PermitRootLogin PasswordAuthentication
不要为了省事长期开启 root 密码登录。更稳妥的做法是重置后登录一次，重新配置密钥，再关闭密码登录。
如果你改错了
/etc/fstab，系统可能会卡在 emergency mode。进入 chroot 后检查：nano /etc/fstab
临时排查时，可以先把可疑挂载行注释掉。尤其是新加的数据盘、网络盘、对象存储挂载、错误 UUID。
查看分区 UUID：
blkid
确认无误后再写回
fstab。不要把救援系统里的设备名当成永久配置，最好用 UUID。fsck一定要谨慎。原则是：不要对已经挂载的分区直接 fsck。如果你已经挂载了根分区，先退出 chroot 并卸载：
exitumount /mnt/sysroot/run umount /mnt/sysroot/sys umount /mnt/sysroot/proc umount /mnt/sysroot/dev umount /mnt/sysroot
然后再执行：
fsck -f /dev/vda1
如果确定要自动回答 yes：
fsck -fy /dev/vda1
但对重要数据盘，不建议一上来就
-y。先看报错，再决定是否自动修。如果 VNC 里看到
grub rescue>、找不到内核、升级内核后启动失败，可以尝试重装 GRUB。先重新挂载并进入 chroot：
mount /dev/vda1 /mnt/sysroot mount --bind /dev /mnt/sysroot/dev mount --bind /proc /mnt/sysroot/proc mount --bind /sys /mnt/sysroot/sys mount --bind /run /mnt/sysroot/runchroot /mnt/sysroot /bin/bash
BIOS 启动的常见修复：
grub-install /dev/vda update-grub
注意：
grub-install后面通常是磁盘/dev/vda，不是分区/dev/vda1。如果是 UEFI 机器，路径和命令可能不同，需要确认 EFI 分区是否挂载到
/boot/efi。不确定时先看：lsblk -f findmnt /boot/efi
场景五：SSH 配置或防火墙把自己锁了
如果你改错了 SSH 端口、防火墙规则或
sshd_config，可以在 chroot 中修：nano /etc/ssh/sshd_config
也可以先禁用危险的防火墙规则。比如 UFW：
ufw disable
如果用的是 iptables/nftables，救援环境里不一定能完整反映原系统运行状态。更可靠的做法是修改原系统的规则文件或启动脚本，而不是只看当前临时环境。
修完后不要直接在面板点重启，先按顺序退出和卸载：
exitumount /mnt/sysroot/run umount /mnt/sysroot/sys umount /mnt/sysroot/proc umount /mnt/sysroot/dev umount /mnt/sysroot/boot 2>/dev/null umount /mnt/sysroot
如果提示 busy，先查谁占用：
lsof +f -- /mnt/sysroot
确认卸载完成后，到服务商面板关闭 Rescue Mode，切回硬盘启动，再重启 VPS。
启动后第一时间检查：
systemctl --failed journalctl -b -p warning ss -lntp
确认 SSH、网站、数据库都正常，再删临时弱密码、恢复防火墙、安全组和备份计划。
你的机器可能是
/dev/vda1，也可能是/dev/sda1或/dev/nvme0n1p1。永远先看lsblk。这是最危险的误操作之一。要么先卸载，要么确认该分区没被挂载。
修完后如果不切回硬盘启动，下一次还是进救援系统，看起来像“没修好”。
救急可以，长期不建议。恢复后应重新配置 SSH 密钥、关闭密码登录、限制登录来源。
救援模式不是万能药，但它是 VPS 用户必须会的最后一道保险。它最适合处理三类问题：启动失败、自己锁在外面、原系统文件需要离线修复。
真正稳妥的流程是：先看控制台判断问题，再做快照，进入 Rescue Mode，挂载原系统，必要时 chroot，修完后正确卸载并切回硬盘启动。只要你不盲目
fsck -y、不乱删文件，大多数“SSH 进不去只能重装”的场景，其实都还有救。推荐阅读
- 上一篇： WPS为PDF文档每一页批量添加签名的技巧
- 下一篇： 为什么Word目录左边对不齐
文章标签：
版权声明： 本文除特别说明外均由 麒麟在线 原创
本文链接： https://www.70ol.com/jishu/368.html，尊重共享，欢迎转载，请自觉添加本文链接，谢谢!
分享本文： 请填写您的分享代码。
呃 本文暂时没人评论 来添加一个吧
发表评论