挂载引导卷修复 OCI 实例

在系统无法启动或登录时，将 OCI 引导卷作为数据卷附加到救援实例，按只读优先方式修复配置并安全重挂。

#type / howto #status / growing #tech / ops #resource / oracle-cloud #platform / server #platform / linux

[!danger] 高风险操作 停机、分离和重新附加错误的引导卷可能造成更长停机或数据损坏。操作前按 OCID 确认源实例、卷和救援实例，创建可用备份，并禁止使用硬编码的 /dev/sdb2 猜设备。

挂载引导卷修复 OCI 实例

目标

在普通 SSH、Run Command 和控制台连接都无法恢复时：

  1. 安全停止故障实例；
  2. 把引导卷作为数据卷附加到救援实例；
  3. 先只读识别分区和数据；
  4. 备份后修复 SSH、网络、fstab 或防火墙配置；
  5. 卸载、分离并重新作为原实例引导卷；
  6. 启动并完成回归验证。

前置条件

  • 救援实例与引导卷位于兼容的 Availability Domain；
  • 救援实例可以正常 SSH；
  • 有块存储附加/分离权限；
  • 故障实例的 Boot Volume OCID 已记录；
  • 有最新备份或接受停机风险；
  • 对 Linux 分区、mount 和权限有基本理解。

1. 保存证据并创建备份

记录：

Broken instance OCID:
Boot volume OCID:
Rescue instance OCID:
Availability Domain:
Original attachment type:
Original device/path:
Failure time and last change:

如果平台允许，先创建引导卷手动备份。备份是 crash-consistent，不保证应用一致，但比直接修改唯一卷安全。

2. 停止故障实例

在 Compute 控制台执行 Stop，等待状态明确变为 Stopped。不要在仍运行时强制分离引导卷。

3. 分离引导卷

进入故障实例的 Boot Volume 资源页，按 OCID 确认目标后 Detach。等待 attachment 状态变为 Detached。

4. 作为数据卷附加到救援实例

在 Boot Volume 详情选择 Attach to instance，将其附加到救援实例：

  • 优先 Paravirtualized，除非场景要求 iSCSI；
  • 初始能选择只读访问时优先只读；
  • 不替换救援实例自己的引导卷；
  • 等待 Attached 后再进入系统。

5. 在救援机识别新设备

附加前后比较：

lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS,MODEL
sudo blkid
sudo dmesg --ctime | tail -n 80

根据大小、UUID、分区表和附加时间识别，不根据论坛示例猜 /dev/sdb2。

设置变量示例：

RESCUE_PARTITION=/dev/sdb2  # 必须替换为实际确认的分区
sudo install -d -m 700 /mnt/oci-rescue

6. 只读挂载和检查

ext4：

sudo mount -o ro,noload "$RESCUE_PARTITION" /mnt/oci-rescue

XFS：

sudo mount -o ro,norecovery "$RESCUE_PARTITION" /mnt/oci-rescue

检查：

findmnt /mnt/oci-rescue
sudo ls -la /mnt/oci-rescue
sudo sed -n '1,160p' /mnt/oci-rescue/etc/fstab
sudo find /mnt/oci-rescue/etc/ssh -maxdepth 2 -type f -printf '%p\n'

先复制重要配置和数据到独立备份，再决定读写修复。

7. 切换读写并修复

卸载只读挂载，再按确认的文件系统读写挂载：

sudo umount /mnt/oci-rescue
sudo mount "$RESCUE_PARTITION" /mnt/oci-rescue

修复 SSH 配置

stamp=$(date +%Y%m%d-%H%M%S)
sudo cp -a /mnt/oci-rescue/etc/ssh "/mnt/oci-rescue/etc/ssh.rescue-$stamp"
sudoedit /mnt/oci-rescue/etc/ssh/sshd_config
sudo find /mnt/oci-rescue/etc/ssh/sshd_config.d -maxdepth 1 -type f -print 2>/dev/null

重点检查非法端口、重复 Include、AllowUsers、密钥认证和语法错误。不要删除整个 SSH 目录。

恢复公钥

以 operator 为例：

sudo install -d -m 700 -o 1000 -g 1000 /mnt/oci-rescue/home/operator/.ssh
printf '%s\n' 'ssh-ed25519 AAAA... trusted-client' | sudo tee /mnt/oci-rescue/home/operator/.ssh/authorized_keys >/dev/null
sudo chmod 600 /mnt/oci-rescue/home/operator/.ssh/authorized_keys
sudo chown -R 1000:1000 /mnt/oci-rescue/home/operator/.ssh

先从 /mnt/oci-rescue/etc/passwd 查实际 UID/GID，不盲用 1000。只写入本地已有公钥，绝不把私钥复制到服务器。

修复 fstab

错误 UUID 会让系统进入 emergency mode。用 blkid 与 fstab 对照，注释非关键错误挂载时保留备份和原因。

文件系统检查

fsck 必须在分区未挂载时执行，并先有备份：

sudo umount /mnt/oci-rescue
sudo fsck -fn "$RESCUE_PARTITION"  # 只读检查

只有理解报告和风险后才进行写修复。

8. 卸载并分离

sync
sudo umount /mnt/oci-rescue
lsblk -o NAME,MOUNTPOINTS

确认目标分区没有挂载，再从 OCI 控制台把该卷从救援实例 Detach。

9. 重挂原实例并启动

按照 Oracle 官方 Boot Volume Attachment 流程，把卷重新作为故障实例的引导卷附加。确认 attachment 状态和 OCID 后启动实例。

先观察 Console History，再测试 SSH。

回归验证

  • 实例完成启动且无文件系统错误
  • SSH 新会话成功
  • sudo 成功
  • sshd -t 通过
  • 网络、UFW 和服务符合预期
  • 数据完整且应用启动
  • 救援机没有残留挂载或敏感数据
  • 临时公钥和宽松规则已清理
  • 创建新的已知良好备份
创建于 2026/7/20 更新于 2026/7/20