VMware虚拟机丢失恢复案例
发布日期：2019-03-29 浏览次数：161
1.故障描述
故障为VMWARE原本挂载的VMFS分区丢失，导致存储在里面的虚拟机丢失。发现虚拟异常后，关闭虚拟机，虚拟机无法再次启动，后重启物理服务器，提示载入硬盘阵列信息，依旧无法看到文件，在远程管理中查看到RAID6第8块盘脱机。
2.故障检测
通过分析元文件，得知此文件系统元文件被破坏，节点索引丢失，无法恢复完整虚拟机。此种情况的恢复，通过全盘扫描文件信息的方式进行，根据文件信息对文件或分区进行拼接。
3.恢复方案
1、重组RAID
分析RAID信息，根据磁盘底层数据的分布，将RAID重组出来。
2、分析文件系统
客户文件系统为VMFS6文件系统，分析VMFS6文件系统底层存储结构，分析元文件、节点等信息是否完整，是否被损坏。
经检验，文件系统元文件损坏，节点位图信息丢失，通过全盘扫描文件信息的方式，根据文件信息进行拼接。
3、扫描文件信息
1）全盘扫描文件信息。
2）根据文件系统特征计算出下一个数据块的某个位置的特征值。
3）遍历所有1M块，匹配特征值，将正确的数据块与上一个块进行拼接。
4）根据扫描到的文件信息，以及根据文件系统特征对文件和分区进行拼接。
4、验证数据
拼接完成后，校验文件系统正确性并随即抽取部分文件进行验证文件是否可用。
查看文件是否可以正常打开，或数据库文件是否可以附加，备份是否正常还原。
4.数据恢复结果
因VMFS文件系统的SBC元文件损坏，索引丢失，只能按照文件结构进行拼接。又因为SBC中指针类型不同指向的数据索引所在的元文件也是不同的，若指针类型指向FBB元文件，可根据文件系统结构和文件信息通过FBB元文件位图信息中的512M位图信息进行拼接，若指针指向SBC元文件或直接指向数据区，因SBC元文件损坏则无法拼接。
因SBC元文件损坏，无法确定指针类型，所以只能根据FBB元文件中的512M位图信息尝试拼接。拼接过程中发现相似目录，创建时间分别为2021年和2020年，2020年目录结构所在分区可能为备份，因2021年拼接完成后文件系统损坏较为严重，使用2020年文件信息进行拼接后文件都是不可用状态，其表现为文件底层为全0或索引的数据块错乱（见下文对比）。所以拼接2020年的目录结构，2020年目录结构所在分区数据在底层连续性较大，拼接完成后，解析分区，除部分文件损坏外，文件都是可用状态。
因此，只能通过有效的数据信息进行拼接2020年数据。
联系方式郑州999服务器数据恢复中心
电话：18137814883
