如果你跟我一样整天和存储设备打交道，那“RAID 0/1/5/6/10”这几个数字绝对不陌生。很多人刚接触服务器时，第一课就是背RAID级别的概念：0要性能，1要安全，5折中，10又安全又性能。可真到了选型、建阵列、坏盘重建的时候，光靠背概念完全不够用。我也是在一次生产环境里吃过同样的亏：某天磁盘报警，阵列降级，重启后系统卡在重建界面，前后折腾了大半天。问题不在于单块硬盘本身，而是当初选RAID级别时根本没把重建期间的风险算进去。所以这篇东西我决定把五个级别的原理、性能表现、容量计算、适用场景、创建流程、故障恢复一次讲透，适合运维工程师、存储管理员，也适合家里组NAS自己折腾的朋友。
1. 先弄明白RAID到底解决了什么问题
1.1 从单块硬盘的“短板”说起
在RAID出现之前，一台电脑或服务器的数据存储能力基本被单块硬盘锁死。你买一块4TB机械硬盘，读写在机械结构限制下也就200MB/s上下，随机IO更是慢得让人焦虑。更麻烦的是，单盘一旦出现坏道或者固件问题，数据往往整套丢失，备份只存在于想象中的情况特别多。RAID的核心思路其实很简单：把多块物理硬盘组合成一个逻辑大磁盘，让这个“磁盘组”在容量、性能、可靠性上超过任何一块单盘。
可以这么理解：单盘是一个小饭馆，客流一大就忙不过来，厨师炒菜再快也有限。RAID相当于把好几个厨房并到一起，有帮厨切配、有厨师掌勺，整体出菜速度自然上去了。这个类比不精准，但方向是对的——RAID的意义并非某种黑科技，而是“堆基数”和“做冗余”。正因为知道单盘迟早会坏，才需要用冗余来兜底。
实际项目中，我看到不少人以为RAID等于“数据绝对安全”，这一点必须从最开始纠正。RAID只能防止“单块物理盘故障导致数据丢失”这个层面，它防不了误删除、程序bug、勒索病毒、电源浪涌、控制器故障。RAID是存储系统的一个组件，不是备份方案。搞清楚这个边界，后面选型才不会想当然。
1.2 RAID的三大核心能力：容量、性能、冗余
所有RAID级别，无论名字多花哨，本质都在围绕三件事打转：容量、性能、冗余。
容量方面，RAID会把多块盘的空间合并成一个大逻辑卷，但不同级别的“合并效率”差别很大。RAID0和RAID10基本可以看作完全利用所有硬盘容量，RAID5要拿出一块盘的容量存放校验数据，RAID6则要拿出两块盘的空间。性能方面，读写性能主要靠“条带化”实现：数据被切成固定大小的块，轮流写到各个物理盘上。比如一块文件总共240KB，条带大小64KB，那么它会被切出4个块，尽量分散到4块盘上，这样多块盘的磁头可以并行工作，吞吐量自然高过单盘。随机IO性能则要看是否能够多块盘同时响应请求，以及是否存在写校验开销。
冗余靠两种主要机制做出来：镜像和奇偶校验。镜像就是同一份数据写两份到不同磁盘，一颗盘挂了，另外一颗还有一模一样的副本。奇偶校验更像一种“数学挽回”的手段，用类似“A、B、C三块盘分别存数据和校验项，哪块坏了都能根据其他两块推出来”的逻辑来恢复。不同级别的差异，说白了就是把这三件事怎么组合的问题。理解了这三件事，看RAID0/1/5/6/10就不会再觉得是一堆需要背的表格了。
2. 逐个拆解 RAID 0/1/5/6/10
2.1 RAID 0：条带化换性能，但牺牲掉所有冗余
RAID0是最容易理解的级别，它就是把两块或更多磁盘通过条带化组合成一个更大的逻辑盘，数据块轮流写到每块盘上。它最少需要2块盘，空间利用率是100%，没有镜像也没有校验，任何一块盘坏了，整个阵列的所有数据都会彻底丢失。
为什么还要用它？因为它在顺序读写方面的提升非常直观。两块盘组成的RAID0，顺序读取速度在理想情况下可以接近两块盘的叠加值。对于视频剪辑、素材暂存、游戏盘这种“数据丢了可以重新生成、但写速度不够就很痛苦”的场景，RAID0还是很受欢迎的。我自己在测试环境做高频日志收集时也用过RAID0，纯粹是为了压榨磁盘吞吐，日志保留时间本来就短，丢一点无所谓。
但RAID0有个被很多人低估的风险：阵列里盘的数量越多，整体“年失效率”越高。假设单盘年故障率是1%，两块盘的阵列发生故障的概率并不是只有1%，而是两块中任意一块坏了都会灭失，大概接近1.99%。四块盘RAID0会更夸张。所以任何需要长久保存的数据，我都不会推荐RAID0。你可以拿它当“性能加速器”，但别拿它当“安全池”。
创建RAID0时有一个细节：条带大小（stripe size）很难说哪个绝对正确。默认的64KB在多数业务下是稳妥起点。如果你大量处理小块随机IO，可以尝试调低到32KB；如果偏大文件顺序读写，256KB以上或许更好。但条带大小必须在创建时定下来，后期要改只能备份数据重建阵列，所以团队里最好定个默认值。
2.2 RAID 1：镜像冗余，简单却“贵”
RAID1的做法是把数据同时写入两块物理盘，两块盘内容完全一样。最少2块盘，可用空间是总容量的一半。读性能有提升，因为控制器可以从两块盘同时读不同区块，写性能理论上是单盘水平，因为要等两盘都写完才算提交。
如果你系统里只有两个硬盘位，又想保住数据，RAID1几乎是唯一合理选择。操作系统盘、数据库事务日志盘、小型应用服务器的数据盘，用RAID1都非常合适。它的恢复逻辑也简单直观：一块盘拔掉，另一块盘就是完整副本，替换新盘后重建，过程相对稳妥。
RAID1的“贵”不仅体现在容量只有一半，还体现在很难扩展。大多数RAID1阵列不能通过增加一块盘变成三盘镜像并扩容，只能对拷出来重建。所以它的场景是“小容量高可靠”，而不是“大容量高利用率”。另外，很多人以为RAID1两块盘不会同时坏，现实中有两个坑：一是两块盘如果是同一批次，生产环境高负荷下可能存在同病相怜的固件缺陷，有一定概率先后坏；二是主控、电源、背板故障会让两块盘一起失效。RAID1只防盘故障，不防其他单点。所以系统盘用RAID1其实只是最低要求。
2.3 RAID 5：分布式奇偶校验，最广泛的折中方案
RAID5在很长一段时间里是中小型服务器“标准答案”。它最少需要3块盘，数据以条带方式写入，同时把校验数据打散存放在所有磁盘上，避免了独立校验盘成为热点的毛病。空间利用率是(N-1)/N，三块2TB盘的RAID5大约可用4TB，四块可用6TB。允许且仅允许一块盘故障，故障后降到降级模式，插入新盘后根据其他盘上的数据和校验信息重建丢失盘的数据。
校验的数学原理可以简化理解：假设三块盘，数据条带分别记为A、B，校验P则需要满足某种关系，比如P = A XOR B。当A盘丢失时，可以利用B和P反推出A。XOR的运算在RAID控制器上是用硬件逻辑实现的，非常快。实际实现里还会结合校验组、分布式排布，但底层就是这个思路。
RAID5最大的坑是“写惩罚”。因为每写一个数据块，都要读一次旧数据、读一次旧校验、写新数据和写新校验，一次用户写请求会被放大成4次底层IO。当然现代RAID卡有缓存合并优化，但具体业务下仍不能忽视。随机写密集的数据库业务用RAID5往往会发现IO延迟明显偏高。另外在重建期间，如果又有一块盘发生故障，数据就会全丢。大容量硬盘（比如单盘8TB以上）组成的RAID5，重建可能要跑一两天，这段时间的窗口风险不小。所以现在我在生产环境里，RAID5主要用于中小规模文件共享、开发测试环境、视频监控存储这类随机写不多、重建窗口可接受的场景。
2.4 RAID 6：双校验，用两块盘的容量换安全感
RAID6是RAID5的“加厚版”，最少需要4块盘，条带数据之外加入两组独立的校验数据P和Q，允许任意两块盘同时故障。空间利用率是(N-2)/N，也就是说4块盘里有两块用来保护数据，可用一半；8块盘则可用75%。重建时利用双冗余可以恢复任意两盘的丢失数据。
RAID6适合大容量、高价值、重建时间长的场景。因为盘数量越多、单盘容量越大，RAID5的重建窗口就越危险，RAID6相当于多买了一份保险。海量备份存储、较长周期的归档数据、NAS大型文件库，我都会倾向选择RAID6。
不过RAID6也有明显的代价。写惩罚比RAID5更重。每次数据写入要产生两个校验更新，通常需要读旧数据、读两个旧校验、写数据、写两个新校验，底层IO放大超过4倍，甚至到6倍左右。再加上控制器CPU/内存的开销，随机写性能会比RAID5更弱一点。再加上至少损失两块盘的容量，预算上需要认真计算。如果你业务的读写比例偏读、顺序写占大头、容量规模很大，RAID6的性价比才会显现。小阵列（4块盘）用RAID6，可用容量只有一半，此时更建议考虑RAID10。
这里再多说一句RAID6的“写惩罚算法”不是固定不变，不同厂商实现有差异。有的控制器借助日志和缓存能优化，有的软RAID实现更直接。所以做容量规划时，不能只看标称吞吐，要实际用类似业务的压测脚本跑一遍，否则上线后IO延迟会让你措手不及。
2.5 RAID 10：先镜像再条带，兼顾性能与安全
RAID10的全名是“镜像+条带”，最少需要4块盘，结构是先组成若干镜像对，再把镜像对条带化成逻辑卷。比如四块盘A、B、C、D，先让A和B组成镜像对，C和D组成另一个镜像对，然后在两个镜像对之间做条带。可用空间仍是50%，允许的故障数不是固定的2块，而是取决于故障盘的位置。
RAID10最大的优点是性能好且恢复稳定。RAID5/6在写操作时需要读取旧数据和旧校验，存在明显写惩罚；RAID10写操作只需要把数据同时写到两个镜像盘，底层IO放大比RAID5/6小得多。随机读写性能在数据库这类场景里表现很突出。重建也相对舒服，坏了一块盘后，只需要从它对应的镜像盘做完整复制，不需要动用其他所有磁盘做奇偶计算，重建速度通常远快于同容量的RAID5/6。
RAID10的容错要讲清楚：如果四块盘组成的阵列，I/O模式是坏一块，阵列仍在镜像对冗余下运行；同一时刻运气不好，坏的两块落到了同一个镜像对里，那整个阵列的数据就丢了。坏两块但分属不同镜像对，阵列依然可以存活。所以RAID10的容错上限是“每个镜像对最多坏一块”。因为大多数情况下坏盘呈随机分布，四盘RAID10在两块盘同时故障时仍有约三分之二的概率能活过一场。这里有个常见误区：很多人以为RAID10和RAID01是同一个东西。RAID01是先条带后镜像，中间条带组坏掉一盘就可能波及整个镜像结构，可靠性显著不如RAID10。这也是存储界不太推荐RAID01的原因。选的时候一定要看准控制器界面里“RAID10”这个写法，别被命名绕晕。
3. 选型对比与场景匹配
3.1 一张表看懂五个级别的差异
到了真正选型的时候，表格比长篇大论好用。下面这张对照表是我在实际项目里经常直接拿给团队解释的版本。
| RAID级别 | 最小盘数 | 空间利用率 | 允许故障盘数 | 读性能 | 写性能 | 重建风险 | 典型场景 |
|---|---|---|---|---|---|---|---|
| RAID0 | 2 | 100% | 0 | 高 | 高 | 无冗余，坏一盘全毁 | 临时数据、游戏盘、缓存 |
| RAID1 | 2 | 50% | 1块（每组镜像） | 有所提升 | 单盘水平 | 低，镜像复制即可 | 系统盘、日志盘 |
| RAID5 | 3 | (N-1)/N | 1块 | 较好 | 存在写惩罚 | 中，重建时间长，期间再挂盘会丢 | 文件共享、开发测试、监控存储 |
| RAID6 | 4 | (N-2)/N | 2块 | 较好 | 写惩罚更重 | 中高，容量越大重建越长 | 海量备份、归档、大容量NAS |
| RAID10 | 4 | 50% | 每组镜像至多1块 | 很好 | 很好 | 低，重建以镜像复制为主 | 数据库、虚拟化、核心生产 |
这张表里的“读性能”“写性能”都是相对概念，实际还要看是顺序还是随机、硬盘类型、控制器缓存、IO大小。不要拿表里的定性描述直接推导硬件配置。比如全闪存阵列里，RAID5的写惩罚虽然还在，但底层SSD的随机能力很强，有时候为了利用率选RAID5反而合理。判断依据永远是业务模型和风险偏好。
3.2 不同业务怎么选：数据库、文件存储、视频剪辑、冷备份
下面我按业务类型总结一下我自己的默认思路。
关系型数据库的核心数据卷，我最常用的还是RAID10。数据库OLTP场景最明显的特征是随机读写多、单次IO小、对延迟极度敏感，RAID10在这种模式下既有不错的并发，又能在单盘故障后快速重建。如果预算非常紧张，至少保证事务日志用RAID1或RAID10，数据文件别用RAID0。
大容量文件共享、NAS、视频监控这类业务，随机写不多，主要以顺序读写为主，可用容量也是硬指标。这种场景RAID5比较划算，但单盘容量超过8TB或者总容错要求更高时，我会换成RAID6。原因前面说过，大容量盘重建周期很长，期间再挂盘的概率不能被忽略。
视频剪辑或者渲染农场，素材可以被重新渲染，只有“跑得快”才重要。这种情况下RAID0经常被摆上台面，但我实际给建议时会在RAID0和RAID10之间做个成本博弈：如果素材完全可再生，RAID0没问题；如果有一些原始采集素材不够好找回，那就用RAID10而非RAID0，至少风险降低一个数量级。
冷备份和归档数据，访问频率很低，但丢不起。容量要大、要抗多盘故障。RAID6是我的默认选项。你可以结合离线冷备或分布式副本再加一道保险，RAID6只负责把在线存储这段做扎实。
3.3 硬件RAID与软件RAID怎么取舍
实现RAID的途径主要分为硬件RAID控制器、主板集成RAID和操作系统软件RAID。
硬件RAID控制器最大的优势是带有独立处理器和缓存，不占用CPU，还能在断电时依赖缓存电池/电容把未落盘数据刷入，性能表现稳定。但它的选择陷阱也很多，比如入门级RAID卡没有缓存、没有掉电保护，跑RAID5/6的写性能可能反而难看。部分“主板集成RAID”本质是厂商用驱动做了个半软半硬的方案，平时用没问题，操作系统坏了想换平台迁移阵列时，兼容性会让你头大。
软件RAID在Linux服务器上很常见，用现成的软件RAID工具就能创建，许多发行版都内置。它的优点是灵活、可跨平台恢复、成本低，缺点是会占用CPU，且如果操作系统坏了，恢复时要用对应发行版的救援环境把阵列重新组合起来。再有就是ZFS这类文件系统级别的存储池，也具备镜像、条带和校验能力，逻辑上比传统RAID更灵活，但它不是传统意义上的RAID级别，选型时要单独讨论。
我个人倾向是：物理机上的生产数据库，尽量用带缓存和电池保护的硬件RAID；虚拟化主机内部可以用硬件RAID做底层数据卷；普通文件服务和开发测试环境，软件RAID完全够用。主板RAID能不用就不用，除非你对整套平台的“假RAID”行为非常了解。
4. 实操：创建阵列、监控健康与故障快速恢复
4.1 创建阵列前的准备：硬盘与控制器
这个环节看起来基础，但我的经验是80%的后续故障都和开始没准备利索有关。
首先，硬盘尽量同型号、同容量、同固件批次。不要为了省预算在阵列里混用5400转和7200转机械盘，也不要混用不同容量盘强制把小盘空间截断。不同转速和缓存大小会导致整个阵列按照最慢的盘工作，部分盘的延迟异常还会让控制器把盘误判为超时。容量混用可以，但建议按“最小容量”统一映射，千万别指望以后换大盘自动扩容，很多阵列做不到。
其次，上机前务必做一次基础健康检查。机械盘先看SMART信息，确认通电时间、重映射扇区、待处理扇区、CRC错误计数都是健康状态。新盘也应检查，不能默认“新盘没问题”。
第三，想清楚条带大小、写策略、初始化方式。写策略里Write Back需要电池/电容保护才建议开，没有掉电保护时宁可牺牲写性能也要用Write Through，否则停电容易损坏数据。初始化方式一般有两种：快速初始化和全量初始化。生产环境建议做全量初始化，虽然速度慢，但能提前发现“带病盘”。我见过太多人为了赶时间选快速初始化，结果上线后坏盘直接把阵列拖垮。
4.2 从零开始创建一个阵列的具体操作
如果用某个Linux发行版的软件RAID，命令逻辑大致是：
- 先确认盘符和分区，比如拿四块空盘sdb、sdc、sdd、sde做RAID10：
lsblk -o NAME,SIZE,MODEL,SERIAL- 对每块盘创建分区（可以整盘作为一个分区）：
parted /dev/sdb mklabel gpt parted /dev/sdb mkpart primary 1MiB 100%- 创建RAID10卷：
mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1- 查看创建进度和状态：
cat /proc/mdstat mdadm --detail /dev/md0- 创建文件系统并挂载：
mkfs.xfs /dev/md0 mkdir /mnt/array mount /dev/md0 /mnt/array- 将阵列结构写入配置，保证重启后能自动组装：
mdadm --detail --scan >> /etc/mdadm.conf如果是硬件RAID卡，通常在开机自检阶段进入阵列配置界面。流程基本是：选中“Configuration Wizard”，选择“New Configuration”，然后把物理盘标记为Unconfigured Good，按组合键加入磁盘组，选定RAID10级别，设置条带大小和写策略，执行初始化。保存配置后开机，系统里会看到一块逻辑盘。
这里面最容易被忽略的步骤是把磁盘连接顺序、机器名、阵列结构记到文档里。出故障时别人（包括未来的你）能靠文档快速定位，而不是摸黑拆盘。
4.3 监控阵列健康状态：别等问题报警才去登录服务器
我强烈建议在阵列建好的当天就把监控配好。软RAID下可以定时读取/proc/mdstat，或者用脚本解析mdadm --detail输出，检查有没有降级标记。硬件RAID卡本身带管理工具和日志，可以查看每个磁盘的SMART状态、Media Errors、Other Errors等指标。
监控不只盯“阵列是否降级”，还要盯“硬盘健康趋势”。比如机械盘的Reallocated Sector Count如果持续增长，说明这块盘已经开始出现坏道转移，虽然还没触发阵列容错，但距离故障可能不远。Current Pending Sector的存在也要警惕，它是坏道等待重映射的队列。遇到这种盘，正确的做法是尽快申请运维窗口把它换掉，而不是等它彻底罢工。
除了SMART，还可以观察IO层指标。一块盘的平均等待时间（await）如果突然从2ms涨到50ms以上，可能是盘在重试坏道，也可能是写缓存策略出问题。RAID卡日志里的错误计数持续增加时，别忽略。
4.4 硬盘故障后的替换与重建流程
真实的生产环境里，硬盘不会像教材一样按“友好顺序”坏给你看。我一般按下面这套顺序处理：
- 先确认报警级别。如果阵列日志显示Disk X故障，先用监控工具确认是逻辑错误还是物理离线。
- 不要让坏盘继续留在阵列里“拖累”整个系统。在确保数据有完整备份的前提下，把故障盘标记为离线（Offline）或直接禁用，然后热拔出换新盘。
- 新盘物理插入后，确认新盘容量不能小于故障盘的容量，最好完全一致。如果控制器没有识别到，先做RAID卡层面的扫描。
- 让阵列进入Rebuild（重建）流程。软RAID通常自动开始，也可以手动添加盘到阵列：
mdadm /dev/md0 --add /dev/sdf1- 重建期间持续观察
/proc/mdstat的进度和速度。如果重建速度突然掉到极低，要排查是否有后台业务IO在抢占磁盘，或者新盘有大量坏块。
有热备盘当然是更理想的方案，一块盘故障后无需人工干预，热备盘自动顶上。但热备盘不是万灵药，热备盘本身也可能因为长期闲置出现介质弱化，所以定期巡检时要把热备盘当作工作盘一样看SMART信息。
5. 常见问题与排查技巧
5.1 阵列降级后系统还能不能跑
能跑，但要以“随时可能再丢一块盘”的心态对待。RAID5在降级状态下可以继续提供读写，但每读取一次降级数据都需要从其余盘做奇偶计算，延迟会明显上升。写入更糟糕，因为既要保证数据落盘，校验盘也少了一块，整体性能会打折。
我个人操作原则是：只要阵列进入降级状态，立刻评估是否有完整备份，如果备份没做过，就先从降级阵列把最关键的数据复制出来，再考虑换盘重建。并不是每次都能从容操作。有的团队在RAID5掉盘之后还在正常跑业务，结果第二天又挂了一块，然后所有数据直接蒸发。这种时候没有后悔药，所以降级是重大事件，不是普通告警。
5.2 重建时为什么“卡住”或失败
重建卡住的原因通常有几类。第一类是后台业务IO压力太大，重建进程一直抢不到磁盘资源，速度长期为0KB/s或极低。可以用系统工具看下IO占用，必要时临时把业务读写停掉或降低负载。第二类是新盘本身有大量Pending Sector，重建过程中反复重试，表现为几个小时还在1%左右。第三类是阵列控制器和硬盘之间出现通信问题，常见于背板接口松动、线缆老化，或者固件不兼容，日志里会有大量超时记录。
重建失败后的处理要格外冷静。不要立刻把“新盘”拔下来再插回去，反复热插拔很容易导致更多信息丢失。我的做法是：先保存阵列日志，确认新盘是否被正确识别为成员盘；如果是软RAID，检查mdadm --detail里的事件计数是否异常；然后尝试把坏盘重新上线一次，如果仍然失败，把数据盘全部标记好位置，再拿到另一台正常的环境里尝试用只读方式组装阵列。
5.3 几个容易被误判的硬盘健康指标
SMART指标很多，不用全部看懂，但下面几个要盯住。
Reallocated Sector Count（重映射扇区计数）上升说明盘内已经有坏道被备用扇区替换。少量的值抖动也许还能忍，但如果连续几天都在涨，这块盘就要准备退役。Current Pending Sector（待重映射扇区）意味着有扇区暂不能被读取，写入时才发现能不能重映射，如果数值不为零，这块盘其实已经带病运行了。UDMA CRC Error Count则是接口传输错误，和盘片无关，但往往预示线缆、背板或电源问题，我见过因为这个指标升高而误判为怀疑硬盘故障的。
除了SMART，还需要看RAID控制器的日志。Unexpected Power Loss、Reset、Media Errors这些关键词一旦频繁出现，都是排查线索。
5.4 误操作与配置丢失场景
有一类问题最心塞：系统重启后阵列识别不出来了。硬件RAID卡这种时候大概率是配置丢失或硬盘顺序变化，不要随便上去就“Initialize”。最安全的是找到当时的阵列配置记录，再让控制器重新导入外部配置。软件RAID相对容易恢复，重新组装命令一般是：
mdadm --assemble --scan /dev/md0如果无法自动组装，可以手动指定成员盘：
mdadm --assemble --run /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1核心原则是只读救援，绝不重新初始化。没有任何备份的情况下，一旦执行了错误的重建动作，神仙难救。
6. 那些年我踩过的坑，以及现在养成的习惯
6.1 硬盘混用与“全盘容量对齐”的坑
以前图省钱，在一组大容量阵列里混入了一块不同品牌的小容量盘，RAID卡自动按最小容量映射，整组大几TB的空间一下子缩水，性能也因为小盘延迟高而拖慢。后来只好把数据搬走，重新换盘重建，白白折腾一个周末。现在我的规矩是：阵列内所有盘尽量同一品牌、同一型号、同一固件版本，容量可以因为批次不同有微小差异，但必须在RAID卡层面看到具体容量完全一致。
6.2 告警一定要“打出去”
早期我给一台存储做了RAID1，之后因为各种原因把系统日志查看频率降到了一个月一次。结果某天半夜阵列已经降级了两天，业务还一直扛着，我完全不知道。直到另一块盘也异常，系统才彻底崩溃。从那以后，我要求所有阵列的SMART状态、降级状态、重建进度都通过监控渠道推送出来，至少要发到手机。告警不是给服务器看的，是给值班的人看的，发不出来的告警等于不存在。
6.3 重建期间不要强行跑大负载
有一次在RAID5重建过程中，开发团队正好要导一批大数据，直接把写压力拉满，重建进度卡了几个小时。我当时也着急，选择暂时中止重建，等业务低峰再恢复。后来学到的经验是：给重建设置合理的IO优先级，不要让它和业务抢资源，也不要让它长时间停滞。软RAID环境下，可以通过系统参数限制重建速度；硬件RAID卡也大多有重建速度选项，设为“中速”通常比较稳。
这些习惯并不复杂，但它们确实让后来几年的运维安稳了很多。如果你刚开始摸RAID，我的建议很简单：先备份，再选型；选完型，在测试环境里模拟一次坏盘重建，确信自己知道整个过程会发生什么，再上生产。毕竟阵列掉盘这种事，迟早会遇到。
