客户的机器是台老 HP，P420i 阵列卡，四块 3TB 组 RAID5。上周三早上监控邮件弹出来：阵列降级，Slot 2 的盘 SMART 报错。

按流程走：确认备用盘在位，然后在线换盘。坏盘拔出来的时候我还看了一眼标签，西数 3TB，2015 年的盘，用了七年多了。我心想这盘也到岁数了，换掉也好。

新盘插进去，阵列开始自动重建。我看重建进度 3%，就放心去干别的了。结果下午三点多，客户电话打过来：机器怎么越来越慢？

上去一看，重建进度卡在 31%，而且 Slot 3 的盘开始报 read error，错误计数一路上涨。我当时心里咯噔一下：RAID5 只能坏一块盘，这要是再坏一块，整个阵列直接完蛋，数据全没。

赶紧查日志，发现 Slot 3 那块盘从上午就开始有 read error，只是没触发 SMART 阈值，没报警。重建期间阵列要全盘读一遍，正好把这块老盘给压垮了——它本来就有坏道，平时读写量小，扛得住，重建这种全盘扫描直接把隐藏的问题全翻出来了。

我第一反应是怪阵列卡：为什么重建不挑块好盘？后来想明白了，重建是拿剩下的盘逐块读，哪块盘都不好过，只是 Slot 3 最虚，先倒了。

当时的选择：停掉重建？不行，停了更危险，阵列还是降级状态。硬着头皮让它重建完？风险是 Slot 3 在中途彻底挂掉，阵列数据全毁。

最后我做了个保守决定：先不碰它，把重建跑完，同时让客户赶紧确认备份有效性——他们有个每周全量的备份脚本，但说实话，这种老机器，备份到底能不能恢复，我心里没底。客户一听可能丢数据，也紧张了，催着我们盯着进度。

重建跑了将近十个小时，凌晨一点多跑完，Slot 3 竟然撑住了。阵列恢复 Healthy，数据没丢。我长出一口气，然后把 Slot 3 那块也登记了，建议客户近期也换掉——这种盘，这次没炸是运气。

后来跟客户聊，他们说这套阵列跑了七年，从来没坏过盘，这次一坏就是连锁反应。我给的建议就三条：第一，老盘赶紧换，别等它坏；第二，RAID5 在盘龄大的时候其实很脆，能上 RAID6 或者干脆换新机器就换；第三，备份别只想着"每周全量"，恢复演练才是真的。

写这个就是想记一笔：换盘重建不是插进去就完事，重建本身就是一次压力测试，会把其他老盘的问题全逼出来。换盘之前，最好先看看剩下几块盘的 SMART 状态，心里有个数。