给生产服务器 RAID5 在线扩容：68 小时还没跑完的 Background Initialization

生产服务器（跑 SAP B1 数据库）存储告急，计划给现有 RAID5 阵列在线加一块盘扩容：2.4TB 10K SAS 盘插进空余的 bay，通过 LSI 阵列卡把它并入现有虚拟磁盘。

操作本身教科书级简单，这篇要记录的是教科书没写的部分。

操作要点

1. 新盘插入后在系统里以 JBOD 形态出现，Disk Management 里显示一块未初始化的 Disk——忍住不要在 Windows 里初始化它。要走阵列卡（LSI Storage Authority）把它加进 RAID5 组，让它成为现有虚拟磁盘的一部分，而不是一块独立的裸盘；
2. 扩容动作安排在周五下班后（17:30）启动——这个决定后来被证明无比正确，但还是低估了后面的事。

教科书没写的部分：Background Initialization

那个”一个周末搞定”的计划实际的样子

盘加进阵列后，控制器开始 background initialization / 重构——把数据和校验块重新分布到包含新盘的布局上。这个过程：

• 以天为单位。周五傍晚启动，到周一早上（68 小时）还没跑完；
• 显著拖累阵列性能。周一上班后用户开始报障：SAP B1 卡顿。数据库的随机 IO 和后台重构在抢同一组磁盘；
• 好消息是 LSI 允许暂停/恢复 background initialization——我们最终的操作模式变成：工作时间暂停，下班后恢复，扩容硬生生变成了一场持续多日的拉锯战。

事后复盘：对大容量机械盘阵列，这个时长其实可以预估——2.4TB 盘、RAID5 重分布、还要给生产 IO 让路，两三天起步是正常量级，当初的心理预期却是「一个周末搞定」。

如果重来一次，会先问这几个问题

1. 重构要多久？ 按盘容量和阵列卡的 rebuild rate 先算一遍，直接决定这是「周末任务」还是「跨周任务」；
2. 性能影响可控吗？ 确认阵列卡支持暂停 BGI / 调整 rebuild 优先级，并提前想好工作时间的应对策略，而不是等用户报卡再现场决定；
3. 在线扩容真的是最优解吗？ 备选方案（新建一组阵列迁数据、或者干脆换更大的盘做一次性重建）在停机窗口允许的情况下，总时长可能反而更短、风险更低；
4. 回退方案是什么？ RAID 扩容中途出问题的回退基本只有「从备份恢复」——所以动手前先确认备份是可恢复的。

教训

存储变更的成本要按「重构时间 × 性能影响」算，而不是按「插盘 + 点几下鼠标」算。

用户感知到的不是你的操作多丝滑，而是那三天里每一次变慢的查询。