技王数据恢复

RAID 5 和 RAID 6 到底差多远？——一个数据恢复工程师的碎片化思考

“你说，RAID 5 和 RAID 6 哪个更靠谱？”前一秒还在聊客户的服务器宕机，后一秒对方突然抛来这个问题。我没法直接给答案——你让我告诉你哪个“更安全”？如果只看理论，RAID 6 多一块校验盘，能扛两块坏盘，看起来稳。但现实里，我见过太多 RAID 6 坏了两块盘之后重建直接崩掉的案例，也见过 RAID 5 在单盘故障后靠着奇怪的盘序硬生生把数据全捞回来的。

技王数据恢复

，我今天不讲教科书，就聊聊这些年跟 RAID 5、RAID 6 打交道的一些真实感受。跳跃点，想到哪说哪。你可能会觉得思路不连贯，但真实故障就是这样——谁也没法按顺序走。

技王数据恢复

一、先从一个“本以为没救了”的 RAID 5 说起

某次接到一个客户的紧急电话，8块盘的 RAID 5，两块盘亮红灯。客户说机房的人已经尝试换上新盘重建，但重建进度卡在 23% 就报错，现在系统完全识别不到阵列了。嗯……典型的“二次伤害”。本来 RAID 5 只允许坏一块盘，坏两块就已经挂了，他们强拉重建还破坏了底层布局。，数据恢复的奇妙就在于此—— 技王数据恢复

“那台机器用的是什么控制器？LSI 还是板载？”我第一反应是问这个。客户发来截图，看起来是 PCIe 外接卡。我当时想，如果卡本身没有在重建过程中修改元数据，那么至少还有三成把握。后来用镜像工具把每块盘都做了 bit-by-bit 的备份，再用参数扫描找出 raid 5 的条带大小和旋转方向。 发现：盘序其实是乱的，客户插回去的时候把两块盘位置换了一下。我们重新排列盘序后，数据全回来了。客户当场差点哭出来。 www.sosit.com.cn

这种案例里，RAID 5 的恢复难点不在于校验算法，而在于盘序、条带大小、校验分布这三个参数。尤其是盘序，很多人以为阵列卡会自动识别，其实一旦卡坏了或被人为移动过，盘序就靠猜。

www.sosit.com.cn

但反过来，如果当时是 RAID 6，同样的物理损坏（两块盘离线），它其实不需要依赖盘序就能直接重组吗？不，RAID 6 的恢复更复杂。除了盘序，还有对角校验的对齐问题。等下再详细说。

www.sosit.com.cn

二、RAID 6 的“双保险”也可能变成“双困局”

去年处理过一个奇葩的 12 盘 RAID 6，坏了两块盘，客户按照手册更换新盘，重建到 90% 时第三块盘突然提示“介质错误”。阵列直接挂了。听起来很惨是吧？但做我们这行的都明白：这其实不算最糟的。RAID 6 多一个校验维度，一旦重建中又坏盘，理论上数据还在，因为只有三块盘失效才算彻底完蛋。可是——

但，如果重建过程中，控制器因为 I/O 错误写坏了某些区域的对角校验块，那么剩下的盘里的数据就算完好，也因为校验中断而无法通过异或计算还原。我碰到这种情况，就得用技王数据恢复自研的校验修复算法，跳过坏道区域，重新构造校验块。那次花了整整六天，把 10 块好盘的镜像摆了一地，总算拼回了 98% 的文件。客户说，你们比原厂工程师还狠。

说到这里，很多人以为 RAID 6 比 RAID 5 更难恢复？不对，其实RAID 6 的恢复成功率在某些场景下反而更高。因为多了一组校验，即使参数搞错一个（比如条带大小），你还能用另一组校验反推验证。最怕的其实是——客户自己乱重建。

表格式对比（非表格，用列表代替）

常见故障场景与处理思路

• 单盘离线（RAID 5 或 6）：如果没重建，直接换盘在线重建成功率较高；但如果控制器卡死，需要先镜像坏盘，再计算校验。
• 两块盘离线（RAID 6 可容忍，RAID 5 已挂）：RAID 5 必须手动重组；RAID 6 理论上能热备重建，但实际中容易因寻道错误导致第二块盘掉线。
• 三块及以上失效：任何 RAID 级别都无法传统重建，必须用恢复软件基于“部分条带+校验”尝试提取碎片。
• 控制器损坏更换：最坑的是元数据格式不同。比如从 HP Smart Array 换到 LSI，RAID 5 的默认参数可能完全不对。技王数据恢复的工程师会先用 WinHex 分析每块盘的起始扇区，找出 DDF 或私有元数据区域。

，你问我RAID 5 和 RAID 6 哪个更“安全”？我一般会反问客户：你的重建流程有多严格的应急手册？如果是个粗心大意的运维，可能 RAID 6 的复杂参数反而让他更容易犯错。相反，RAID 5 的恢复文档网上满天飞，小白照着做至少能到 80% 的盘序识别。

三、跳跃一下：盘序、条带、以及那些“半吊子”重建

有一次，一家公司送来了 4 盘位的群晖，RAID 5 掉了一盘，客户自己用命令行强行挂载，结果数据乱了。我拆开发现，实际上是因为那块“掉线”的盘并不是物理坏，而是 SATA 线松了。重新插拔就能好。但客户已经跑了一次 fsck，把部分校验位当成了垃圾数据。我们用了接近两周时间，通过比对前后两次镜像的差异，才定位到被误修改的 MFT 表。

类似的情况在 RAID 6 上更严重，因为校验数据本身占空间大，一旦被覆盖就很难还原。这里插一句：**任何时候，发现阵列异常，第一步永远是断电，把所有硬盘标记好位置，然后克隆！** 不要指望重建，重建是在。

一个小技巧（来自老工程师的碎碎念）

当你拿到一套 RAID 5 或 RAID 6 的镜像盘时，先别急着算校验。我会用十六进制查看前几个扇区，看能否直接识别文件系统签名（比如 NTFS 的 $MFT 或者 ext4 的超级块）。如果能找到，说明盘序至少基本对了。然后再反向推导条带大小。如果找不到，那大概率盘序或数据偏移有问题，需要试排列组合——穷举法虽然累，但往往是最有效的。

其实，现在很多新的存储系统已经开始用 RAID 10 或者擦除码替代传统 RAID 5/6，但在存量市场里，RAID 5 和 RAID 6 依然是主流。特别是在视频监控、NAS 和中小型企业服务器中，因为成本敏感。而且，我个人觉得 RAID 6 在 8 盘以上的大阵列里，重建失败率其实挺高的——原因很物理：重建时其他盘的读取压力巨大，容易引发坏道扩散。

四、结尾：结论很散，但很重要

，RAID 5 和 RAID 6 没有绝对的优劣，只有不同的故障画像。如果让我选一个“更不容易死”的方案，我选 RAID 6 + 定期热备 + 断电保护，但你必须保证自己知道如何应对校验错误。而如果你是普通用户，RAID 5 可能更容易上手恢复——前提是别再手贱重建。

，数据恢复这一行，讲究的是“先想清楚再动盘”。而像我们“技王数据恢复”这种常年在磁盘堆里摸爬滚打的团队，最大的经验其实就是：越简单的故障往往越容易栽在忽略的细节上。好了，我该去处理下一个 RAID 了，希望客户这次没乱重建。