恢复顺序为什么重要
异常掉电会留下三类隐患：写缓存中未下刷的数据、文件系统元数据处于中间态、以及阵列在上电后需要重做的一致性校验。恢复时如果先起主机并立刻拉业务，等于在存储仍在校验时施加满负载压力，轻则性能长时间异常，重则在校验期间遭遇介质错误。规范做法是按依赖顺序上电，并给存储充足的自检与校验时间。
基本信息
| 上电前确认 | 市电与 UPS 已稳定、机柜供电无单路缺失、环境温度与告警恢复正常 |
|---|---|
| 上电顺序 | 存储与扩展柜先行，确认阵列自检与卷状态正常后再启动主机 |
| 重点观察 | 缓存是否有未下刷数据、阵列是否进入重建或一致性校验、卷是否可读写 |
| 校验代价 | 全量一致性校验会占用大量带宽与介质时间，期间性能低于正常水平 |
| 文件系统 | 主机侧先只读检查，确认无异常再决定是否修复 |
| 变更约束 | 恢复期间不要并行执行固件升级、扩容等变更，先回到稳态 |
典型使用场景
- 机房市电中断后批量恢复，需要确定存储、主机、业务的启动次序时
- 单台设备被误断电，评估缓存数据与文件系统是否需要修复时
- 掉电后阵列自动进入校验或重建，判断业务能否立即拉起来时
- 主机重启后文件系统报错，决定是否执行修复以及如何留证据时
- 恢复完成后向业务方交付，需要说明当前性能处于校验期的正常区间时
恢复期的检查动作
恢复期的检查动作
# 主机侧：确认卷是否已正常识别与成员状态
lsblk -S
cat /proc/mdstat
# 文件系统先做只读检查，不修改任何元数据
fsck -n /dev/mapper/mpatha
xfs_repair -n /dev/mapper/mpatha
# 只读挂载验证数据可读，确认无误后再以读写方式挂载
mount -o ro /dev/mapper/mpatha /mnt/check
# 全程盯内核日志与阵列事件，留意介质错误与重置
journalctl -k -f | grep -Ei 'i/o error|reset|fault'恢复阶段与完成判据
| 阶段 | 关键动作 | 完成判据 |
|---|---|---|
| 供电确认 | 核对市电、UPS、机柜供电状态 | 供电稳定且环境告警消除 |
| 存储上电 | 按厂商顺序上电并观察自检 | 阵列状态正常、卷可识别 |
| 一致性校验 | 等待校验或重建完成 | 校验进度归零、无新错误计数 |
| 主机拉起 | 先只读检查再读写挂载 | 文件系统挂载正常、数据抽检通过 |
| 业务恢复 | 分批恢复业务并观察基线 | 延迟与吞吐回到历史基线区间 |
掉电后如果写缓存保护部件本身也失效，缓存中未下刷的数据可能永久丢失。此时不要急于让业务大量写入，先把当前状态与丢失窗口评估清楚，再决定是否从备份恢复。
一致性校验与重建期间性能下降属于预期行为，交付时要主动说明窗口与量级，避免业务方误判为存储故障而触发二次变更。