阿里云 EC模式 raid6 数据恢复——一个工程师的真实复盘
前几天接到一个电话，客户在阿里云上跑着阿里云 EC模式 raid6，一共8块云盘，用mdadm做的软件RAID。结果一块盘直接离线，另一块盘出现了大量坏道，系统I/O卡死，业务全停。客户急得不行——“工程师，数据还能救吗？”
说实话，听到“RAID6 + 坏盘+第二块盘bad block”这种组合，我心里先咯噔一下——RAID6允许坏两块盘，但前提是坏的是“干净”的故障，如果第二块盘只是有坏道而非完全掉线，其实是可能抢救的。但这需要极其谨慎的操作，稍不注意就可能让整个阵列崩溃。
今天我就把这次处理的完整思路和步骤写出来，也把一些容易犯的错、判断的陷阱说清楚。希望对遇到类似问题的朋友们有帮助。 技王数据恢复
故障初判：阿里云 EC模式 raid6 到底发生了什么
先解释一下“阿里云 EC模式 raid6”。EC模式是阿里云弹性计算（Elastic Compute）的简称，客户自己买了多块ESSD云盘，挂载到一台高配ECS实例上，然后通过Linux的mdadm创建了RAID6阵列。这种场景在需要大容量、高IOPS且预算有限的企业里很常见——因为云盘本身有冗余，再加上RAID6，理论上非常安全。
但云盘毕竟不是物理盘，它底层是分布式存储，坏道的表现和物理硬盘不一样。客户看到系统日志里有大量buffer I/O error，而且/dev/sda连续报错。我用smartctl查看云盘状态——其实阿里云云盘不支持传统的SMART，但可以通过dmesg和/sys/block/sdx/device/state判断。
当时发现两块盘的状态：
- 盘A：/sys/block/sda/device/state 显示 offline，完全掉线。 技王数据恢复
- 盘B：state 显示 running，但dmesg疯狂报read error at sector X，说明这块盘还没完全挂，但已经出现了大量不可恢复的读取错误。
这种局面下，如果直接重启或者重新激活阵列，很可能导致盘B也被踢出，RAID6降级为RAID5甚至直接失效。核心判断点：第二块盘只是读错误，还没有被内核标记为失效，我们要抢在它彻底罢工之前把数据完整读出来。 技王数据恢复
紧急止损：先别重启，先备份元数据
我做的第一件事：让客户切勿重启ECS实例，也不要执行任何mdadm --assemble或fsck。因为一旦重新组装，mdadm可能根据当前磁盘状态重新同步，导致错误覆盖。
然后远程登录（通过阿里云VNC或串行控制台，避免ssh中断风险），立刻执行：
技王数据恢复
mdadm --detail /dev/md0 > raid_detail.txtmdadm --examine /dev/sda /dev/sdb /dev/sdc ... > raid_examine.txt www.fixhdd.cn 备份这些元数据至关重要，后期如果阵列完全崩溃，我们可以根据这些信息重建RAID结构。，把所有可读的盘（包括有错误的盘B）的完整块设备镜像用ddrescue拉取到备用存储区，这是最安全的操作。
技王数据恢复
ddrescue 拉取镜像时的注意事项
盘B有读取错误，但ddrescue可以跳过错块继续复制，并且会生成日志文件。命令： www.fixhdd.cn
ddrescue -d -r3 /dev/sdb /backup/sdb.img /backup/sdb.log 技王数据恢复
这里-d表示直接访问设备，-r3是重试3次。日志文件要保留，后面判断坏块位置用。
盘A完全离线怎么办？不能直接dd，需要先尝试热插拔？但阿里云云盘本身不支持热插拔，而且offline状态很可能是因为底层故障，阿里云控制台看到磁盘显示“已挂载”但实例内不可见。这时我让客户提工单让阿里云后端检查——很多时候是云盘所在的物理存储节点出了问题，重新挂载后可能恢复。但为了保险，我们在一开始就通过mdadm --examine记录下盘A的超级块信息，如果云盘能重新可见，我们就能恢复。
核心恢复流程：基于阿里云 EC模式 raid6 的逐层拆解
上面备份做好之后，我们得到了一份干净的副本：盘B的镜像sdb.img，以及其他正常盘的镜像（或者在线dd）。由于盘A无法直接读取，我们利用RAID6的校验和 + 其他盘数据来重建盘A的内容，然后合并成完整阵列。这里必须强调：千万不要在原始盘上操作，全部用镜像。
我写过一个小工具，但这次用mdadm的--create在镜像文件上重建RAID，指定缺失盘为“missing”。
具体步骤：
- 准备镜像文件：把所有可读盘都dd到独立的文件，盘B用ddrescue得到的，盘A我们创建一个全零的空文件，大小与盘A一致。
- 构造RAID6：
mdadm --create /dev/md_test --level=6 --raid-devices=8 --chunk=128K /dev/loop0 /dev/loop1 ... /dev/loop7
其中loop0对应盘A（空白文件），loop1对应盘B（ddrescue镜像），loop2-7对应正常盘镜像。顺序必须和原始阵列一致，这依靠之前备份的mdadm -E信息。 - 自动重建：mdadm会识别缺少盘，自动启动恢复进程。但由于盘A是空白，重建会非常慢，而且盘B上的坏块区域会导致读取错误。做法是创建一个只读的md设备，用
--readonly标志，不让mdadm主动写任何数据。然后直接挂载，能读多少是多少。 - 提取数据：挂载后优先复制重要目录。对于坏块导致的读取错误，mdadm会返回I/O错误，但我们可以在上层用
dd_rescue复制文件系统级别的数据。
这个方案在客户案例中成功恢复了95%以上的数据。之不是100%，因为盘B的坏块区域正好落在文件系统的元数据上，导致少量文件丢失。但核心数据库（MongoDB）可以通过WAL日志恢复。
一个意外的陷阱：阿里云 EC模式 raid6 的磁盘顺序
在准备镜像时，我注意到一个重要细节：阿里云挂载云盘时，设备名（如/dev/xvdb）可能因为内核分配顺序不同而变化。客户重启过实例，导致设备名映射改变。但mdadm的超级块里记录了UUID和磁盘角色，不能完全依赖设备名。必须用mdadm -E /dev/xxx查看每个磁盘的Raid Device号，再确定顺序。
我们这次就出现了编号混乱：/dev/sdc本来应该是第3块盘，但超级块里显示它是第5块。幸亏提前备份了mdadm --examine输出，否则按错误顺序重建直接废掉整阵列。
强烈建议：在阵列健康时，定期导出mdadm --detail --export信息，保存到安全位置。
技王数据恢复的一点经验
说起来，我们团队（技王数据恢复）以前处理过一个类似的阿里云 EC模式 raid6 案例，那次更棘手——客户误执行了mdadm --zero-superblock，导致超级块被清零。但幸运的是，所有盘的数据区完整，我们通过扫描每个磁盘的校验和数据，手动重建了RAID参数（chunk大小、阵列布局等）。那篇文章我写过，但今天这个案例更典型，因为涉及了盘B坏道和盘A离线并存的场景。
总结下来：RAID6并非万能，尤其在云环境中，云盘的“故障”表现和物理盘不同，不能简单套用传统经验。
结论与预防建议
回到开头的问题：阿里云 EC模式 raid6 在遇到一块盘完全离线、另一块盘出现读取错误时，数据是很有可能恢复的，关键在于立刻停止一切写操作，优先做镜像。不要尝试重新挂载、重新组装或者修复文件系统，那会破坏现场。
从这次案例中学到几点：
- 监控云盘的dmesg错误和/sys/block/sdX/device/state，一旦发现报错，在没完全掉线前火速镜像。
- 定期检查mdadm阵列的健康状态：echo check > /sys/block/md0/md/sync_action，但注意这会在校验不一致时自动修复，风险自负——建议放在业务低峰期，且提前备份元数据。
- 对于关键业务，可以考虑用RAID6 + 备用云盘（热备盘），或者使用阿里云提供的分布式快照（快照也能当备份）。
阿里云 EC模式 raid6 是个非常稳定的方案，但如果真遇到故障，别慌，先冷处理，再按规程操作。数据恢复是一个拼耐心和细节的活，很多时候需要的不是花哨的工具，而是冷静的判断。
