VMware虚拟机丢失恢复成功案例

一.故障描述

客户故障为VMWARE原本挂载的VMFS分区丢失，导致存储在里面的虚拟机丢失。发现虚拟异常后，关闭虚拟机，虚拟机无法再次启动，后重启物理服务器，提示载入硬盘阵列信息，依旧无法看到文件，在远程管理中查看到RAID6第6块盘脱机。

二.故障检测

通过分析元文件，得知此文件系统元文件被破坏，节点索引丢失，无法恢复完整虚拟机。此种情况的恢复，通过全盘扫描文件信息的方式进行，根据文件信息对文件或分区进行拼接。

三.恢复方案

1、重组RAID

分析RAID信息，根据磁盘底层数据的分布，将RAID重组出来。

2、分析文件系统

客户文件系统为VMFS6文件系统，分析VMFS6文件系统底层存储结构，分析元文件、节点等信息是否完整，是否被损坏。

经检验，文件系统元文件损坏，节点位图信息丢失，通过全盘扫描文件信息的方式，根据文件信息进行拼接。

3、扫描文件信息

1）全盘扫描文件信息。

2）根据文件系统特征计算出下一个数据块的某个位置的特征值。

3）遍历所有1M块，匹配特征值，将正确的数据块与上一个块进行拼接。

4）根据扫描到的文件信息，以及根据文件系统特征对文件和分区进行拼接。

4、验证数据

拼接完成后，校验文件系统正确性并随即抽取部分文件进行验证文件是否可用。

查看文件是否可以正常打开，或数据库文件是否可以附加，备份是否正常还原。

四.数据恢复结果

因VMFS文件系统的SBC元文件损坏，索引丢失，只能按照文件结构进行拼接。又因为SBC中指针类型不同指向的数据索引所在的元文件也是不同的，若指针类型指向FBB元文件，可根据文件系统结构和文件信息通过FBB元文件位图信息中的512M位图信息进行拼接，若指针指向SBC元文件或直接指向数据区，因SBC元文件损坏则无法拼接。

因SBC元文件损坏，无法确定指针类型，所以只能根据FBB元文件中的512M位图信息尝试拼接。拼接过程中发现相似目录，创建时间分别为2020年和2019年，2019年目录结构所在分区可能为备份，因2020年拼接完成后文件系统损坏较为严重，使用2020年文件信息进行拼接后文件都是不可用状态，其表现为文件底层为全0或索引的数据块错乱（见下文对比）。所以拼接2019年的目录结构，2019年目录结构所在分区数据在底层连续性较大，拼接完成后，解析分区，除部分文件损坏外，文件都是可用状态。

因此，只能通过有效的数据信息进行拼接2019年数据。

五.挑选同文件对比

【2020年数据信息拼接】

目录结构：

图片1-水印.png