故障场景
一套3节点的Linux KVM虚拟平台集群，共同挂载一个12TB FCSAN，部署了大量企业应用，包括档案系统、SVN、网站等。
12TB 存储卷采用LVM管理，被划分为数十个LV，为虚拟机提供LVM类型的虚拟存储空间。另外也有XFS类型分区，为虚拟机提供目录级别存储空间。如下图所示：
历史操作：
因业务变动，其中两个节点改为windows系统，但安装系统时未卸载FCSAN存储卷，导致所有存储卷被破坏。
用户用备份的LVM配置文件，还原了LVM结构，但所有LV都无法挂载，提示：
mount 文件系统类型错误、选项错误，/dev/mapper/xxxxxxx 上有坏超级块、缺少代码页或助手程序，或其它错误
如下图所示：
背景知识
VMware vSphere 、 RedHat KVM 、MicroSoft Hyper-V 、 Ctrix XenServer，都是被广泛部署的虚拟平台，篇幅所限，我们重点介绍KVM的存储虚拟化机制。
与vSphere不同，KVM虚拟机支持以下多种存储方式：
目录类型的Storage Pool：与VMFS类似，虚拟磁盘是一个xxx.img的文件，可保存在宿主的任意文件系统中
LVM类型的storage Pool：宿主用LVM管理器，直接创建的lv，为某个虚拟机提供空间。
iSCSI/Ceph等三方存储：虚拟机直接使用第三方存储作用Storage Pool。
本案例中的KVM，混合采用了目录类型的Storage Pool和LVM类型的storage Pool，因此我们要同时处理XFS文件系统下的img恢复，和各种虚拟机自身的NTFS、EXT3/4等文件系统恢复。
恢复过程
制定最佳恢复策略
与消费级数据恢复服务不同，企业业务需要考虑恢复策略的可回退性、海量数据恢复效率、业务系统重建、业务系统安全，等多重因素。
可回退性：本案例中，我们没有尝试重建LVM结构，以及在恢复前、恢复中、恢复后，从各方面预防FCSAN再次被其它主机破坏。
海量数据恢复效率：12TB FCSAN，我们必须在安全性、可操作性、恢复效率上，找到一个折中的恢复方案。我们与用户多次沟通，充分调动可用硬件资源，快速组建了安全、高速的恢复环境。
业务系统重建：用户业务系统中，含多个网站、Oracle、SQL系统，我们在后期恢复时，为客户提供足够的支援，协助重建业务系统。
生产系统安全：生产系统的潜在威胁来自多个方面，包括临时恢复环境可能造成的IP冲突、网络流量过载、后端 IO压力过载，以及恢复数据对存储空间的异常占用等，我们需要在多个维度为用户预警，防止我们的行为造成新的生产故障。
执行数据恢复
在恢复环境中，可以看到总共有24个分区，但无法看到内部有价值的数据：
分区扫描：
本案例中，因为KVM虚拟平台在使用过程中多次正常的新建、删除虚拟机行为，导致扫描出数百个无效分区，各分区间又有重叠。如果每一个分区都分别执行一次NTFS、EXT、XFS文件系统扫描，可能一年都恢复不出数据。
为了解决分区干扰的问题，工程师深入分析了lv底层扇区，根据各分区数据类型特征，准确判断了各分区的精确起止边界及分区类型，如下图所示：
根据我们判断的分区边界及分区类型，执行对应数据扫描：
准确扫描出生产数据：
恢复出的核心文件及Oracle数据库：
特别注意
KVM平台的多种存储池模式，开放灵活，但也导致问题点多，更容易诱导人为误操作。面对复杂的存储架构，对IT运维人员的要求就特别高。对于异常故障，我们需要冷静应对，切忌急于解决故障，轻易尝试不明确潜在风险的操作，造成更严重的后果。
本案例中，难点是：
1、对 12TB 海量数据恢复，配合用户，在有限资源下，构建安全高效的恢复环境
2、对数百个干扰分区，精确定位真实分区边界，判断文件系统类型。
技术支持
温馨提示：如重要数据丢失，还请在行动前咨询专业工程师建议，以免数据遭到二次破坏。
直接技术支持：shop396558956.taobao.com