虚拟化数据恢复环境：

某品牌服务器（部署VMware EXSI虚拟机）+同品牌存储（存放虚拟机文件）。

虚拟化故障：

意外断电导致服务器上某台虚拟机无法正常启动。查看虚拟机配置文件发现这台故障虚拟机除了磁盘文件以外其他配置文件全部丢失，xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还在。管理员联系VMware工程师寻求帮助。VMware工程师尝试新建一个虚拟机来解决故障，但发现ESXi存储空间不足。于是将故障虚拟机下的xxx-flat.vmdk磁盘文件删除，然后重建一个虚拟机并且分配固定大小的虚拟磁盘。新建虚拟机安装Windows Server操作系统，部署SQL Server数据库环境（管理宏桥和索菲两套应用数据库）。

虚拟化数据恢复过程：

1、在VMware vSphere Client上将挂载的存储上的VMFS卷以正常方式卸载，然后将存储上的VMFS卷通过网线的方式连接到备份服务器上。使用工具将整个VMFS卷以扇区的方式镜像到备份空间上，以确保数据安全。之后的数据分析和数据恢复操作均在备份数据上进行，避免对原始数据造成二次破坏。

2、基于备份数据分析VMFS卷的底层数据，发现异常断电导致故障虚拟机目录下的目录项被破坏。这种破坏不会影响虚拟机的重要数据，可以通过人工修复。如果是人为删除某个文件，目录项对应的数据区索引会被清掉，但是也不会影响被删除文件的实际数据。这种情况可根据删除虚拟磁盘文件中的文件系统以及虚拟磁盘中的文件类型，在VMFS卷自由空间中进行碎片匹配和合并来恢复删除的虚拟磁盘文件。但是在上述两种情况之下又新建了一台虚拟机，并且分配了虚拟磁盘。经过分析发现分配的虚拟磁盘已经全部清零（在创建虚拟磁盘的时候会选择创建磁盘的类型），也就是这个新建的虚拟机所占用的磁盘空间全部被清零。 如果新建虚拟磁盘占用了被删除虚拟机磁盘文件所释放的空间，那么此部分空间中的数据将无法恢复。

3、方案a：

根据VMFS卷的结构以及删除虚拟磁盘的文件系统信息，在底层的自由空间中扫描符合删除虚拟机磁盘的区域，并统计其数量和大小是否符合删除虚拟磁盘的大小。根据虚拟磁盘中文件系统的信息将这些扫描到的碎片进行排列组合，结果发现很多碎片缺失。重新扫描也没有找到这些缺失的碎片。将扫描到的碎片按照虚拟磁盘原本的顺序进行重组，对于没有找到的碎片暂且留空。使用虚拟磁盘快照程序将重组好的父盘和快照盘进行合并，生成一个新的虚拟磁盘，然后解释虚拟磁盘中的文件系统。因为数据缺失，文件系统解释过程中出现大量报错，提示某些文件损坏。

解析完文件系统后发现没有找到原始的数据库文件。虽然宏桥备份和索菲备份这两个目录的目录结构正常，但是将备份导入数据库中时，数据库导入程序报错。

4、方案b：

由于方案a并没有将原始的数据库文件恢复出来，并且好多备份文件都无法正常使用。因此采用方案b来恢复尚未恢复出来的数据库文件。

根据SQL Server数据库的结构去自由空间中找到数据库的开始位置。根据SQLServer数据库结构，数据库的第9个页会记录数据库的数据库名。根据这个特征可以核对此数据库的头部页是否是正在查找的。SQL Server数据库的每个页中都会记录数据库页编号以及文件号。根据SQL Server数据库的上述那些特征，

北亚企安数据恢复工程师编写数据库扫描程序。利用该程序去底层扫描所有符合数据库页的数据碎片，然后将扫描出来的碎片按照顺序重组成一个完整MDF文件。通过MDF校验程序检测MDF文件的完整性。在校验过程中，只有cl_system3.dbf和erp42_jck.dbf因有部分碎片没有找到外，其余数据库文件均校验成功。

5、方案c：

上述两个方案实施完后并没有将所有的数据库文件恢复出来。cl_system3.dbf和erp42_jck.dbf这2个文件因缺失部分页导致无法正常使用，因此需要采用备份来恢复这两个数据库文件。在检查完这两个文件的备份后发现cl_system3.dbf的全部备份因备份机制故障没有备出来，而erp42_jck.dbf只有增量备份。

由于erp42_jck.dbf文件中只缺失少量的页，因此可以根据缺失的页号在增量备份中查找缺失的页，然后补到erp42_jck.dbf文件中。这样可以恢复一部分丢失的数据库页。虽然补完后还是缺失部分页，但是通过北亚企安自主开发的数据库解析程序将erp42_jck.dbf文件中比较重要的几十张表成功导出，并成功导入到新建的数据库中。

6、验证数据

在本地服务器中搭建和原始环境一样的数据库环境。由用户方通过远程工具连接到验证服务器，并安装上层宏桥应用软件验证数据库是否完整。经过仔细验证，用户确认数据库基本没问题，上层应用可以正常运行，数据记录也基本没有缺失，数据库成功挂载。