详细内容：服务器故障：
机房非正常断电导致虚拟机不能启动。服务器管理员对虚拟机进行了检查发现虚拟机配置文件丢失，xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还存在。
服务器管理员在试图恢复虚拟机的时候将原虚拟机内的xxx-flat.vmdk删除然后新建了一个虚拟机，分配了200GB的精简模式和160GB的快照数据盘，但是原虚拟机内的数据并没有恢复。服务器管理员联系我们数据恢复中心进行虚拟机数据恢复。
虚拟化数据恢复过程：
1、将挂载在VMware vSphere Client上的卷卸载后备份。
2、经过数据恢复工程师对备份数据进行检测和分析发现虚拟机目录项由于非正常断电被破坏，服务器管理员删除操作导致文件的数据区索引被清除，重建虚拟机导致分配给新建虚拟机的磁盘数据底层被清零。虚拟机目录项和文件的数据区索引可以通过人工修复方式进行恢复数据，但新建虚拟机的操作导致底层数据清零，如果新建虚拟机磁盘的空间占用了原虚拟机的释放空间则会导致这部分数据无法恢复，具体需要进一步检测。
虚拟机数据恢复案例之虚拟机目录项：
3、虚拟化数据恢复工程师对底层数据进行分析，在自由空间内排查被删除的虚拟机磁盘区域，对这部分区域进行扫描发现了大量的碎片。数据恢复工程师对碎片进行重组，通过拼接和重组后发现缺失部分碎片文件，只能暂时将丢失的文件碎片位置留空。
4、虚拟化数据恢复工程师利用虚拟磁盘快照程序将重组好的父盘和快照盘进行合并，生成一个新的虚拟磁盘。利用工具解释虚拟磁盘中的文件系统，因缺失好多数据，文件系统解释过程中频繁报错提示文件损坏。
5、解析完文件系统后发现没有找到原始的数据库文件，而**备份和**备份这两个目录的目录结构正常。但是在尝试将备份导入数据库中时，数据库导入程序提示报错。**备份和**备份的部分目录结构如下图
6、虚拟机数据恢复工程师根据SQL Server数据库的结构去自由空间中找到数据库的开始位置。数据库的库名通常出现在当前库的第九页内，根据这一特性可以借助一些数据恢复工具到底层扫描数据库页的碎片，再利用数据库碎片重组mdf文件，在本次数据恢复案例中除了cl_system3.dbf和erp42_jck.dbf因有部分碎片没有找到外
7、虚拟机数据恢复到这一步已经将可用的数据都利用得差不多了，但是数据依然没有恢复完整，*后只能依靠备份文件。数据恢复工程师对备份文件进行详细的检查后发现这两个丢失的文件依然不存在，只有部分增量备份文件。
8、由于erp42_jck.dbf文件中只缺失少量的页，因此可以根据缺失的页号在增量备份中查找，将找到的页补到erp42_jck.dbf文件中，通过这种方式可以恢复一部分丢失的数据库页。但是补完后还是缺失部分页，无**常使用。
9、虚拟化数据恢复工程师通过北亚数据恢复中心自主开发的数据库解析程序将erp42_jck.dbf文件中用户比较重要的几十张表成功导出，并成功导入到新建的数据库中，恢复出来缺失的文件。
虚拟化数据恢复数据验证：
在数据恢复安全设备中重新搭建原始环境，将恢复出来的数据导入到数据恢复安全环境中，再由服务器管理员亲自验证数据库的完整性，经过验证所有数据均完整没有缺失、数据库挂载成功、上层应用运行正常，本次虚拟机数据恢复完成。(联系我时，请说明是在51站台网看到的，谢谢！)