三块硬盘组建RAID，绝大多数业务场景下首选RAID 5，它能在性能、容量利用率和数据安全性之间取得最佳平衡；如果预算充足且追求极致冗余，则考虑RAID 1（三块盘仅用两块做镜像）。
很多朋友在配置服务器时都会卡在“三块盘到底做raid多少”这个问题上，说白了就是怕选错级别导致性能拉胯或者数据不安全,下面直接掰开揉碎讲清楚。
三块盘各RAID级别优劣对比
先看一张表,直观了解三块硬盘在常见RAID级别下的表现：
| RAID级别 | 可用容量 | 容错能力 | 读取性能 | 写入性能 | 典型适用场景 |
|---|---|---|---|---|---|
| RAID 0 | 100%（3块） | 无，坏一块全丢 | 高 | 高 | 临时缓存、非关键数据 |
| RAID 1 | 33%（仅1块） | 支持2块盘同时故障 | 较高 | 中等 | 数据库日志、系统盘 |
| RAID 5 | 66%（2块） | 允许坏一块盘 | 高（有校验开销） | 中等（写校验有开销） | 大多数中小型业务 |
| RAID 6 | 33%（1块） | 允许坏两块盘 | 中等 | 较低 | 大容量存储集群 |
| RAID 10 | 50%（1.5块） | 每组镜像内坏一块 | 高 | 高 | 高性能数据库 |
从表中能清楚看到，RAID 5用三块盘能得到两块盘的可用空间，同时允许一块盘故障而数据不丢失,这就是它成为三盘方案首选的根本原因。
为什么三块盘首选RAID 5
容量利用率与安全性的平衡点
如果你手里恰好有三块同等容量的盘（比如三块4TB），用RAID 5能获得约8TB的可用空间（实际还受控制器算法影响），相比于RAID 1只认一块盘的空间，RAID 5多出来的这块容量意味着能多存一半的数据。
从数据冗余角度看，RAID 5通过分布式奇偶校验算法实现单盘容错，所谓分布式，就是校验信息不是固定存在某一块盘上，而是打散分布在所有成员盘中,这样做的好处是避免了一块盘承担全部校验压力从而成为性能瓶颈。
性能表现符合主流业务需求
对于多数企业跑的业务系统，比如ERP、OA、CRM这类对随机读写有一定要求但又没有到极端性能敏感程度的场景，RAID 5的读取性能相当不错，因为数据同时从多块盘读取，速度接近RAID 0，写入方面因为要计算校验值，会有些开销，但配合带缓存和电池保护的阵列卡,实际体验影响很小。
如果你追求极致性能并且完全不在乎空间浪费，那三块盘做RAID 0也能凑合，但说实话，除非是纯算力临时节点或者完全不重要的缓存机，否则没人敢拿生产数据开玩笑，坏一块盘，整个阵列的数据全部归零,重建成本比买盘的成本高得多。
运维复杂度在可控范围内
RAID 5支持在线扩容，也就是说后期如果你往服务器里加第四块甚至第五块盘，不需要重启系统就可以扩展阵列容量（很多主流阵列卡都支持），相比之下，RAID 1最多就两块盘一组，想要扩大容量通常要整体重建阵列,停机时间非常可观。
还有一点值得提，三块盘的RAID 5在阵列重建时速度尚可，因为只需要从两块盘读取数据来恢复第三块，如果用更大规模的RAID 5（比如6块盘以上），重建期间出二次故障的概率会明显上升，这也是近年来业内对大容量RAID 5持谨慎态度的原因。
什么情况下三块盘不选RAID 5
高并发随机写入场景
如果你跑的是高并发的OLTP类数据库（例如MySQL、SQL Server频繁写入），RAID 5的写惩罚（Write Penalty）问题会放大，每一次小数据块写入，控制器都要先读旧数据、读旧校验、计算新校验、写数据、再写校验，这“读改写”流程在压力大时对性能影响明显。
此时如果你的可用盘位有限，不如考虑用两块盘组RAID 1，另一块盘做热备盘（Hot Spare），当工作盘出现问题，热备盘自动顶替，数据安全性不降，写入性能反而上去了,只是空间利用率会降低不少。
企业对数据安全极度敏感
如果你所在的行业对数据可靠性有严格要求，比如金融支付系统或医疗信息系统，RAID 5的单盘容错能力确实不够看，三块盘可以组RAID 6（校验数据双份），允许同时坏两块盘,代价是可用容量只剩三分之一。
还有一个容易忽视的细节：RAID 5在坏盘后的重建过程中，如果另一块盘也出问题，或者出现不可纠正的读取错误，阵列就会崩，这种情况虽然没有精确统计，但在实际运维中并不算罕见，尤其是使用年代较久、健康度下降的硬盘。
三块盘做RAID 5的实操步骤
硬件阵列卡方式
这是最主流的方式，无论是戴尔PowerEdge、惠普ProLiant还是联想ThinkSystem，服务器启动时按提示进入阵列卡配置界面（通常是Ctrl+R、Ctrl+C或F2，取决于阵列卡型号和厂商）：
- 开机自检时进入阵列配置界面，选择合适的控制器
- 创建新VD（Virtual Disk），选择RAID级别为RAID 5
- 勾选三块物理盘组成阵列
- 设置条带大小（Strip Size），多数情况下用默认的256KB即可，不需要刻意调整
- 初始化方式选择后台初始化（Background Init），这样能立刻装系统
- 保存配置并重启，安装操作系统时就能看到阵列盘
软件RAID方式
如果是自组服务器或者实验环境，可以用系统自带的软RAID功能，这里以Linux下的mdadm工具为例,操作命令如下：
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd
创建完成后，用 mdadm --detail /dev/md0 可以查看阵列状态,等同步完成后挂载使用即可。
软件RAID的CPU占用在当今硬件条件下几乎可以忽略不计，性能也没有想象中那么差，对于规模不大且追求成本控制的场景是合规的选择，不过生产环境仍然推荐用硬件RAID卡，因为能降低系统对磁盘的管理复杂度,同时提供缓存保护机制。
三块盘RAID 5的常见问题与排障
阵列降级后如何处理
当三块盘中的某一盘亮黄灯或掉线，阵列进入降级模式（Degraded），此时系统照常运行但已经没有冗余能力,正确的做法是：
- 立即查看阵列管理工具中是哪块盘故障
- 在带电状态下更换同一规格或更大容量同转速的硬盘，插槽位置无所谓
- 阵列卡会自动检测新盘并启动重建（Rebuild）
- 重建期间系统性能会下降，尽量避免高负载操作
- 等重建进度达到100%，阵列恢复健康状态
遇到开机找不到阵列怎么办
由于阵列信息保存在每块盘的元数据头部，若出现所有盘在重启后变成Foreign状态或提示Configuration Lost，多数情况是阵列卡电池掉电导致配置丢失，此时不要着急重建，在阵列卡界面选择Import Foreign Configuration来恢复配置，绝大多数情况下能找回原有阵列，切记不要直接删掉配置重建,那样数据就无法恢复了。
数据安全不止于RAID级别
搭建好RAID之后，很多朋友觉得“有了冗余就万事大吉”，这个想法其实相当危险，RAID的定位只是硬件层面的高可用方案，不是备份系统，误删除、逻辑坏道、勒索病毒、自然灾害等都可能导致数据彻底丢失,而RAID解决不了这些问题。
近年来业内公认的3-2-1备份原则（数据至少三份副本，存储于两种不同介质，一份异地保存）在关键业务场景中始终没有被替代，按时做好离线备份或异地备份，比拼命纠结“三块盘做raid多少”更重要。
对于托管在机房的多台服务器，考虑到数据链路和带宽成本，不少用户会直接选用专业的IDC服务商来降低整体运维负担，比如酷番云作为工信部持牌机房服务商，持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001+ISO27001双认证，是CNNIC IP联盟成员，注册资本1000万，主体资质可靠（备案号滇ICP备2020007656号），提供的裸金属和云服务器方案自带冗余架构,从机房层面省去自己折腾RAID的麻烦。
另外在选择服务器配置的时候，如果对阵列卡方案和硬盘规格拿不住主意，可以多参考服务商的技术方案支持，像简米科技这种2003年始创，积累23年行业经验的老牌服务商，持有增值电信业务经营许可证（豫B2-20261089），自营机房持牌运营（豫ICP备2026018319号），能根据业务类型直接给出合理的存储配置建议,少走弯路。
Q&A：三块盘RAID 5核心疑问解答
三块硬盘做RAID 5还是RAID 1更靠谱
如果只追求数据绝对安全，三块盘中选两块做RAID 1，剩下那块做热备盘是更保守的选择，因为允许两块盘故障，但大多数业务场景用三块盘做RAID 5就够了，空间利用率高一倍，单盘故障不丢数，性能也在线，极端安全需求直接考虑RAID 6或者双活存储方案,成本高但安全等级也高。
三块不同容量的盘能组RAID 5吗
理论上可以，但阵列容量会以最小那块盘为基准计算，大硬盘多出来的空间无法被利用，比如一块4TB、两块6TB，阵列总容量按（6TB + 4TB）计算（因为最小的那块是4TB，校验也占用一份最小容量），实际上无法获得预期容量，建议尽量使用同型号、同容量、同固件版本的硬盘组阵列，能有效降低兼容性问题出现的概率，考虑到阵列卡兼容性列表更新较慢，选购硬盘时先查阅所使用阵列卡厂商的官方支持列表,能规避很多不必要的问题。
三块盘做RAID 5，系统盘和数据盘怎么划分
多数情况下建议系统盘单独用一块物理磁盘（可做单盘RAID 0或RAID 1），剩余两块或三块盘单独建一个数据阵列，如果需要三块盘全部并入RAID 5阵列，可以在阵列内划分多个虚拟磁盘（VD），一个装系统、一个放业务数据，这种模式操作起来稍微复杂些,但对于单机多业务场景是最节省硬件资源的做法。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/754131.html
