虚拟机不能启动，管理员删除了vmdk文件

虚拟机数据恢复案例介绍：本次数据恢复案例中共涉及一台R710系列服务器和一台MD3200系列存储，上层是虚拟机和虚拟文件，虚拟机系统版本为ESXI5.5版本，由于客户的机房非正常断电导致虚拟机不能启动。机房管理员对虚拟机进行了检查，虚拟机配置文件丢失，继续查询发现了xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还存在。管理员在试图恢复虚拟机的时候将原虚拟机内的xxx-flat.vmdk删除然后新建了一个虚拟机，分配了200GB的精简模式和160GB的快照数据盘，但是原虚拟机内的数据并没有恢复。
下面介根据数据恢复工程师的数据恢复步骤介绍虚拟机的数据恢复方法：数据恢复第一步先将挂载在VMware vSphere Client上的卷进行卸载，然后进行备份，方便数据恢复工程师进行数据检测和数据恢复。
经过数据恢复工程师对备份数据进行检测和分析发现虚拟机目录项由于非正常断电被破坏掉了，管理员删除的文件导致了文件的数据区索引被清除，重建虚拟机导致分配给新建虚拟机的磁盘数据被底层清零。前两者可以通过人工修复进行恢复数据，但新建虚拟机的操作直接导致了底层数据的清零，如果新建虚拟机磁盘的空间占用了原有虚拟机的释放空间则会导致这部分数据无法恢复，具体需要进一步检测。下图为虚拟机的目录项：
图一：虚拟机数据恢复案例之虚拟机目录项

虚拟化数据恢复工程师对底层数据进行分析，在自由空间内排查被删除的虚拟机磁盘区域，对这部分区域进行扫描发现了大量的碎片，随后对碎片进行重组，但是经过拼接和重组后发现仍然缺失部分碎片文件，只能暂时将丢失的文件碎片位置留空。接下来利用虚拟磁盘快照程序将重组好的父盘和快照盘进行合并，生成一个新的虚拟磁盘。再用专业工具解释虚拟磁盘中的文件系统，因缺失好多数据，文件系统解释过程中报好多错误，提示某些文件损坏。解释完的文件系统如下图：
图二：虚拟机数据恢复案例之文件系统解释结果

在解析完文件系统后发现没有找到原始的数据库文件，而宏桥备份和索菲备份这两个目录的目录结构正常。但是在尝试将备份导入数据库中时，数据库导入程序提示报错。宏桥备份和索菲备份的部分目录结构如下图：
图三：虚拟机数据恢复案例之目录结构

导入.BAK文件报错信息如下:
图四：虚拟机数据恢复案例之：文件报错信息

虚拟机数据恢复工程师根据SQL Server数据库的结构去自由空间中找到数据库的开始位置。数据库的库名通常反应在当前库的第九页内，根据这一特性可以借助一些数据恢复工具到底层扫描数据库页的碎片，然后使用数据库水片重组mdf文件，在本次数据恢复案例中除了cl_system3.dbf和erp42_jck.dbf因有部分碎片没有找到外（极有可能这部分数据被覆盖了），其余数据库均校验成功。校验完的MDF文件如下：
图五：虚拟机数据恢复案例之数据库校验成功

cl_system3.dbf文件中某个碎片丢失的区域如下图：
图六：虚拟机数据恢复案例之碎片丢失区域

虚拟机数据恢复工作进行到这一步已经将可用的数据都用的差不多了，数据依然没有恢复完全，只剩下最后一个希望，那就是备份文件，数据恢复工程师对备份文件进行了详细的检查发现丢失的两个文件依然不存在，只有部分增量备份文件。
由于erp42_jck.dbf文件中只缺失少量的页，因此可以根据缺失的页号在增量备份中查找，再将找到的页补到erp42_jck.dbf文件中，这样可以恢复一部分丢失的数据库页。最终补完后还是缺失部分页，无法正常使用。但是可以通过自主开发的数据库解析程序将erp42_jck.dbf文件中用户比较重要的几十张表成功导出，并成功导入到新建的数据库中，缺失的文件就这样恢复了。
数据验证：在数据恢复安全设备中重新搭建原始环境，将恢复出来的数据导入到数据恢复安全环境中，再由客户亲自前往验证数据库的完整性，经过验证所有数据均完整没有缺失、数据库挂载成功、上层应用运行正常，本次虚拟机数据恢复成功。