RAID10阵列（md2）故障恢复方案咨询

首先得说，接手别人配置的RAID出故障这种情况确实头疼，必须小心翼翼来，你先备份再动手的思路绝对是对的，给你点个赞！

先帮你梳理下目前的核心状况：

• 4块磁盘上搭建了3个RAID10阵列，md0、md1状态正常，但md2启动时因UUID问题报错，sda5和sdb5被标记为「非新鲜盘」踢出，只剩sdc5、sdd5在阵列中，因镜像数不足无法正常启动。
• sda5事件数偏低，说明它很久没和阵列同步，数据大概率已过时；而sdb5的事件数和活跃的sdc5、sdd5完全一致——这很关键，意味着它最后一次同步时和正常盘数据是一致的，被踢更可能是临时硬件/连接故障，而非数据本身不一致。

接下来给你分阶段的实操建议，核心原则是备份优先，慎动原盘：

第一步：完成备份，筑牢安全线 #

等额外备份盘到位后，一定要用ddrescue给涉及md2的所有分区做镜像，重点优先备份sdb5（数据最新）和sdc5、sdd5，命令示例：

ddrescue /dev/sdb5 /path/to/backup/sdb5.img /path/to/backup/sdb5.log
ddrescue /dev/sdc5 /path/to/backup/sdc5.img /path/to/backup/sdc5.log
ddrescue /dev/sdd5 /path/to/backup/sdd5.img /path/to/backup/sdd5.log

备份过程中尽量不要对原盘做任何写入操作，避免破坏数据。

第二步：备份完成后的恢复操作 #

方案一：尝试强制组装md2（优先推荐） #

因为sdb5的事件数和活跃盘一致，我们可以先跳过数据过时的sda5，尝试强制组装md2：

mdadm --assemble --force /dev/md2 /dev/sdb5 /dev/sdc5 /dev/sdd5

• 如果组装成功，先别急着挂载，先检查文件系统完整性（以ext系列为例）：

e2fsck -f /dev/md2

• 文件系统检查无误后，挂载测试数据是否正常。确认数据没问题后，再处理sda5：先把它从阵列中彻底移除（如果还残留配置），再重新添加同步：

# 先检查sda5是否仍在md2配置中
mdadm --detail /dev/md2
# 如果存在则移除
mdadm /dev/md2 --remove /dev/sda5
# 添加sda5重新同步
mdadm /dev/md2 --add /dev/sda5
# 查看同步进度
cat /proc/mdstat

方案二：强制组装失败后的补救 #

如果方案一失败，说明阵列元数据可能损坏，这时候需要借助备份镜像尝试恢复，或重新创建阵列（风险较高，必须确保参数完全匹配）：

1. 从mdadm --misc --examine的输出中提取原阵列关键参数：chunk size、RAID级别（RAID10）、布局（如near/far/off）、UUID等，这些参数必须和原阵列完全一致，否则会损坏数据。
2. 用备份镜像创建临时阵列测试：

mdadm --create /dev/md2_test --level=10 --raid-devices=4 --chunk=XXX --layout=YYY /path/to/backup/sdb5.img /path/to/backup/sda5.img /path/to/backup/sdc5.img /path/to/backup/sdd5.img

（XXX为chunk size，YYY为布局，需从examine结果中提取）
3. 确认临时阵列能正常挂载读取数据后，再对原盘执行相同的创建命令（注意：这一步会覆盖原盘元数据，必须确保备份完整）。

关键注意事项 #

• 所有操作前必须确保备份完成，这是最后一道防线，绝对不能省略。
• 操作时尽量在单用户模式或救援环境下进行，避免文件系统挂载导致的冲突。
• 执行mdadm命令前务必仔细核对参数，尤其是创建阵列的命令，错一个参数就可能毁掉数据。
• 恢复完成后，建议定期检查RAID状态（mdadm --detail /dev/md2、cat /proc/mdstat），避免类似问题再次发生。

备注：内容来源于stack exchange，提问作者Malaxes