Dell PowerEdge R730 RAID 故障及 Ubuntu 启动恢复实录

故障类型：PERC H730P Mini RAID 配置异常、Ubuntu UEFI 启动失败、EXT4 文件系统不一致
设备：Dell PowerEdge R730；iDRAC8；Dell PERC H730P Mini
操作系统：Ubuntu 22.04.5 LTS（根据恢复后的登录界面）
记录范围：从控制器和磁盘检查、Foreign 配置导入，到 Ubuntu 恢复登录。内容根据现场截图与对话复盘；个别日期、具体原因及数据完整性未独立验证。

一、故障现象与恢复结果

服务器无法正常启动，屏幕一度提示 No boot device available or Operating System detected；iDRAC 显示 RAID 5 虚拟磁盘 GenericR5_0 为 Failed。检查发现五块物理磁盘中多块处于 Foreign（外来配置） 状态。后续通过 PERC 控制器 预览并导入原有 Foreign 配置，RAID 5 最终显示 Ready，三块 SAS 成员盘均为 Online。

首次尝试 Ubuntu 启动时，出现 Failed to open \EFI\ubuntu\grubx64.efi - Device Error；后续再次启动已能读取内核，但根文件系统 EXT4 检查失败，进入 (initramfs)。执行手动 fsck.ext4 修复并二次检查后，系统成功进入 Ubuntu 命令行登录界面并登录。

最终已证实：RAID 5 可被控制器识别；Ubuntu 系统可启动并登录。仍待确认：RAID 1 处于 Degraded、业务应用和数据完整性、网络配置以及持续出现的 OverlayFS 提示。

二、初步排查 RAID 和硬件

1. 检查虚拟磁盘

通过 iDRAC8 的 存储 → 虚拟磁盘，发现系统中存在名为 GenericR5_0 的虚拟磁盘，信息如下：

2. 检查内存告警（同期独立故障）

Lifecycle Log 曾报告 DIMM_A1 多位 ECC 错误、DIMM_A2 可纠正 ECC 错误次数超阈值，同时出现 Memory Reference Code（MRC）提示。随后 iDRAC 显示 A1、A2、B1、B2 四条 16GB 内存均被识别，总计 64GB。

此处只能证明内存当时重新被识别，不能据此证明内存本体或插槽故障已根治；它与 RAID 异常也不能直接建立因果关系。

3. 检查五块物理盘及 Foreign 状态

其中前三块约 1.2TB 的 SAS 盘与 RAID 5 容量吻合：(3-1) × 1117.25 GB = 2234.50 GB。但盘位与磁盘组对应关系最终仍以 PERC 配置预览为准。

存储事件日志记录 A foreign configuration was detected on Integrated RAID Controller 1，并记录若干磁盘重新识别事件。日志中的 inserted 不足以单独证明现场有人拔插过磁盘。

三、尝试启动失败，确认需要先处理 RAID

系统启动菜单存在 ubuntu 条目，但先后出现无启动设备及 Ubuntu 引导失败提示。由于 RAID 5 当时为 Failed，优先处理存储阵列，而不是直接重装操作系统或改写启动项。

导入前的阵列成员状态

在 System Setup → Device Settings → PERC H730P Mini → Virtual Disk Management → View Associated Physical Disks，原 RAID 5 曾只显示一块 Online，另外两个成员位置为 Removed。

四、预览 Foreign 配置并恢复原阵列

1. 进入配置预览

使用服务器本地 F2 菜单，进入：

System Setup
  → Device Settings
  → Integrated RAID Controller 1: PERC H730P Mini
  → Configuration Management
  → Manage Foreign Configuration
  → Preview Foreign Configuration

预览发现导入后计划识别的三个虚拟磁盘：

预览警告内容包含 Possible outdated Physical Disk data 以及建议找回缺失成员磁盘。界面底部明确说明 Imports all foreign configurations，因此这一步不是仅导入 RAID 5，还涉及其他外来磁盘组。

数据安全提醒：Foreign 导入通常不会主动格式化或初始化原数据，但会更改控制器识别的阵列配置；错误导入、过期成员盘、后续自动重建均可能造成数据不一致。现场确认存在备份后进行了导入；本文是已执行的故障记录，不应被理解为任何类似设备均可直接导入。没有可验证备份且数据重要时，应优先保存成员盘完整镜像。

2. 实际执行的导入步骤

在复核原配置和备份条件后，返回 Manage Foreign Configuration，执行 Import Foreign Configuration，在确认界面提交，现场反馈导入成功。

没有执行 Clear Foreign、Create Virtual Disk、Initialize、Force Online 等破坏性或高风险操作。

3. 导入后复核真实状态

导入后，iDRAC 一度仍显示 RAID 5 Failed，但三块成员盘已均显示 Online。可重启系统，后续进入 PERC 控制器配置工具直接查看，确认：

Virtual Disk 0: GenericR5_0
RAID5, 2.182TB, Ready

Physical Disk 00:01:00  Online
Physical Disk 00:01:01  Online
Physical Disk 00:01:02  Online

与此同时，RAID 0 已显示联机，而 RAID 1 仍处于 Degraded（降级）。不要把“RAID 5 Ready”误写为全部阵列完全健康。

五、Ubuntu 引导与 EXT4 根文件系统修复

1. GRUB 初次启动异常

恢复阵列后从 ubuntu 启动项尝试启动，一度出现：

Failed to open \EFI\ubuntu\grubx64.efi - Device Error
Failed to load image: Device Error
Boot Failed: ubuntu

随后再次启动时，系统已能进入 Linux 内核启动流程，所以没有重建 EFI 分区、没有重装 GRUB，也没有重新安装 Ubuntu。

2. 进入 initramfs，确认 EXT4 不一致

内核可以识别 LVM 根逻辑卷，但自动文件系统检查失败：

/dev/mapper/ubuntu--vg-ubuntu--lv:
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
fsck exited with status code 4
Failure: File system check of the root filesystem failed

随后进入 BusyBox (initramfs)。这里的 ubuntu--vg-ubuntu--lv 是 LVM mapper 的实际设备名，不同服务器不可直接照抄。

3. 在 initramfs 运行手动 fsck

在已确认备份和阵列可访问的前提下，执行：

fsck.ext4 -f /dev/mapper/ubuntu--vg-ubuntu--lv

修复过程依次经历 inode/extent 检查、目录结构检查、目录连通性检查、引用计数检查及组信息检查。

遇到 Optimize<y>? 等优化提示，现场逐项确认；对孤立 inode，出现 Connect to /lost+found<y>? 时选择保留至 /lost+found。

第一轮结束后提示：

***** FILE SYSTEM WAS MODIFIED *****

注意：fsck 会写入文件系统元数据。虽然这次成功恢复启动，但修复仍可能导致某些文件丢失原目录关系、被清理或内容不完整；应在业务核验时检查 /lost+found，并与备份比对。对不明修复提示不要无条件连续回答 y。

4. 再次检查并继续启动

在 (initramfs) 再运行一次：

fsck.ext4 -f /dev/mapper/ubuntu--vg-ubuntu--lv

第二轮顺利完成 Pass 1～5，未再次看到 FILE SYSTEM WAS MODIFIED 或新的修复提示。随后尝试 exit / 重启流程，系统最终进入 Ubuntu 登录界面。

六、最终结论与交付检查项

后续建议

1. 立即备份并验证：优先备份关键业务文件、数据库及相关配置；检查 lost+found 和业务数据能否正常使用。
2. 排查 RAID 1：明确缺失成员及磁盘数据新旧，避免贸然 Rebuild/Initialize/一致性检查。
3. 复核硬件告警：检查 A1/A2 ECC 错误是否复现、PERC 事件及物理盘健康。
4. 恢复业务网络和服务：查看 Netplan、物理网线、Bond/Bridge，确认 OverlayFS 的日志来源。
5. 保留故障记录：导出 iDRAC Lifecycle Log、控制器配置和恢复后状态截图。

复盘重点：这次是“先恢复原 RAID 配置 → 确认系统卷可访问 → 手动修复 EXT4 → 正常进入 Ubuntu”，不是通过重装系统解决。RAID 恢复与文件系统修复均有数据风险，本记录仅供同类问题参考，不能替代基于实际磁盘健康与备份情况的现场判断。