2026-10-07 · 约 6 分钟
VPLEX与SVC后的卷恢复，核心不是先救物理盘，而是先定位故障层：后端LUN、网关节点、路径、虚拟卷映射或主机多路径。确认后端LUN完好后，再按镜像重新同步、映射重建、主机路径清理和一致性校验的顺序处理；split-brain不能盲目resync。
主机看到的hdisk或sd设备，是VPLEX导出的virtual volume或SVC导出的vdisk，不是后端LUN本身。一次卷不可用可能是后端LUN掉线、网关节点故障、网关到后端路径全断、虚拟卷映射丢失，或主机多路径状态异常。恢复前必须分层确认。
在网关层做映射重建之前，必须确认后端LUN本身完好，否则重建出的虚拟卷会指向坏数据。多数卷恢复事故的根因，是跳过分层判断，直接在主机侧折腾多路径。先定位层，再动手，是后续所有动作的前提。
VPLEX mirrored virtual volume和SVC vDisk mirror维护两个副本。一个副本失效时，正常路径是让健康副本作为源、失效副本作为目标做resync，对应VPLEX的rebuild或SVC的sync。这里有两个关键判断：同步方向，以及哪个副本是权威。
如果两个副本都曾被独立写入，就出现split-brain。此时简单resync会用一边覆盖另一边，可能造成不可逆的数据丢失。更稳妥的做法是先把两个副本都只读挂起做取证，确认哪边是权威后再决定同步方向。不要在未确认权威副本前点resync。
镜像恢复解决的是副本间块级一致，不是上层逻辑正确。恢复后仍需进入一致性校验。把重新同步当成数据恢复完成，是常见误判。
VPLEX的virtual volume到storage view再到host initiator链路，SVC的vdisk到host mapping链路，都是纯元数据。网关节点重建、配置库恢复后，这些映射可能丢失。恢复映射时，host的WWPN和LUN ID必须与故障前一致，否则主机侧设备名会变，Linux下sd字母漂移，依赖固定设备名的应用会挂。
VPLEX配置存在cluster的configuration database，SVC配置存在cluster配置中，两者都有备份或导出机制。没有配置库备份时，节点全损后映射关系只能从主机侧反推，难度和风险都高。因此网关配置库应纳入和数据库同等级的备份对象，并定期演练映射重建流程。
映射重建不是凭空生成新卷，而是让主机重新看到正确虚拟卷。LUN ID、WWPN、storage view或host mapping的对应关系必须逐项核对，再交给主机侧重新发现。
网关恢复后，主机multipath层可能仍持有旧的path记录，形成幽灵路径。Linux下用multipath -ll查看路径状态，必要时用multipath -f清掉失效map再重新发现。不同厂商多路径策略不同，ALUA、VPLEX的active/active、SVC的active/active对路径状态判断不同，恢复后要确认策略匹配。重启主机代价高，手工清理通常更可控。
卷能挂载、能读写，不等于数据正确。文件系统层可离线fsck，数据库层使用各自的校验工具。对关键库，恢复后应做业务级抽样校验，例如随机读若干记录比对。网关层的resync只保证块级一致，不保证上层逻辑一致。卷在线只是恢复流程的一个中间状态，不是终点。
救得了的情况通常有共同前提：后端LUN本身完好，网关冗余或映射元数据仍有恢复路径。包括后端LUN掉线、网关节点故障、网关到后端路径全断、虚拟卷映射丢失、主机多路径状态异常、镜像副本一坏一好，以及配置库有备份可重建映射。这些场景可按分层定位、镜像resync、映射重建、主机路径清理和一致性校验的顺序处理。
救不了或不能按本文方法处理的情况也要说清：后端LUN本身损坏、盘片级故障，需要专业数据恢复服务，不在网关映射重建范围；两个副本都曾被独立写入形成split-brain，且在未确认权威副本前已经盲目resync，覆盖可能不可逆；网关节点全损且配置库没有备份，映射关系无法可靠重建；网关resync只保证块级一致，上层逻辑损坏仍要靠文件系统或数据库工具处理。诚实判断边界，比承诺都能救更重要。
先分层定位。用vplexcli或Unisphere查看virtual volume health和每个extent的后端LUN状态，确认后端LUN是否完好；同时检查网关节点、路径和主机多路径。不要先在主机侧反复折腾多路径。
用lsvdisk、lsmdisk、lsvdiskaccess查看vdisk与mdisk的对应、镜像状态和主机访问关系。先确认mdisk后端LUN完好，再考虑vdisk同步或映射恢复。
不能。两个副本都曾被独立写入时，简单resync会覆盖其中一个副本，可能造成不可逆丢失。应先把两个副本只读挂起做取证，确认哪边是权威，再决定同步方向。
因为主机依赖这些信息识别设备。WWPN和LUN ID与故障前不一致时，Linux下sd字母会漂移，依赖固定设备名的应用会挂。重建storage view或host mapping时需逐项核对。
不算。卷在线不代表数据正确。文件系统可离线fsck，数据库用各自校验工具；关键库还应做业务级抽样校验。网关resync只保证块级一致，上层逻辑一致性要单独验证。
IBM SVC / Storwize 把后端存储抽象成 MDisk，再切分成 extent 组成 VDisk。 恢复的核心不是"盘"，而是"extent 映射表"——它在 SVC 的配置里，不在后端盘上。
| 项目 | 取值 / 位置 | 说明 |
|---|---|---|
| MDisk | 后端存储卷（可来自不同厂商阵列） | SVC 把它们当作统一的块池 |
| Extent | 固定大小的分配单元（常见 16MB~1GB，按池设置） | VDisk 由若干 extent 组成 |
| VDisk | 呈现给主机的逻辑卷 | 主机只看到 VDisk，看不到物理布局 |
| 映射表 | VDisk → extent → MDisk 的对应关系 | 存在 SVC 集群配置中，丢失后需按数据反推 |
| FlashCopy | 时间点副本，写时复制 | 可能是最快的恢复路径 |
# 在 SVC CLI 上导出关键配置（只读查询）
svcinfo lsvdisk
svcinfo lsmdisk
svcinfo lsvdiskhostmap
svcinfo lsextentpool
# 有 FlashCopy 时优先看映射关系
svcinfo lsfcmap顺序：先导出 VDisk/MDisk/extent 三层映射，再谈数据。集群起不来时， 后端盘上的数据仍在，但没有映射表就不知道哪段属于哪个 VDisk， 只能按文件系统特征反推——成本高得多。
参数判定、镜像方案、固件损坏这类问题，聊清楚不收钱；需要现场检测、书面报价或上门，统一走 项目1 服务页（到店免费检测，出报告后报价，不出结果不收费）。
18620311365
深圳市福田区深南中路2070号电子科技大厦A座35楼D22（华强北地铁站D1口步行320米）