RAID 重建的那几个小时：URE、双盘失效与阵列选型

阵列坏一块盘，插上新盘开始重建。这几个小时，是整套存储一年里最脆弱的时候。

大多数人对重建的理解是「系统在后台慢慢把数据补回去」。实际上重建做的事情要激烈得多：它要把其余每一块成员盘从头到尾完整读一遍。平时业务只读热数据，冷数据区可能几年没被碰过；重建期间，那些区域一定会被读到。

一、重建到一半，第二块盘掉了

现象：RAID 5 坏一块盘，换新盘开始重建，重建到百分之六七十的时候另一块成员盘报错，整组数据没了。

机理：这叫不可恢复读错误（Unrecoverable Read Error，URE）。机械硬盘的规格书里都会写一个 URE 指标，常见的是每读取 10^14 或 10^15 位出现一次不可恢复错误。平时不会碰到，因为平时不会连续读那么多。重建会。

盘容量越大，一次完整读取的数据量越大；盘龄越长、批次越接近，同时劣化的可能越高。这两个因素叠加，就是大容量盘做 RAID 5 风险偏高的原因。

怎么办：

一个现实：过保机器里的盘，往往是同一批次、同一天上架的。一块到寿命，其他几块大概率也快了。整组同时进入高风险期这件事，在做规划时必须算进去。

现象：阵列所有成员盘状态正常，没有任何告警，但吞吐和响应时间明显变差。

这类问题在过保设备上最难查，因为没有任何东西「坏」了。可能的原因有三类：

可能一：有盘进入了内部重试或介质扫描。盘在内部做重映射或扫描时，单次响应会拉长到几百毫秒，但还没到控制器的报错阈值。看单盘延迟分布能发现——如果某一块盘的 P99 延迟明显高于同组其他盘，就是它。

可能二：控制器的缓存策略被降级了。最常见的原因是 RAID 缓存电池失效，控制器自动从回写（write-back）退到直写（write-through），写性能会掉一个数量级。这一类单独展开在《机器没坏，只是变慢了：RAID 缓存电池》。

可能三：后台任务在跑。一致性校验（consistency check）、巡检（patrol read）、重建，都会占用大量带宽。很多平台默认每周或每月自动跑一次一致性校验，如果没人调整过时间窗口，它可能正好落在业务高峰。

排查顺序：先看控制器状态和后台任务列表（这一步最快），再看单盘延迟分布，最后才怀疑硬件。顺序反过来，会浪费大量时间。

更换存储控制器是存储维护里风险最高的动作之一，没有之一。

现象：换上新控制器后，原有阵列配置丢失，或者识别异常、盘序错乱。

三个常见原因：

规程（不是建议，是规程）：

这一步没有捷径。现场即兴发挥的代价，是整组数据。

现象：一个控制器早就故障了，业务由剩下那个扛着，一直没换。

这是国内机房里相当普遍的一种状态，尤其是过保之后。

风险有三层：

为什么不换：多数时候不是不想换，是过保之后原厂报价太高，或者直接答复不再供应。

实际情况：这类控制器在渠道库存和下架资产里通常还有货。关键不是能不能买到，是买到的固件版本能不能和现有配置对上——见上一节。

带病运行的时间越长，最后那次故障的代价越大。这是一条在账面上看不见、但在停机那天会一次性结清的负债。

重建风险的解法里有一半是「提前备好件」。

七小服的料号库收录 11,894 个料号，4,786 个为库房常备实物，国内六城设区域备件库，海外 35+ 国家和地区有本地库房。硬盘、控制器这类重建期间用得上的件，可以按设备清单提前核一次库存位置——备件料号速查可以直接查，或者把清单发过来人工核。