RAID原理、选型与故障处理：从条带化、镜像、校验到RAID 5/6/10实战

RAID 这个词，大多数人第一次见到是在装机店的配置单上，第二次见到是在机房的告警邮件里。它的中文名叫独立磁盘冗余阵列，核心思路说白了就一句话：把几块普通硬盘用条带化、镜像、校验这三种基本手法组合起来，对外呈现成一个容量更大、读写更快、或者更不容易因为单块盘损坏而丢数据的逻辑盘。这套东西从服务器机房一路渗透到家用 NAS、监控录像机、剪辑工作站，几乎只要涉及"多块盘"的场景就绕不开它。但真正把 RAID 用明白的人并不多，我见过太多把 RAID 当成备份的、把 RAID 5 堆到十几块大容量盘还觉得稳的、重建到一半第二块盘亮红灯的。这篇就把 RAID 从原理到选型、从建阵列到故障处理完整捋一遍，不管你是刚接触存储的新手，还是天天跟阵列卡打交道的老兵，应该都能捞到点东西。

1. 先把话说清楚：RAID 到底在解决什么问题

1.1 单块硬盘的三道坎

一块硬盘的能力是有物理天花板的，而且这三道坎互相打架。第一是容量，单盘再大也有上限，而且盘越大单价往往越不划算；第二是性能，机械盘受限于主轴转速和磁头寻道，随机 IOPS 长期卡在一两百这个量级，顺序读写也就两三百 MB/s，SATA 接口的固态盘虽然能跑到五百多，但接口带宽和主控通道数一样有顶；第三是可靠性，任何一块盘都有故障率，厂商标称的 MTBF 动辄上百万小时，可那是统计意义上的平均值，落到你手里那块盘上，明天坏和五年后坏都是有可能的。更麻烦的是，这三者往往不能同时满足——想要大容量就得接受更多盘片和更长寻道，想要高性能就得付出更高成本。RAID 的出发点，就是用"多块盘协同"这个手段，把这三道坎分别往上顶一顶。

1.2 RAID 的能力边界：它能救什么，救不了什么

很多人对 RAID 的期待过高，这是所有事故的起点。RAID 真正能救的只有一类问题：磁盘介质的物理性故障。盘片划伤、磁头卡死、电路板烧了、固件挂了，这类故障只要冗余还在，阵列就能继续对外提供服务，你换块盘插回去重建就行。但 RAID 救不了的东西同样一长串：误删文件、格式化错分区、勒索软件加密、文件系统元数据损坏、操作系统层面的逻辑错误、机箱进水、电源浪涌把整机带走、阵列卡或背板故障、机箱被盗。这些场景下，RAID 的镜像和校验会非常忠实地把错误数据同步到每一块盘上。所以行业里有句被说烂了但依然有人不信的话：RAID 不是备份。备份要求的是时间维度上的多份副本和离线隔离，RAID 给的是同一时刻的空间维度冗余，两者根本不是一回事。

1.3 几个必须先纠正的认知

第一个误区是"盘越多越安全"。实际情况恰恰相反，阵列里的盘越多，单盘故障的概率叠加就越高，重建时要读取的数据量也越大，重建窗口越长，二次故障的窗口也就越长。一个 24 盘的 RAID 5，年故障概率远高于 4 盘 RAID 5。第二个误区是"RAID 0 不算 RAID"。它确实没有冗余，但它是最纯粹的条带化实现，在临时缓存、渲染中间文件、只读镜像分发这类"数据可重建"的场景里，RAID 0 的性价比高得离谱。第三个误区是"阵列卡上的缓存越大越好"。写缓存只有在有电池或超级电容保护的前提下开 Write Back 才是安全的，没有掉电保护的写缓存，一次意外断电就足以让整个文件系统报废。这几点在后面的章节里还会反复提到，先把地基打牢。

2. 三块积木：条带、镜像、校验

2.1 条带化：把 IO 切碎了并行发出去

所有 RAID 级别的地基都是条带化。做法是把每一块成员盘按固定大小切成一段一段，这个固定大小叫chunk或者 strip，常见取值 64KB、128KB、256KB、1MB。然后数据按顺序轮流写到各块盘上：第 1 个 chunk 写盘 A，第 2 个写盘 B，第 3 个写盘 C，写满一圈再回到 A。于是一个大文件的顺序读取，就变成了 N 块盘同时往外吐数据，聚合带宽接近单盘带宽乘以盘数，这是 RAID 0 和所有带级别的性能来源。这里有个容易混淆的概念：chunk 是单块盘上的一段，stripe是一次并行写满所有数据盘的总量，等于 chunk 乘以数据盘数量。比如 6 块盘的 RAID 5，数据盘 5 块，chunk 64KB，那么一个 stripe 是 320KB。这个数字很关键，后面讲文件系统对齐和条带大小选择时都要用到它。

条带大小选错，性能会明显打折。基本原则是看你的 IO 特征：如果业务以大文件顺序读写为主，比如视频素材、备份归档、日志落盘，块可以给大一点，256KB 到 1MB 都行，这样单次 IO 能覆盖多个数据盘，带宽拉满；如果是数据库、虚拟化这类以小 IO 随机读写为主的负载，块要小一些，64KB 甚至 32KB，避免一次 8KB 的随机读反而触发了跨盘寻道。这里有个反直觉的点：条带太小也不好，同样大小的顺序读会被拆成更多次跨盘访问，每次都要等所有盘响应，延迟反而上升。我个人的经验起点是数据库类 64KB、文件服务器 128KB、媒体素材库 256KB 到 512KB，然后拿真实业务压测再微调。

2.2 镜像：最暴力也最可靠的冗余

镜像的逻辑简单到不需要解释：同一份数据同时写到两块盘上，读的时候从任意一块读都行。RAID 1 就是两块盘互为镜像，RAID 10 是先把盘两两配对做镜像，再把多组镜像条带化拼起来。镜像的好处非常实在：写的时候要写两份，写放大是 2 倍，但读的时候可以两块盘并行读不同的请求，随机读性能接近翻倍；重建的时候只需要从存活的那块盘完整拷一份数据过去，重建速度快，而且重建过程中另一块盘的状态是明确的，不存在校验计算失败的问题。代价是容量利用率只有 50%，四块 8TB 盘做 RAID 10 只有 16TB 可用，这是硬成本。所以 RAID 10 一般用在两个地方：一是写密集且对延迟敏感的业务，二是盘位和预算都还算宽裕但数据非常重要的场景。

镜像还有个容易被忽视的细节：它防不住"逻辑性损坏的同步"。如果文件系统写入了错误数据，或者某块盘固件有 bug 返回了脏数据，镜像会把这个错误原样写到两块盘上，你读到的是两份一致的错误。这一点决定了镜像只能解决介质故障，不能解决数据正确性问题。真正要防静默损坏，靠的是上层文件系统的校验和与定期 scrub，而不是 RAID 级别本身。

2.3 校验：拿 CPU 换容量，代价是写惩罚

校验的思路是：不存完整副本，只存一份由所有数据块异或运算得出的校验块，任何一块数据丢了，用剩下的数据块和校验块异或回去就能恢复。RAID 5 用一份校验，允许坏一块盘；RAID 6 用两份独立的校验（通常是异或加伽罗瓦域运算），允许坏两块盘。容量利用率因此大幅提升，RAID 5 是 (N-1)/N，RAID 6 是 (N-2)/N，六块盘的情况下分别是 83% 和 67%，比镜像的 50% 好看太多。

但校验的代价藏在写操作里，这就是所谓的写惩罚。一次随机小块写，RAID 5 需要先读出旧数据块、读出旧校验块，算出新校验，再写回新数据块和新校验块，一共 4 次磁盘 IO 才算完成一次逻辑写。RAID 6 更狠，要读旧数据、读两个旧校验，写新数据、写两个新校验，6 次 IO。RAID 10 只写两份，2 次 IO。把这个换算成可用写 IOPS，公式就很清楚了：假设单盘随机写能力 100 IOPS，8 块盘的 RAID 5 有 7 块数据盘，写 IOPS 大约是 7×100/4 = 175；同样 8 块盘的 RAID 10 是 8×100/2 = 400。差了将近一倍多。这就是为什么数据库这类写密集业务，很多时候宁愿牺牲容量也要上 RAID 10。

2.4 热备盘与重建：冗余真正兑现的时刻

冗余在平时是没有存在感的，只有一块盘挂掉、阵列进入降级状态的那一刻，它才真正开始工作。这时候如果有热备盘，阵列卡或软件会自动把热备盘拉进来顶替故障盘，开始重建。热备盘分两种：全局热备可以被任意阵列征用，专用热备只服务指定的那个阵列。盘位紧张的时候用专用热备更省，但灵活性差；盘位宽裕就用全局热备，利用率高。

重建的过程本质上是把缺失的数据重新算出来写到新盘上。镜像类重建是直接拷贝，速度取决于源盘的顺序读能力；校验类重建要读取同 stripe 内所有其他数据盘和校验盘，一边读一边算，对整组盘都是满负荷冲击，这段时间阵列性能会明显下降，业务侧能感觉到延迟抖动。重建时间跟单盘容量强相关，粗略估算一下：一块 8TB 的盘，实际重建速率受限于单盘顺序读和阵列卡处理能力，按有效 80MB/s 算，8,000,000MB ÷ 80MB/s ≈ 100,000 秒，差不多 28 小时。这还只是理想情况，业务压力大、盘本身有坏道、重建优先级被限制，拖到两三天都很正常。这 28 小时就是你的风险窗口，窗口期内再坏一块盘，RAID 5 直接归零。所以重建速率限制这个参数要慎用，它能保护业务性能，但也实实在在地延长了危险期。

3. 各 RAID 级别逐个拆：容量、性能与适用边界

3.1 RAID 0 与 RAID 1：两个极端

RAID 0 是纯条带，容量利用率 100%，读写性能随盘数线性提升，但没有任何冗余，任何一块盘挂了整个阵列的数据全部不可读。它的合理使用场景非常明确：数据本身可以从别处重新生成或者重新下载，且对性能极度渴求。比如视频剪辑的代理文件缓存、渲染农场的临时输出目录、只读镜像的分发节点。反过来说，只要这份数据丢了你会心疼，就别用 RAID 0。

RAID 1 是纯镜像，最少两块盘，容量利用率 50%，读性能接近翻倍，写性能基本等于单盘，重建速度最快，配置最简单。它最适合小规模、高价值的场景：系统盘、数据库日志盘、小型办公文件服务器。两块大容量盘做 RAID 1 现在很常见，因为单盘容量上去了，两块盘就能凑出够用的空间，而且重建窗口短、风险低。唯一要接受的就是那一半的容量损失。

3.2 RAID 5：性价比之王，也是踩坑最多的地方

RAID 5 是最广为人知的级别，也是被误用最严重的级别。它的账面上确实漂亮：最少三块盘，容量损失一块，读性能接近条带，写性能受写惩罚影响但还能接受。在机械盘容量还停留在几百 GB 到 1TB 的年代，RAID 5 几乎是默认选项，因为重建一块 500GB 的盘只要一两个小时，风险窗口很短。

问题出在盘容量暴涨之后。一块 8TB 甚至 16TB 的盘，重建动辄二三十小时，而重建过程中需要读取整个阵列的所有扇区。这里有个绕不开的物理现实：大容量机械盘在长时间满负荷读取时，遇到不可恢复读错误的概率不再是理论值，而是实实在在会发生的事。一旦重建过程中某块盘报出读错误，RAID 5 没有第二份校验可以兜底，重建直接失败，整个阵列的数据就废了。所以现在的通行做法是：单盘容量超过 4TB 的阵列，基本不推荐 RAID 5，要么上 RAID 6，要么上 RAID 10。如果非要用 RAID 5，成员盘数量控制在 4 到 6 块，别堆到十几块。

3.3 RAID 6 与 RAID 10：大容量盘的现实选择

RAID 6 用两份校验换来"同时坏两块盘还能活"的能力，最少四块盘。它的价值不只是多一层保险，更重要的是重建期间的安全性：RAID 5 重建时只要再来一块盘出问题就完了，RAID 6 重建时还有一份冗余顶着，而且第二份校验能帮助定位到底是哪一块盘读错了，RAID 5 只能发现"这组数据错了"却不知道是谁错的。代价是写惩罚更重（6 次 IO），写性能比 RAID 5 再降一截，容量利用率也更低。对于近线存储、备份归档、监控录像、大容量 NAS 这类"写入不小但延迟不敏感"的场景，RAID 6 是非常合适的平衡点。

RAID 10 走的是另一条路：用容量换性能和恢复速度。它最少四块盘，容量利用率 50%，读性能接近条带，写性能是 RAID 5 的两倍多，重建速度快、重建期间对同组盘的压力小。对于数据库、虚拟化宿主机、任何写密集且延迟敏感的业务，RAID 10 通常是首选。我见过不少团队在数据库服务器上纠结 RAID 5 和 RAID 10 的容量差，最后因为一次重建超时把整个库搞挂，之后再也没碰过 RAID 5。

3.4 RAID 50/60：组合级别的适用场景

RAID 50 是多个 RAID 5 子组再条带化，RAID 60 是多个 RAID 6 子组再条带化。它们的意义在于降低单个子组的盘数，从而缩短重建时间和重建影响范围。举个例子，12 块盘如果直接做 RAID 6，成员盘太多，重建时要读 11 块盘；拆成两个 6 盘 RAID 6 子组再做条带，每个子组只有 6 块成员盘，重建只影响这个子组，速度和风险都更可控。代价是每个子组都要损失自己的校验盘，容量利用率进一步下降，而且故障域变成了"每个子组各能坏 N 块"，不是全局的。这类组合级别适合盘位多、容量大、又不想上 RAID 10 的中大型存储池，小规模场景没必要折腾。

3.5 一张对照表和几个必须会算的数

容量算法很直白，但要留意厂商标称容量的十进制陷阱：8TB 的盘在操作系统里看到大约是 7.28TiB，六个 8TB 盘做 RAID 5，可用容量是 5×8TB=40TB 标称，系统里显示大约 36.4TiB，再扣掉文件系统元数据，实际能用的还要少一点。做容量规划时按系统显示的数值算，别按包装盒上的数字算。

再算一个 IOPS 的账。假设 8 块万转机械盘，单盘随机写 130 IOPS，做 RAID 6：数据盘 6 块，写 IOPS ≈ 6×130/6 = 130，几乎和单盘持平；同样的盘做 RAID 10：写 IOPS ≈ 8×130/2 = 520，是 RAID 6 的四倍。这就是为什么 OLTP 数据库基本不考虑 RAID 6。如果换成固态盘，单盘 IOPS 上万，写惩罚带来的绝对差值会被放大，但固态盘本身没有寻道开销，写惩罚的影响方式又不一样，这块后面单独说。

4. 落地：从选型到建阵列的完整操作

4.1 硬件 RAID、软件 RAID，还是干脆不用

硬件 RAID 依赖独立的阵列卡，卡上有自己的处理器和缓存，操作系统看到的是一块逻辑盘，跟底层细节完全解耦。优点是管理简单、性能稳定、有掉电保护的写缓存、热插拔和重建都是卡自己完成的，跟操作系统无关。缺点是卡本身是单点，卡挂了你得找同型号的卡来导配置，跨品牌迁移基本别想，而且卡上缓存没有后备电池或超级电容时千万别开 Write Back。

软件 RAID 把活交给操作系统，Linux 下的 mdadm、各类支持校验和的文件系统、Windows 的存储空间都属于这一类。优点是配置透明、不依赖特定硬件、迁移方便、阵列元数据跟着盘走，出问题能在另一台机器上直接组装起来。缺点是要吃 CPU，重建时对系统负载有影响，而且没有硬件缓存，写性能在某些场景下不如硬件方案。对于预算有限、盘位不多、或者用通用服务器搭存储的场景，软件 RAID 完全够用，我个人的很多环境就是 mdadm 加一层文件系统校验，稳定跑好几年。

还有第三种选择：不用 RAID。现在云主机、对象存储、分布式存储系统在底层已经做了多副本或纠删码，你在单机上再做一层 RAID 5 属于重复建设，反而增加了故障点。单机场景如果数据量不大、恢复时间要求不高，直接用单盘加备份，比搭一个半吊子的 RAID 更实在。

4.2 建阵列前必须敲定的几个参数

条带大小按前面的原则选，数据库 64KB，文件服务 128KB，媒体 256KB 到 512KB。写策略在有电池或超级电容保护的前提下开 Write Back，没有就老老实实 Write Through，别为了跑分好看去赌断电。初始化方式分快速初始化和完全初始化，快速初始化只写元数据，几秒钟完成，但后台会慢慢补齐校验，这段时间阵列性能是抖的；完全初始化会把所有扇区写一遍，耗时可能十几个小时，但完成后阵列状态是干净的，我一般建议新阵列在不赶时间的情况下走完全初始化。

文件系统对齐是很多人忽略的一步。如果文件系统的块大小和 RAID 的条带没对齐，一次逻辑写会跨越两个物理 stripe，触发读改写，性能直接腰斩。用 ext4 的话，mkfs.ext4时把stride设成 chunk 除以文件系统块大小，stripe-width设成 stride 乘以数据盘数。举例：chunk 64KB，文件系统块 4KB，那么 stride = 16，6 盘 RAID 5 数据盘 5 块，stripe-width = 80。XFS 用的是su（条带单元）和sw（条带宽度），单位是块数，逻辑一样。固态盘做 RAID 还有个额外的坑：要确认 TRIM/DISCARD 能不能透传，很多硬件阵列卡是不支持的，长期跑下去写放大和寿命都会受影响。

下面这套参数是我按常见业务负载总结的起点，不是标准答案，落到你的环境还得靠实测微调。

# 六块盘做 RAID 6，条带 64KB，带内部写意图位图 mdadm --create /dev/md0 --level=6 --raid-devices=6 \ --chunk=64K --bitmap=internal /dev/sd[b-g] # 查看组装状态和重建进度 cat /proc/mdstat mdadm --detail /dev/md0 # 文件系统按条带对齐：chunk 64K / 块 4K = stride 16，数据盘 4 块 mkfs.ext4 -E stride=16,stripe_width=64 /dev/md0

那个--bitmap=internal是软件 RAID 的一个实用开关。没有位图的时候，一次非正常关机后重启，阵列要做全量一致性校验才能上线，8TB 级别的阵列可能卡几个小时；有了位图，只重扫脏区域，几十秒就能恢复服务。代价是写路径上多一点点开销，但在大多数场景下这个交换非常划算。

4.3 初始化完成之后要做的三件事

第一件是记录配置。把mdadm --detail的输出、阵列卡的配置导出、每块盘的序列号和槽位对应关系全部存一份到别的地方。真出事的时候，你会无比庆幸自己有这份记录——尤其是硬件阵列卡坏了要换卡导入配置的时候，槽位顺序错一位，数据就可能对不上。

第二件是建立监控。至少要盯四个指标：阵列健康状态、单盘 SMART 里的重映射扇区数和待定扇区数、文件系统使用率、重建/校验任务的进度。SMART 里的Reallocated_Sector_Ct和Current_Pending_Sector只要开始非零增长，就说明这块盘在走下坡路，别等到它被阵列踢出去才动手。监控采样频率别太高，机械盘的 SMART 查询本身有开销，一天一次足够，但阵列状态要频繁一点。

第三件是设定巡检周期。带校验的阵列要定期做一致性校验（也叫巡检读），把整组盘的所有扇区读一遍，发现读错误就尝试用校验修复。频率一般一个月一次，放在业务低峰期，并且一定要给校验任务限速，否则它会把整个阵列的 IO 吃满。

# 手动触发一次一致性校验 echo check > /sys/block/md0/md/sync_action # 限制后台校验速率，避免打满业务 IO（单位 KB/s） echo 50000 > /sys/block/md0/md/sync_speed_max # 查看当前校验进度 cat /sys/block/md0/md/sync_completed

4.4 坏盘替换的标准动作

发现降级之后，第一反应不应该是拔盘，而是先确认是哪块盘真的坏了。看阵列状态定位到具体槽位，再去看这块盘的 SMART 和内核日志。如果只是超时被踢、SMART 全绿、日志里全是链路层错误（CRC 错误、复位、超时），那大概率是线缆、背板或者接口接触问题，换盘没用，换线或者换个槽位可能就好了。这种情况我遇到过不止一次，急着换盘反而把好好的盘换走了，问题依旧。

确认是盘的问题后，热插拔换上新盘，然后把它加回阵列。软件 RAID 的操作是这样：

# 先把故障盘标记为移除 mdadm /dev/md0 --fail /dev/sdc --remove /dev/sdc # 插入新盘后加入阵列，开始重建 mdadm /dev/md0 --add /dev/sdc # 重建期间盯着进度 watch -n 60 cat /proc/mdstat

重建期间要控制业务压力，别在这时候跑大批量备份或者全表扫描。如果阵列支持重建速率限制，把它调低一点，用时间换安全。重建完成后一定要再做一次一致性校验，确认新盘上的数据算出来是对的。

5. 故障现场：降级、掉盘、重建失败怎么处理

5.1 掉盘先别急着换盘

前面提过一次，这里展开说，因为这是最高频的误判。一块盘从阵列里掉出去，原因至少有四类：盘本身介质故障、盘固件 bug 导致超时、链路问题（线缆、背板、接口氧化）、控制器或驱动问题。这四类里只有第一类需要换盘。判断方法很朴素：看 SMART 属性里重映射扇区和待定扇区有没有增长，看内核日志里是"介质错误"还是"超时/复位/CRC 错误"。介质错误的盘必须换，链路错误的盘换上去大概率还会再掉。

还有一个隐蔽的情况：整组盘同时掉。这基本可以排除介质故障，往供电、背板、阵列卡、驱动方向查。我见过因为机箱电源老化导致瞬态掉压，几块盘同时被复位，阵列直接崩掉。这种时候千万别急着逐块盘重建，先把硬件问题解决，否则重建一百次也会再崩。

5.2 重建失败的常见原因链

重建失败最典型的场景是 RAID 5 重建过程中遇到不可恢复读错误。表现形式是重建进度卡住，日志里出现读取失败，然后阵列要么把另一块盘也标记为故障（整个阵列失效），要么重建中断。这种情况下如果数据重要，不要再对阵列做任何写操作，先做全盘镜像再说，找专业数据恢复也比自己反复尝试强。

第二个常见原因是用了 SMR 盘。叠瓦式磁记录盘在持续写入时性能会断崖式下跌，重建过程中写入速度跟不上，阵列卡判定超时，直接把新盘踢掉，重建反复失败。这类盘价格便宜、容量大，很容易被误买来做 NAS，唯一的辨别方式是查厂商规格书里的记录技术。做 RAID 慎用 SMR，尤其是校验类阵列。

第三个原因是重建期间业务压力过大，阵列卡的处理能力被占满，重建任务被饿死或者超时。对策是限速加错峰，把重建优先级调低，让它慢慢跑，别追求速度。

5.3 性能不达预期的排查顺序

按这个顺序查，能覆盖八成问题。先看条带对齐，文件系统块和 RAID 条带没对齐是最常见的性能杀手，表现为小 IO 延迟明显高于预期。再看写缓存策略，Write Through 和 Write Back 的写性能差好几倍，如果最近改过配置或者电池失效自动降级到 Write Through，性能会突然掉下来。第三看是否有后台任务在跑，一致性校验、重建、快照清理都会抢 IO。第四看单盘是否已经有坏道，坏道会触发重试，一次重试几十毫秒到几秒，足以把整体延迟拉爆。最后才去看阵列卡固件、驱动版本、队列深度这些更底层的东西。

固态盘做 RAID 还要额外看两个点：TRIM 是否透传，以及阵列卡是否支持直通模式。很多阵列卡会把固态盘当成机械盘处理，队列深度受限，性能跑不满；有条件的话用直通卡加软件 RAID，反而更容易发挥固态盘的性能。

5.4 常见问题速查表

5.5 几条用血换来的经验

第一条，新盘上手先做全盘写测试。买回来的盘，尤其是批次相同的盘，先跑一遍全盘写入加读取校验，把早期失效的盘筛掉。同批次盘同时采购、同时上机，故障时间也会趋同，这是 RAID 最怕的"同批次雪崩"。有条件的话分批采购，或者混用不同批次。

第二条，RAID 5 的盘数上限比容量上限更重要。我给自己定的线是：单盘超过 4TB 不用 RAID 5，成员盘超过 6 块不用 RAID 5，两个条件满足任意一个就换 RAID 6 或 RAID 10。这条线不是拍脑袋，是重建时间、读错误概率、二次故障窗口三个因素叠加出来的。

第三条，冗余和备份要分开设计。阵列负责"盘坏了业务不停"，备份负责"数据错了还能回去"。这两件事的介质、位置、周期都要独立，别把备份放在同一个阵列里，也别用快照代替备份——快照和源数据在同一个存储上，存储挂了就一起没了。

第四条，改配置之前先备份元数据。硬件阵列导出配置，软件阵列保存mdadm --detail和mdadm --examine的输出，文件系统的 UUID 和挂载参数也记下来。这些东西平时没用，出事的时候能省下几十个小时。

第五条，定期做恢复演练。不是验证备份文件存在就算完，要真的从备份里恢复一份数据到测试环境，跑一遍完整性校验。我见过备份任务天天成功、真要用的时候发现备份的是空目录的情况。RAID 阵列也一样，定期拔一块盘模拟降级、观察告警是否触发、重建流程是否顺畅，这套动作做熟了，真出事的时候才不会手忙脚乱。

最后分享一个我一直在用的小习惯：给每个阵列建一个纯文本的"档案卡"，写清楚建阵列的日期、成员盘的型号序列号槽位、条带大小、文件系统参数、热备盘分配、巡检周期、上次校验时间。放在监控系统之外的地方，比如运维文档或者打印机旁边贴一张。这东西看着土，但在凌晨三点排查故障的时候，它比任何花哨的监控面板都管用。