RAID 5曾经很好用，但面对大容量硬盘已经有些力不从心

RAID 5曾经是很多服务器、NAS和存储设备里的经典方案。它通过数据条带化加一组分布式奇偶校验，让整个阵列在牺牲一块硬盘容量的情况下，获得单盘故障容错能力。对于过去几百GB、1TB甚至2TB级别的硬盘来说，这种设计在容量、性能和可靠性之间取得了不错的平衡，因此长期以来都有很高的普及率。

但随着机械硬盘容量不断增长，RAID 5面临的问题也越来越明显。现在一块硬盘做到12TB、16TB、20TB甚至更高容量已经并不罕见，硬盘本身虽然越来越大，但机械结构和实际读写速度并没有按照同样的比例提升。于是，一个过去几个小时就能完成的RAID重建任务，在大容量硬盘时代可能变成十几个小时甚至更长时间。

真正让RAID 5变得不太适合大容量硬盘的，并不是它不能识别大容量硬盘，而是硬盘容量越大，故障之后进入重建状态所持续的时间越长，而这段时间恰恰是整个阵列风险最高的时候。Dell的RAID资料也明确指出，大型RAID 5卷重建需要更长时间；IBM同样提醒，在阵列重建期间，如果再次发生磁盘故障，整个阵列的数据都可能受到影响。

RAID 5最脆弱的阶段，是硬盘坏掉之后

理解这个问题，首先要弄清楚RAID 5是怎么恢复数据的。

假设服务器里有4块16TB硬盘组成RAID 5，可用容量大约是48TB。当其中一块硬盘损坏时，剩余的3块硬盘并不会突然变成一份完整的数据备份，而是需要通过原本存储在其他磁盘上的数据和奇偶校验信息，把损坏硬盘中的数据重新计算出来，然后写入新的硬盘。

这就是所谓的“重建”。

正常运行的时候，RAID 5可以承受一块硬盘故障，但进入重建之后，整个阵列就从“能够容忍一次故障”变成了“不能再承受第二次故障”的状态。因为奇偶校验本身只提供单盘容错能力，一旦重建期间又有第二块硬盘出现不可恢复的问题，阵列就可能无法完整恢复数据。Dell对RAID 5的说明也明确指出，RAID 5只能容忍单盘故障，两块硬盘同时失效时则会导致数据丢失。

问题在于，大容量硬盘让这个危险窗口明显变长。

比如一块1TB硬盘出现故障，需要重新写入的数据规模和16TB硬盘相比完全不是一个数量级。即便控制器、硬盘和服务器的重建速度保持不变，16TB硬盘也意味着需要处理更多数据。实际环境中，RAID重建还会受到服务器业务负载、磁盘随机I/O、控制器性能以及阵列工作状态等因素影响，因此重建速度通常并不能简单按照硬盘标称容量换算。

IBM曾经给出过一个非常直观的例子。在其对RAID 5与大容量硬盘的分析中，7+P RAID 5使用6TB Nearline硬盘时，如果按照一定的重建速度计算，重建一块6TB硬盘可能需要大约55小时。也就是说，一块硬盘损坏后，阵列可能需要连续几十个小时处于高风险状态。

大容量硬盘还有一个容易被忽视的问题

除了第二块硬盘故障之外，重建过程中还存在另一个风险，那就是读取其他硬盘数据时出现不可恢复读取错误。

RAID 5重建并不是简单地把新硬盘“复制”出来，而是要读取剩余成员盘的大量数据，再通过校验计算恢复缺失数据。硬盘容量越大，重建过程中需要扫描和读取的数据自然越多。

如果剩余硬盘中的某个位置本身就存在无法正常读取的数据，RAID 5可能无法依靠现有的一份奇偶校验继续完成整个重建。尤其是在大容量机械硬盘组成的阵列中，一次重建可能涉及几十TB甚至更多的数据读取量，这使得潜在的读取错误更加值得关注。

IBM曾使用6TB硬盘的RAID 5案例进行计算，在特定假设条件下，重建过程中遭遇不可恢复读取错误的概率已经明显高于较小容量硬盘场景，并据此建议高容量、低转速硬盘环境优先考虑RAID 6。

这里需要特别说明，这并不意味着“大容量硬盘一定会在RAID 5重建时出错”，也不能简单理解成所有硬盘都按照某个固定概率发生URE。实际风险取决于硬盘型号、介质质量、阵列设计、控制器机制、错误恢复策略以及厂商实现。不过可以确定的是，随着每次重建需要读取的数据规模增加，阵列暴露在重建风险中的时间和数据量都会随之增加。

RAID 5的问题，本质上是容错能力跟不上数据规模

RAID 5最初的优势非常明显，因为它只需要牺牲一块硬盘的容量，就能实现单盘故障保护。

例如4块4TB硬盘组成RAID 5，理论可用容量约为12TB；如果换成4块16TB硬盘，可用容量则提升到了约48TB。容量利用率依然很高，这也是很多人面对大容量硬盘时仍然喜欢RAID 5的重要原因。

但容量效率高，并不代表风险水平同样保持不变。

过去一块硬盘只有500GB或者1TB，坏掉之后需要重建的数据规模比较有限。现在一块机械硬盘可能达到16TB甚至更高容量，阵列一次故障所对应的数据规模已经发生了巨大变化。与此同时，机械硬盘的实际持续读写速度并没有同步提升到能够完全抵消容量增长的程度。

这就形成了一个很现实的矛盾：硬盘越来越大，但重建速度并没有按照容量同比增长。

于是，RAID 5过去“牺牲一块硬盘容量换取单盘容错”的优势，在大容量时代逐渐变成了“为了节省一块硬盘容量，却让阵列在故障之后承担更长时间的风险”。

RAID 6为什么越来越受欢迎

在大容量硬盘环境中，RAID 6之所以越来越常见，核心就在于它增加了一组独立的校验信息。

RAID 5只能容忍一块硬盘故障，而RAID 6可以同时容忍两块硬盘故障。这样即使阵列正在重建，第二块硬盘出现问题，系统依然拥有继续恢复数据的能力。

这并不意味着RAID 6没有代价。第二组校验信息会带来额外的容量开销，同时写入过程也会增加一定的计算和I/O负担。Dell的资料显示，RAID 6的可用容量通常按照“N-2”计算，而RAID 5则按照“N-1”计算。

不过对于今天的大容量机械硬盘阵列来说，多牺牲一块硬盘容量换取更高的故障容忍能力，很多时候是更合理的选择。IBM在针对大型、较慢硬盘的研究中也明确建议，在这类环境下优先考虑RAID 6。

RAID 10也值得重新考虑

除了RAID 6之外，RAID 10同样是大容量存储场景中经常被考虑的方案。

RAID 10通过镜像与条带化组合实现数据保护，不依赖RAID 5那样的奇偶校验重建机制。在发生单盘故障之后，恢复过程主要是从对应镜像盘复制数据，因此重建逻辑相对直接。Dell也指出，RAID 10没有RAID 5、RAID 6那样的奇偶校验计算开销，在一些高性能业务环境下往往能够提供更好的性能表现。

它最大的缺点则是容量利用率只有大约50%。如果企业更加看重IOPS、低延迟和故障恢复速度，RAID 10通常更有吸引力；如果更加关注容量利用率，同时又需要较强的容错能力，RAID 6往往更合适。

RAID 5并不是彻底“淘汰”了

说RAID 5不适合大容量硬盘，并不意味着RAID 5已经完全没有使用价值。

在小型阵列、容量相对有限、业务负载较低，或者对容量利用率要求比较高的环境中，RAID 5依然能够发挥作用。部分存储产品甚至仍然提供RAID 5配置选项，说明它并不是一个过时到不能使用的技术。IBM目前的存储文档中同样可以看到RAID 5仍然存在，只是在不同产品和硬盘类型下会有明确的成员盘数量与容量限制。

真正需要改变的是思路。

以前选RAID，很多人首先考虑的是“能提供多少可用容量”，现在面对12TB、16TB、20TB甚至更大容量硬盘时，则应该把“故障之后多久能够完成重建”“重建过程中还能承受多少次故障”“阵列到底需要读取多少数据”这些因素放到更重要的位置。

对于小容量硬盘，RAID 5的问题可能并不突出；而当单盘容量不断上升，几十TB级别的数据越来越集中在一个阵列中，RAID 5单盘容错的局限性就会越来越明显。

所以，RAID 5真正的问题从来不是“大容量硬盘不能用”，而是硬盘容量增长之后，单盘容错机制面对越来越长的重建时间和越来越大的数据读取量，已经越来越难满足高可靠存储的要求。

对于今天的新建存储系统，尤其是使用大容量机械硬盘的NAS、服务器和企业存储平台，RAID 6往往比RAID 5更加稳妥；对于数据库、虚拟化和高IOPS业务，则可以进一步考虑RAID 10。至于重要数据，则无论采用哪一种RAID，都不能把RAID本身当成真正意义上的备份，独立备份仍然是数据安全最后一道防线。