Linode Rescue Mode 与 Rebuild：救援磁盘、检查文件系统和恢复数据

· 更新于 · 发布：iVPSer · Linode、Linux教程

Linode 无法正常启动时，可以先用 Rescue Mode 读取现有磁盘、复制数据或修复配置。Rescue Mode 会启动临时 Finnix 环境，不会主动删除实例磁盘。Rebuild 则会删除当前磁盘并重新部署系统。

Rebuild 会删除当前磁盘，删除后的数据无法找回。没有经过验证的实例外备份时，不要把 Rebuild 当成普通排障按钮。

先判断应该走哪条恢复路径

现象优先动作
实例在运行，但公网或 SSH 不通先查 Cloud Manager 状态、Lish、Cloud Firewall、主机防火墙和 SSH 日志
系统无法启动、配置损坏或需要离线检查磁盘进入 Rescue Mode
已有可用备份优先恢复到测试实例，验证后再决定切换
疑似未经授权的入侵新建全新实例，只迁移经过检查的数据与密钥，不继续信任旧系统
已完成实例外备份且决定从零部署最后才考虑 Rebuild

Rescue Mode 适合离线检查，不会自动判断根因。先保存 Cloud Manager 的 Activity Feed、启动日志、当前 Configuration Profile、磁盘名称与挂载关系，避免排障时失去原始证据。

进入 Rescue Mode 前的检查

  1. 在 Cloud Manager 验证 Launch Console / Lish 能打开。
  2. 记录正常启动所用的 Configuration Profile，以及每个磁盘对应的 /dev/sda、/dev/sdb 等位置。
  3. 若仍能读取数据，先创建实例外备份；同一故障磁盘上的压缩包不是备份。
  4. 记录 Block Storage、加密、Cloud Firewall 和应用依赖，避免只恢复系统盘却遗漏数据盘。

如果只是忘记密码或 SSH 配置错误，Lish 可能已经足够。不要为了一个可以在线修复的问题直接进入 Rebuild。

启动 Rescue Mode 并确认磁盘映射

在 Cloud Manager 的 Rescue 表单中，将磁盘分配到与正常 Configuration Profile 相同的设备位置，并记下本次映射，例如系统盘被分配为 /dev/sda。

Akamai 当前文档说明，Rescue Mode 最多可分配多个磁盘，Finnix 自身使用单独设备。设备名不匹配可能使 chroot 按错误的 /etc/fstab 位置挂载磁盘，因此不要沿用旧教程里的 /dev/xvda 假设。

点击 Reboot into Rescue Mode，等待实例重新显示为 Running，再通过 Lish 进入 Finnix。先读取实际状态：

lsblk -f
blkid
findmnt

把 Cloud Manager 的磁盘标签、容量、文件系统和这里的输出逐项对应。本文后续用 /dev/sda 举例；只有本次 Rescue 映射与 lsblk -f 都确认它是目标系统盘时，才可使用。

先只读挂载并复制重要数据

先把设备保存为变量，避免后续命令混用不同磁盘。若实际设备不是 /dev/sda，先替换右侧值，并确认它尚未挂载：

ROOT_DEVICE=/dev/sda
if findmnt --source "$ROOT_DEVICE" >/dev/null; then
  echo '目标设备仍在挂载，停止操作' >&2
  exit 1
fi
blockdev --setro "$ROOT_DEVICE"
test "$(blockdev --getro "$ROOT_DEVICE")" -eq 1 || exit 1
lsblk -f "$ROOT_DEVICE"

普通的 mount -o ro 仍可能让 ext3/ext4 回放 journal。确认 FSTYPE 是 ext2、ext3 或 ext4 后，使用 noload 禁止回放，再挂载：

mkdir -p /mnt/linode-root
mount -o ro,noload "$ROOT_DEVICE" /mnt/linode-root
findmnt /mnt/linode-root

blockdev --setro 让块设备拒绝写入，ro,noload 避免 ext journal 恢复。XFS、Btrfs、LVM、加密盘或其他类型应停止使用这个挂载示例，改查对应文件系统的只读且不恢复日志选项。

挂载成功后，先检查业务数据、数据库文件、配置与日志是否存在。优先把不可替代的数据复制到另一台服务器、对象存储或本地设备，再尝试会写入磁盘的修复。

ls -la /mnt/linode-root
du -sh /mnt/linode-root/home /mnt/linode-root/var 2>/dev/null

需要整个磁盘镜像时，使用通过 SSH 复制 Linode 磁盘；不要把镜像写回同一块源磁盘。

文件系统检查只在未挂载时执行

e2fsck 只适用于 ext2/ext3/ext4 文件系统，并且只能对未挂载的目标设备执行。先核对 lsblk -f 的 FSTYPE，卸载目标盘，并确认它没有任何挂载点：

umount /mnt/linode-root || { echo '卸载失败，停止文件系统检查' >&2; exit 1; }
if findmnt --source "$ROOT_DEVICE" >/dev/null; then
  echo '目标设备仍在挂载，停止文件系统检查' >&2
  exit 1
fi
e2fsck -n "$ROOT_DEVICE"

findmnt 没有输出，才表示该设备当前未挂载。e2fsck -n 只做不写入的初步检查；它不能代替备份，也不能保证文件内容完整。

如果确认是 ext 文件系统、实例外数据副本已完成，并决定修复，再运行交互式检查：

blockdev --setrw "$ROOT_DEVICE"
test "$(blockdev --getro "$ROOT_DEVICE")" -eq 0 || exit 1
e2fsck -f "$ROOT_DEVICE"

逐项阅读修复提示，不要机械添加 -y。XFS、Btrfs 或其他文件系统必须使用各自官方工具，不能运行 e2fsck。

仅在确有需要时启用 Rescue SSH

Finnix 默认不接受 SSH。只有 SFTP、rsync 或整盘复制确实需要网络传输时，才从 Lish 设置临时密码并启动 Rescue 环境的 SSH：

passwd
service ssh start

Finnix 的 root 密码只属于本次临时救援环境，不会修改原系统磁盘上的 root 密码。Cloud Firewall 应只允许当前管理来源访问实际 SSH 端口，不要把 Rescue root 登录开放给整个互联网。

传输完成后停止临时 SSH，并删除为 Rescue 临时增加的防火墙规则：

service ssh stop

返回正常启动并验证

结束前同步写入并卸载仍然挂载的磁盘：

sync
if findmnt /mnt/linode-root >/dev/null; then
  umount /mnt/linode-root || { echo '卸载失败，停止退出 Rescue' >&2; exit 1; }
fi
if findmnt --source "$ROOT_DEVICE" >/dev/null; then
  echo '目标设备仍在挂载，停止退出 Rescue' >&2
  exit 1
fi
blockdev --setrw "$ROOT_DEVICE"

上面的 findmnt 条件应不成立；若卸载失败，应先处理占用进程，不能带着未完成的写入直接启动。随后在 Cloud Manager 关机，明确选择原 Configuration Profile 再启动。

通过 Lish 观察启动日志。实例显示 Running 后，还要确认系统和服务确实恢复正常。

至少验证根文件系统、网络地址、SSH、失败服务、数据库和真实业务请求。若验证失败，再次进入 Rescue Mode 时保持相同设备映射，并依据已保存的证据回滚配置或恢复备份。

什么时候才使用 Rebuild

只有数据已经复制到实例外、备份可恢复，且明确接受删除当前磁盘时才使用 Rebuild。更稳妥的做法通常是在新实例恢复并验证，再切换流量，而不是先破坏唯一源盘。

疑似入侵时不要在旧系统上“修好后继续用”。应新建全新实例，轮换密码、SSH 密钥、API Token 与应用密钥，只迁移经过审查的数据，并保留旧实例用于取证或受控清理。

iVPSer 使用边界

iVPSer 控制台可用于查看当前可选实例方案；Rescue、磁盘映射、文件系统修复、应用恢复和数据验证由使用者在 Akamai Cloud Manager 与实例内完成。库存、系统和实例能力以实时控制台为准。

👉 立即购买 Linode VPS

参考文档