RAID重建时第二块盘为何容易故障？揭开级联故障的底层真相

1. 凌晨两点的告警风暴：点下重建后，第二块盘跟着崩了

做服务器运维这些年，我最怕听到的声音不是业务告警，而是机房里那种若有若无的硬盘异响。更怕的，是凌晨两点手机上连续弹出的告警：先是RAID阵列降级，接着某块盘被标记离线，我打开管理界面确认故障盘，点了rebuild，刚准备回床。结果连一杯水都还没倒完，又一条告警砸下来——第二块盘SMART异常，阵列直接进入失效状态。

这种事，老运维十有八九都遇到过。不管是戴尔R740、浪潮NF5280M5还是惠普DL360 Gen9，不管是RAID卡是SAS9211-8i、5350-8i还是PERC H700，只要阵列里跑的是三四块同批次的老盘，一旦开始重建，第二块盘的故障概率就会明显上升。这不是哪个硬盘品牌特别矬，也不是纯粹运气差，而是RAID重建这个动作本身，在逻辑层面和物理层面都藏着一套系统性的高风险机制。

这篇文章我想把这件事彻底讲透：重建期间第二块盘为什么容易死、底层压力怎么产生的、上机前能做什么检查、重建中该盯哪些指标、长期怎么减少级联故障。如果你正在维护一台跑着RAID5或RAID10的老服务器，或者正准备给阵列换盘，下面的内容大概率能帮你避开一次全套数据迁移的痛。

1.1 掉一块盘只是开始，真正致命的是接下来的连锁反应

先说最常见的故障剧本。RAID5阵列，四块4TB硬盘，某天一块盘出现大量坏道，控制器把它踢出阵列，阵列降级。此时管理员要做的事很明确：找一块替代盘，插上去，让控制器开始重建。重建的意思是，控制器把剩余三块盘上的数据逐扇区读出来，重新计算丢失盘的校验数据，写入新盘。这个过程通常要跑十几个小时甚至一两天。

问题就出在这十几个小时里。剩下的三块盘被迫承担了整个阵列的全部读取压力。硬件设备到了一定的使用寿命，最怕的不是固定的稳态负载，而是负载模式突变。一块已经在“亚健康”边缘晃悠的盘，平时跑业务顶多占用百分之二三十的IO，突然连续十几个小时接近满负荷读盘，重则当场掉线，轻则SMART属性疯狂增长。

以前我做一次RAID5重建，四块盘里有一块是服役接近五年的老企业盘，重建启动八小时后，管理界面显示它的“当前待映射扇区”从0跳到了16。虽然没掉线，但那次重建结束后我做的第一件事，就是把它换下来。因为我很清楚，这种增长一旦开始，下一次重建它就是首发故障盘。

1.2 这事不是玄学，而是存储圈的真实高频事故

硬盘厂商的故障统计里，有一个名词叫“重建期间组内次生故障”。在云存储和大型IDC的运维报告里，这类事件被归为“级联故障”。老运维不会去赌概率，因为赌输的代价是整阵列数据不可读。RAID5降级后，任何一块盘再出问题，整个逻辑盘直接报废，后续能做的只有数据恢复公司的高额账单。

这也是为什么很多资深运维会把RAID5称为“最佳数据销毁方式”。尤其是大面积机械盘阵列，容量越大、盘数越多，重建窗口越长，级联故障风险越高。RAID6和RAID10可以扛住第二块盘故障，但这只意味着你不会立刻丢数据，并不意味着重建压力不存在。稍微较真一点说，第二块盘是否真“死”，有时候是逻辑判定——它还能转，但控制器认为它无法可靠响应，就把它踢出阵列。所以在实际运维中，你看到的“第二块盘掉了”，很多是控制器在高压环境下对盘的健康状态做出了“没信心”的判断。

2. 重建的本质是“魔鬼训练”：让所有剩余盘暴露在高压读负载下

要理解重建为什么危险，得先搞清楚重建过程中硬盘到底在干什么。很多人以为重建就是把数据从旧盘复制到新盘，实际上没这么简单，尤其是RAID5和RAID6这类奇偶校验阵列。

2.1 重建时硬盘到底在干什么：全量读、校验计算和高强度寻道

拿RAID5举例。四块盘，每块盘上的数据被切分成条带，写入时每N-1份数据块会生成一份校验块，轮流分布在各个盘上。现在丢失了一块盘，剩余三块盘上的数据并不完整，控制器要把每一条带的数据块都读出来，再进行XOR运算，把缺失块的内容补算出来，写入新盘。

这意味着，重建期间三块老盘上的每一个扇区都要被完整读一遍。听起来只是“读”，但问题在于读取范围是整个盘面。机械硬盘的磁头要从盘片最外圈一路扫描到最内圈，从一个磁道跳到另一个磁道，寻道动作极其频繁。连续读取和全盘扫描式读取，对机械盘来说负载差别很大，后者带来的是持续的寻道延迟、伺服系统压力和控制板发热。

假如盘上某些区域已经出现了坏道，控制器读不过去，就会反复重试。RAID卡对单扇区的读取超时通常设定在7到15秒左右，超过这个时间就会把这个扇区标记为不可恢复错误。重试期间，整个阵列的等待队列被卡住，重建速度骤降。更麻烦的是，重试次数多了，控制器会认为盘“不响应”，直接把它从阵列中踢出去。所以你看到的“第二块盘死了”，很多时候不是盘彻底物理报废，而是它没能在规定时间内完成读取，被控制器主动除名。

2.2 隐藏的坏道和重试风暴：平时不显眼，重建时集体爆发

我经常打一个比方：平时跑业务，硬盘就像在操场上被安排跑接力赛，每棒距离固定，频率固定，有些赛道就算有点坑坑洼洼也能凑合跑。重建则像是让操场上的选手连续跑马拉松，而且是全场地地毯式跑。原本一块盘上有一千个隐藏坏扇区，平时跑业务根本不会碰到它们，重建时上千个隐藏问题全被翻出来，重试风暴一旦形成，盘就要承受数倍于平时的延迟和读取压力。

更关键的是，很多隐藏坏扇区并不是盘片物理损坏，而是弱磁信号。这种扇区在常温、低负载环境下能读出数据，但在高温、持续高负载和相邻磁道干扰增加的情况下，错误率会上升。重建过程的持续负载会顺带推高盘体温度，温度一上来，弱扇区变成真坏道的概率大幅增加。这就是为什么有些盘你单独测SMART看起来一切正常，一进重建就开始冒大量坏道。

2.3 温度、震动、供电波动：容易被忽略的物理环境杀机

重建还有一个容易被忽略的东西：物理环境。全盘读取带来的功耗提升会让硬盘供电电流明显增加，劣质电源或者老化背板供电电路会出现电压波动，严重情况下直接导致磁头复位。服务器机柜里的风扇如果正好在低转速档，盘体温度可能会在重建中段飙升到50度以上，而机械盘长期在超过45度的环境里工作，磁头和碟片之间的气浮高度都会受影响，读取可靠性下降。

震动也是一个大变量。重建时的持续寻道动作本身就是震动源，多块盘一起寻道会放大共振。如果机箱固定不牢靠，或者硬盘笼里有螺丝松动，震动叠加后会出现瞬时读写错误。这种错误不会直接留下坏道，但会增加SMART里的“命令超时”和“重试次数”。

所以，重建不是简简单单在软件层面点一下“开始”就行。它是一场对剩余所有硬件——包括背板、电源、风扇、硬盘笼——的全方位压力测试。硬件环境里任何一个薄弱环节，都会在重建窗口里被放大为一次故障。

3. 更深层的原因：第一块盘和剩下的盘，很可能本来就是“命运共同体”

很多时候，第二块盘死掉并不是因为它运气差，而是因为它在出厂时间、磨损程度、使用环境上和第一块故障盘高度趋同。做运维时间长了，你会发现一个规律：阵列里掉盘往往不是孤立的，剩下的盘经常会接着出问题，就像一栋楼里如果有一户水管爆了，隔壁几户的水压也会异常，因为整栋楼的水管本来就是同一批施工的。

3.1 同一批次硬盘的“共病”问题

采购服务器或扩容硬盘时，绝大多数团队会一次性买齐同一型号、同一生产周期的货。这带来一个隐蔽风险：同一批次的硬盘，不仅固件版本相同，盘片、磁头、电机控制器甚至出厂质检的偏差曲线都高度接近。当它们在同一台服务器里以同样的负载模式运行了几年，磨损进度也差不多。第一块盘故障，说明这批盘的寿命已经进入后期阶段。剩下的盘不是“好好的”，只是还没轮到它暴露问题。

业内常说的“bad batch”现象就是这个意思。某批次的某型号硬盘，可能会有批次性的磁头偏振或者固件瑕疵。这种问题平时不容易发觉，只有经过高强度全盘读写时才会成规模爆发。所以你往往会看到，第一块盘出了问题，紧接着第二块也开始疯狂报错，这不是巧合，而是同一批次的“共病”到了集中发作期。

3.2 从URE概率看“重建失败”的必然性

再说一个更有数学味道的视角。硬盘的可靠性参数里有一个叫做“不可恢复读错误率”（Unrecoverable Read Error，简称URE）的指标。消费级机械盘通常标称1E14，也就是大约每读取12.5TB数据，就可能出现一个无法修复的扇区读取错误。企业级盘好一些，通常是1E15或更高，也就是每读取125TB以上才可能出现一个不可恢复错误。

假如你有一组四块4TB盘的RAID5，一块盘掉线后，重建需要读取三块剩余盘的全部数据，也就是大约12TB。如果这用的是消费级盘，URE概率就接近百分之百——意思是你很可能碰到一个读不出来的扇区。控制器碰到这种扇区时，如果数据分布导致它无法通过校验恢复（重建时的校验逻辑并不总能纠正单个扇区的读取故障），重建就会失败或卡住。

这个参数平时很少被人注意，但它在重建场景里几乎是决定性的。它解释了一个反直觉现象：阵列越大，重建越容易失败。因为读取量上去了，URE出现的概率也上去了。所以很多存储老手会告诉你，超过五个盘位宁可组RAID6也不要硬撑RAID5，因为RAID5在重建时，剩余盘的容量越大，读取数据量越大，失败风险就越高。

3.3 哪些盘在重建中最容易出局：故障盘画像

我根据这些年的运维经验和厂商文档，把重建中最容易出局的盘归纳成几个特征：

并不是说符合高风险的盘就一定会掉，只是这些特征叠加越多，级联故障概率越高。有一个道理特别直观：一块已经在SMART里带着“待映射扇区”的盘，就好比一块已经出现裂纹的玻璃板。平时放个杯子没问题，可一旦要在它上面持续施压十几个小时，裂纹扩大几乎是可以预期的事。

4. 按重建按钮之前的保命清单，这10分钟决定你后面是安心还是崩溃

很多运维一看到阵列降级就手忙脚乱，立刻把新盘插进去，马上点重建。这种动作我完全能理解，毕竟降级状态下容错能力为零，谁都希望尽快恢复冗余。但从风险控制的角度，我更建议在点下重建之前花十来分钟做个检查。这十分钟不会显著延长降级窗口，但能让你避免在重建中途发现更大的雷。

4.1 备份优先：RAID从来都不是备份

先说最难听但最重要的一句话：RAID不是备份。RAID提供的只是冗余和可用性，防止单块盘故障导致服务中断，但它防不住控制器固件崩溃、雷击、误删文件、勒索病毒，也防不住重建期间第二块盘故障导致的数据全毁。如果你手上这批数据真的重要，那么在阵列降级之后、重建之前的短暂窗口里，你需要评估一个事：是否有核心数据可以直接先备份出来。

我见过最痛心的一次教训，是某台服务器RAID5掉了第一块盘，管理员觉得重建能搞定，没有做任何额外备份。结果重建到百分之六十，第二块盘也掉了，整个逻辑盘消失，最后找数据恢复公司开盘，花了六位数，还只救回一部分。如果他当时先花一小时，把关键数据库目录同步到另一台机器上，后面根本不用这么被动。

当然，如果整阵列容量特别大，全量备份需要太长时间，就优先备份最重要的数据。哪怕只备份关键业务目录，也比什么都不做强得多。这叫“在风险和窗口之间做取舍”。

4.2 给剩余盘做体检：SMART关键属性、长自检和读扫描

重建前，如果服务器允许在线诊断，我对剩下的每块盘都会扫一眼SMART，重点看五个属性：

• 05 重映射扇区计数：已经发生物理坏道，被固件重映射的扇区数量。
• C5 当前待映射扇区：读取不稳定、被挂起等待判断的扇区数量。
• C6 离线不可修复扇区：已经无法读取且未能重映射的扇区数量。
• 187 无法修正错误计数：硬件纠错失败的次数。
• 197/198 当前待映射 / 离线扫描：结合C5/C6看当前与历史的待处理扇区。

在Linux下用smartctl可以直接查到，比如smartctl -a /dev/sda。如果手头是LSI/Broadcom的RAID卡，可以用storcli /c0/eall/sall show all配合查看物理盘状态。在Windows下，CrystalDiskInfo这类工具也可以快速看到这些属性。

判断标准很简单：任何一块盘的C5或C6非零，就要高度警惕。小数值（比如几个扇区）可以暂时观察，但如果C5持续增长，我会直接建议在重建前就把这块盘换掉。不要觉得“再多一块盘故障就完蛋了，所以不能动它”，C5增长中的盘本身就不是稳定因素，带着它进重建，风险更大。

如果时间充裕，我还会跑一次smartctl -t long /dev/sda做长自检。长自检会在后台读取整个盘面，把弱扇区提前暴露出来。这个操作在重建前做会占用一些IO，但如果阵列本身不是高负载状态，影响可控。跑了长自检能让你对剩余盘的健康度更有底。

4.3 确认热备盘/冷备盘状态，别让备盘变成下一块墓碑

接下来这一步很多人会漏：确认备盘是否真的可用。如果是已经常年插在服务器里的热备盘，它平时也承受着和主盘一样的工作环境，同样可能已经处于亚健康状态。不要默认热备盘就一定是健康的，重建前查看它的SMART信息，确认没有异常增长，再让它上岗。

如果是冷备盘，也就是放在仓库里的新盘，也要注意长时间存放导致的静电和湿度问题。拆封后装进服务器，最好先别直接插到故障位，可以先放到空槽位上通电识别，确认固件识别正常、无“SMART自检失败”提示，再做重建。有一次我因为着急，直接把冷备盘插进故障位，结果控制器报告“SMART command failed”，只好停机换盘。虽然阵列没二次故障，但白白浪费了窗口时间。

还要确认一件事：热备盘容量必须不小于阵列中最小容量盘。看似简单的规则，实际经常被忽略。小容量盘插上去，控制器可能拒绝把它作为重建目标盘。提前在RAID卡管理界面查看一下逻辑盘组和物理盘的容量映射，能避免到重建启动阶段才发现容量问题。

5. 重建中的实时监控与常见的“伪经验”

重建一旦启动，剩下的就是等待吗？不是。重建过程是最需要盯盘的时段，但盯什么、怎么盯，很多人其实没概念。只会看进度百分比，遇到问题也不知道怎么应对。

5.1 重建时要盯到哪些指标才算心里有底

进度百分比之外，真正重要的是两方面：单盘错误计数变化和重建速度的稳定性。

如果你是Linux环境下用LSI/Broadcom控制器，可以周期性运行storcli /c0/eall/sall show all查看每块物理盘的SMART属性，重点盯C5和187是否在增长。C5一旦从0变成几个，说明盘面在重建压力下开始产生待映射扇区。此时不能立刻下结论，需要看后续增长趋势。如果增长停住，可能只是几个弱扇区被修复；如果持续增长，就要做好第二块盘即将掉线的准备，提前安排备份和更换方案。

重建速度的稳定性也很重要。一个典型RAID5重建，四块4TB盘，在无业务负载时通常能以每小时800GB到1.2TB的速度推进，整体能在四到六小时完成。但如果看到重建速度忽快忽慢，甚至在某个百分比停留特别久，大概率是有磁盘在反复重试某个扇区。这种情况要用控制器日志确认是哪块盘在读困难。控制器日志在LSI控制器下可以看storcli /c0 show events或查看系统/var/log/messages里的RAID事件。

5.2 重建速度到底要不要调低？“慢=安全”是误区吗？

有些控制器的重建优先级是可以调节的，比如低、中、高。不少运维认为，重建优先级调到“低”，让重建慢慢跑，对剩余盘的损害就小。这个想法有合理性，但也不完全对。

重建优先级调低，本质是限制重建IO占用的带宽，降低业务影响和减缓磁盘压力。好处明显，坏处也很直接：重建窗口被拉长，而降级状态持续越久，整体风险就越大。本来十二小时能完成的动作，拖到三十多小时，意味着有更大时间窗口被第二块盘故障击中。

更妙的是，缓慢重建并不意味着读取量减少。该读的扇区还是得读完，只是把压力摊开到更长时间里。对盘本身来说，单次持续负载是下降了，但总工作时间长了，同样会积累损伤。所以我个人建议，如果业务可以接受短时间的IO占用，把重建优先级设在中高位，尽快缩短降级窗口。如果生产业务完全不能接受性能波动，那就把重建放在业务低谷期执行，但一定不要在启动后反复调优优先级、频繁暂停恢复，这对重建过程没有任何好处，反而增加控制器状态机异常的概率。

5.3 重建期间能不能继续读写业务：风险量与应对策略

这是一个很现实的问题。我见过很多小团队，阵列降级了，重建在跑，但业务照常读写，管理员觉得“反正RAID还在工作”。事实是，降级状态下的RAID5，读性能其实下降了，因为每次读取都要从其他盘计算校验数据；写性能更是明显恶化。此时业务负载产生的随机读写，会跟重建任务抢IO，进一步延长重建窗口，也会干扰对故障盘状态的判断。

如果可能，尽量把重建安排在业务低峰期。但运维工作不可能总那么理想，业务24小时在线怎么办？我的做法是：重建期间，尽量避免在阵列上跑大文件复制、数据库全量导出这类高负载任务，同时把日志级别适当调高，重点记录磁盘错误事件。另外一个容易被忽视的点：重建期间不要轻易重启服务器。一旦重启，重建进程会中断，有些控制器会从头开始重建，这中间浪费的时间，足够让剩下几块盘多承受一次折磨。

6. 重建结束不是终点：长期策略把级联故障压缩到最低

重建进度到100%，很多人的第一反应是长舒一口气，觉得事情过去了。但我一般会在重建完成后继续盯三天。为什么？因为我吃过亏。

有一块盘在重建期间C5从0涨到8，重建结束后看起来稳定了。我本以为没事，结果不到一周，这块盘的C5涨到了几百，最后还是在备份窗口里被我换掉的。如果当时掉以轻心，下一次它掉线很可能发生在某个深夜，而那时候已经没有热备盘可用。重建完成只能说明当前冗余恢复了，不能说明所有盘都健康了。

6.1 让盘“错峰衰老”：采购与替换策略

长期降低级联故障概率，最有效的办法之一，是别让同一批盘同时服役。采购硬盘时，我会有意错开购买时间。比如组一个四盘RAID10，可以分两个批次买，或者用不同生产周期的同型号盘。这个操作在批量采购时代可能稍微麻烦，但确实能降低“同一批次同时老化”的概率。

另一层策略是替换节奏。如果阵列里有一块盘服役五年了，而其他三块盘都是三年的，那我不会等五年盘掉了再换，而是先找机会把五年盘主动替换下来。主动替换的成本远低于故障替换。故障替换是发生在凌晨两点、没有备件、业务中断的被动局面；主动替换是有计划的、有备件的、有验证时间的从容操作。这两者的运维体验完全不同。

6.2 RAID卡巡检、一致性校验和定期SMART扫描的落地节奏

重建之外，巡检才是真正让你的阵列少出问题的关键。所谓“问题提前露头，比在重建时爆发强一百倍”，指的是你要养成日常巡检的习惯。我建议的节奏是：

• 每周：查看RAID控制器日志，确认没有新增磁盘错误事件。
• 每月：对阵列执行一致性检查（consistency check），也就是常说的scrub。这个操作会读取阵列中所有条带，校验数据与校验块是否一致。它能提前发现静默数据损坏，并把潜在坏道暴露出来。
• 每季度：查看每块物理盘的SMART详细属性，记录05、C5、C6、187等关键属性的趋势。如果发现某个属性连续两个季度非零且缓慢增长，就纳入替换观察列表。

控制器的一致性检查也是消耗资源的操作，所以我会把它安排在月末的夜间执行，并且设置较低优先级。LSI/Broadcom控制器下可以用storcli /c0 set consistencycheck start之类的命令发起，也可以在WebBIOS里配置周期性计划。很多服务器厂商的管理工具（如戴尔的iDRAC、惠普的iLO）也提供了RAID控制器的健康状态页面，能直接看到巡检建议。

6.3 重建完成后的72小时观察期，以及我踩过一次的教训

最后分享一个我自己的实操经验。重建完成后，我通常不会立刻把这事翻篇，而是保持至少72小时的“观察期”。观察期内，我会每天检查一次控制器事件日志和SMART关键属性，同时关注阵列读写的IO错误是否增加。如果某一盘的C5或187在观察期内上涨，哪怕只是一点点，我都会在业务允许时尽快安排替换。

我能明确告诉你的教训是：有一回，重建完成后第二天，某个盘SMART看起来正常，控制器事件日志也没有异常，但存储性能明显下滑。我没当回事，结果第三天发现C5涨了二十多个。最终在第四天夜里，那块盘掉了，阵列再次降级。当时因为没有多余的热备盘，我只能跑了一趟机房去更换。那次经历让我意识到，重建后短时间内的“隐性衰退期”是真实存在的。别等第二次故障再来复盘，任何异常指标都值得提前处理。

存储运维这行的本质，就是拿着有限预算去换数据生存概率。RAID重建期间第二块盘为什么容易死，说穿了无非是设备衰老、压力骤增、批次共病三个因素叠加。理解了这些，你就不会再把重建当作一个“点完按钮就完事”的操作，而是会主动做检查、盯指标、留预案。少一次夜里被警吓醒的经历，比什么技巧都值钱。