3. 存储层故障：磁盘坏道导致快照失败、存储控制器切换引发IO超时、LUN映射丢失导致数据不可见
存储层出问题，往往是最让人头疼的。为什么？因为症状千奇百怪，根因却藏得很深。我见过太多运维同事，一看到IO超时就怀疑网络，一看到快照失败就重做快照，结果问题反复出现。
说白了，存储层是灾备系统的地基。地基不稳，上面再好的备份软件、再完善的灾备策略，都是白搭。今天咱们就聊聊三个最常见的存储层故障：磁盘坏道、控制器切换、LUN映射丢失。
核心观点：存储层故障的排查，一定要遵循「从物理到逻辑」的顺序。先看硬件健康，再看链路状态，最后才查配置。跳过任何一步，都可能让你绕大圈子。
3.1 磁盘坏道：快照失败的隐形杀手
快照失败，很多人第一反应是快照空间不够。但我要告诉你，磁盘坏道才是更隐蔽的元凶。快照本质上是在某个时间点冻结数据块的状态，如果源卷上有坏道，快照引擎在读取那个块时就会卡住，最终超时失败。
我记得有一次，某客户的核心数据库快照连续三天失败。备份团队查了快照池、查了网络、查了主机，都没问题。最后我让他们去存储管理界面看硬盘状态——果然，一块SAS盘有重定位扇区，已经超过阈值了。
我的排查习惯：遇到快照失败，先做三件事：
- 登录存储管理界面，查看所有磁盘的健康状态
- 检查系统日志，搜索"Media Error"或"Uncorrectable"关键字
- 用smartctl工具扫描疑似故障盘（如果主机能直连）
磁盘坏道的修复，分两种情况：
| 坏道类型 | 表现 | 修复方案 |
|---|---|---|
| 逻辑坏道 | 读写超时，但磁盘SMART状态正常 | 用fsck或chkdsk修复文件系统；或使用存储自带的坏道重映射功能 |
| 物理坏道 | SMART报Reallocated_Sector_Ct增长，有"Click"异响 | 立即更换磁盘；如果RAID有冗余，热备盘顶上后重建 |
注意：千万不要在坏道盘上反复做快照重试。我曾经见过一个案例，运维人员连续重试快照7次，结果坏道区域扩大，最终导致整个RAID组降级。正确的做法是：先隔离故障盘，再处理快照。
3.2 存储控制器切换：IO超时的幕后推手
存储控制器切换，本意是高可用设计。但现实是，切换过程往往伴随着IO抖动，甚至超时。你想想看，控制器A突然把缓存里的数据刷给控制器B，路径要重新选路，LUN要重新归属——这个过程如果超过主机的IO超时阈值，应用就报错了。
我遇到过最典型的一个场景：某双活存储，凌晨两点自动触发控制器固件升级。升级过程中控制器切换了三次，每次切换导致约15秒的IO中断。而主机端的multipath配置的超时时间是10秒。结果就是——数据库会话全部断开，灾备复制链路中断。
排查控制器切换问题，我一般看这几个地方：
- 存储事件日志：搜索"Controller Switchover"或"Failover"事件，记录切换时间和次数
- 主机端multipath状态：用
multipath -ll查看路径状态，看是否有路径处于"failed"或"degraded" - IO延迟统计：用
iostat -x 1观察await和svctm，切换期间这两个值会飙升
避坑指南：我曾经在配置灾备复制链路时，忽略了主机端的IO超时参数。结果存储控制器一切换，复制链路就断。后来我把/sys/block/sdX/device/timeout从默认的30秒改到60秒，同时调整了multipath的polling_interval，问题才解决。
修复控制器切换导致的IO超时，核心思路是「对齐超时阈值」：
| 层级 | 关键参数 | 建议值 |
|---|---|---|
| 存储端 | 控制器切换超时 | 30-60秒（视缓存数据量而定） |
| 主机端SCSI | device timeout | 60秒（大于存储切换时间） |
| 应用层 | 数据库IO超时 | 90秒（大于主机SCSI超时） |
说白了，就是让每一层的超时时间都比上一层长，留出足够的缓冲。这个原则，我在多个灾备项目中验证过，非常管用。
3.3 LUN映射丢失：数据突然「消失」了
LUN映射丢失，是存储层最吓人的故障之一。主机上明明之前还能看到磁盘，突然就没了。或者新映射的LUN，主机死活认不到。
为什么会这样？原因通常有三个：
- WWN或IQN变更：主机HBA卡更换、虚拟机迁移后WWN变了，但存储端的映射还是旧的
- 存储端配置丢失：控制器重启、配置回滚导致LUN映射表被清空
- Zoning或SAN交换机配置错误：光纤交换机上的Zone配置被修改，主机和存储端口不在同一个Zone里
我记得有一次，某客户做存储迁移，新存储映射了LUN给主机，但主机就是认不到。他们查了三天，最后发现是新存储的端口WWN写错了——少了一位。嗯，这种低级错误，其实挺常见的。
排查LUN映射丢失，我有一套固定的「三板斧」：
- 主机端确认：用
lsscsi或fdisk -l看有没有新磁盘；用cat /proc/scsi/scsi看SCSI设备列表 - 存储端确认：登录存储管理界面，查看LUN映射表，确认主机WWN/IQN是否在允许列表中
- SAN交换机确认：用
show zoneshow或cfgshow查看Zone配置，确认主机和存储端口在同一个Zone里
一个小技巧：如果主机端认不到LUN，先别急着重启。试试用echo "- - -" > /sys/class/scsi_host/hostX/scan重新扫描SCSI总线。很多时候，重新扫描就能认到。我习惯在排查脚本里把这个命令放在第一步。
修复LUN映射丢失，步骤其实不复杂：
| 场景 | 修复步骤 |
|---|---|
| WWN/IQN不匹配 | 在存储端更新LUN映射，添加正确的WWN/IQN |
| 存储端配置丢失 | 重新创建LUN映射，注意保持LUN ID不变（否则文件系统可能挂不上） |
| Zone配置错误 | 在SAN交换机上修正Zone配置，保存并激活配置 |
特别提醒：如果LUN ID变了，即使映射恢复，主机也可能无法挂载文件系统。因为/etc/fstab里用的是/dev/sdX或UUID。我建议生产环境的LUN映射，一定要记录LUN ID和主机设备名的对应关系。别问我为什么强调这个——我曾经因为没记录，恢复映射后折腾了三个小时才把文件系统挂回来。
3.4 三个故障的关联与综合排查
实际运维中，这三个故障往往不是孤立出现的。磁盘坏道可能导致控制器切换（因为坏道引发IO错误，触发控制器自动切换），控制器切换又可能导致LUN映射暂时不可见。你想想看，如果只盯着一个点查，很容易被表象误导。
我个人的综合排查顺序是这样的：
- 第一步：看存储硬件告警。磁盘、电源、风扇、控制器——任何硬件异常都优先处理
- 第二步：看存储事件日志。按时间线梳理所有事件，找关联性
- 第三步：看主机端日志。
/var/log/messages里搜"timeout"、"error"、"lost"关键字 - 第四步：看SAN交换机日志。确认Zoning和端口状态
这套顺序，我在十几个灾备项目中用过，基本能覆盖90%的存储层故障。剩下的10%，往往是硬件固件bug或配置文档错误——那种情况，就只能找原厂支持了。
总结一下：存储层故障排查，核心是「分层定位、逐层排除」。磁盘坏道看SMART，控制器切换看超时配置，LUN映射丢失看WWN和Zone。记住这三句话，遇到问题就不慌了。