服务器数据恢复环境：
某品牌X3850系列服务器（用于VMware虚拟主机）+某品牌RD220i系列存储（用于存放虚拟机文件）+VMware ESXi虚拟化操作系统。
虚拟机操作系统：Windows Server，虚拟机上运行SQL Server数据库（宏桥和索菲两套应用的数据库）。
虚拟磁盘：数据盘（精简模式）+ 快照数据盘。
服务器故障：
意外断电导致某台虚拟机无法正常启动。管理员检查后发现此虚拟机除了磁盘文件以外其他配置文件全部丢失，xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还在。管理员联系VMware工程师寻求帮助。VMware工程师尝试新建一个虚拟机，但发现ESXi存储空间不足，于是将故障虚拟机下的xxx-flat.vmdk磁盘文件删除了。VMware工程师重建了一个虚拟机，并且分配了固定大小的虚拟磁盘。
服务器数据恢复过程：
1、在VMware vSphere Client上将挂载的RD220i存储中VMFS卷以正常方式卸载，然后将RD220i存储上的VMFS卷通过网线连接到北亚企安备份服务器上。使用专业工具将VMFS卷以扇区的方式镜像到已准备好的备份空间上。后续数据分析和数据恢复操作均在镜像文件上进行，避免对原始数据造成二次破坏。
2、故障分析：
a、基于镜像文件分析VMFS卷的底层数据，发现ESXi主机的非正常断电导致故障虚拟机目录下的目录项被破坏，这种问题可以通过人工修复。
b、人为删除某个文件，则目录项对应的数据区索引会被清掉，不会影响文件的实际数据，这种情况可根据删除虚拟磁盘文件中的文件系统以及文件类型，通过在VMFS卷自由空间中匹配和合并碎片的方法来恢复删除的虚拟磁盘文件。
但是本案例中的故障情况是在上述的两种情况下又新建了一台虚拟机并且分配了虚拟磁盘。经过分析发现分配的虚拟磁盘已经全部清零（在创建虚拟磁盘的时候会选择创建磁盘的类型），也就是说这个新建的虚拟机所占用的磁盘空间全部被清零。 如果新虚拟磁盘占用了删除虚拟机磁盘文件所释放的空间，那么此部分空间的数据将无法恢复。
故障虚拟机的目录项区域：
3、经过北亚企安数据恢复工程师团队会诊后，确定以下三套数据恢复方案。
a、方案一：恢复删除的VMDK文件。
根据删除虚拟磁盘文件中的文件系统以及文件类型在VMFS卷的自由空间中匹配和合并碎片，恢复删除的虚拟磁盘文件。使用快照合并程序将快照文件和恢复的虚拟磁盘文件合并成一个完整的虚拟磁盘文件，然后通过文件系统解释工具解释虚拟磁盘文件中的所有文件。
b、方案二：恢复MSSQL数据库文件。
如果方案一效果不理想，可根据SQL Server数据库文件结构，对VMFS卷自由空间中符合SQL Server页结构的数据区域进行统计、分析和聚合，生成一个可以正常使用的.MDF格式的文件。
c、方案三：恢复MSSQL数据库备份文件。
如果上述两种方案执行后还有一些数据库文件无法恢复的话，可以通过备份文件（故障虚拟机中的数据库每天做一次增量备份，15天做一次全部备份。）恢复数据库。根据备份文件.bak的结构，对VMFS卷自由空间中符合SQL Server备份文件结构的数据区域进行统计、分析和聚合，生成一个可以正常导入到SQL Server数据库中.BAK格式的文件。
4、执行方案一。基于镜像文件分析底层，根据VMFS卷的结构以及删除虚拟磁盘的文件系统信息，在底层的自由空间中扫描符合删除虚拟机磁盘的区域，统计其数量和大小是否符合删除虚拟磁盘的大小。根据虚拟磁盘中的文件系统信息将这些扫描到的碎片进行排列组合，结果发现中间有好多碎片缺失，重新扫描还是没有找到这些缺失的碎片。将扫描到的碎片按照虚拟磁盘原本顺序重组，暂且留空没有找到的碎片。使用虚拟磁盘快照程序合并重组好的父盘和快照盘，生成一个新的虚拟磁盘。解释虚拟磁盘中的文件系统，因为很多数据缺失，文件系统解释过程中出现很多报错，提示某些文件损坏。
文件系统解析完成后没有找到原始数据库文件，而宏桥备份和索菲备份这两个目录的目录结构正常，但是尝试将备份导入数据库中时，数据库导入程序提示报错。
导入.BAK文件报错信息:
2、执行方案二。由于方案一没有将数据库文件恢复出来，且其中很多备份文件都无法正常使用，因此采用第二套方案来恢复尚未恢复的数据库文件。
根据SQL Server数据库的结构去自由空间中找到数据库的开始位置。在SQL Server数据库的结构中，数据库的第9个页会记录本数据库的数据库名，根据这个特征核对此数据库的头部页是否是正在查找的。数据库的每个页中都会记录数据库页编号以及文件号，北亚企安数据恢复工程师根据这些特征编写数据库扫描程序去底层扫描所有符合数据库页的数据碎片。接着将扫描出来的碎片按顺序重组成一个完整MDF文件。通过MDF校验程序检测MDF文件的完整性。经过校验，只有cl_system3.dbf和erp42_jck.dbf因有部分碎片缺失没有找到外，其余数据库文件均校验成功。
cl_system3.dbf和erp42_jck.dbf因底层有很多碎片缺失找不到（初步怀疑被覆盖），因此校验不通过。
cl_system3.dbf文件中某个碎片丢失的区域：
3、执行方案三。
由于前两个方案执行后并没有将所有的数据库文件全部恢复出来。cl_system3.dbf和erp42_jck.dbf这2个文件因缺失部分页导致其无法正常使用，因此需要采用备份来恢复这两个数据库文件，但是检查完这两个文件的备份后发现cl_system3.dbf因备份机制故障没有备份出来，erp42_jck.dbf没有全部备份，只有增量备份。
由于erp42_jck.dbf文件中只缺失少量的页，因此可以根据缺失的页号在增量备份中查找，再将找到的页补到erp42_jck.dbf文件中，通过这种方式可以恢复一部分丢失的数据库页。结果补完后还是缺失部分页，无法正常使用。通过北亚企安自主开发的数据库解析程序将erp42_jck.dbf文件中比较重要的几十张表导出并导入到新建的数据库中。
验证数据：
在本地服务器中搭建和原始环境一样的数据库环境并安装上层宏桥应用软件。由用户方工程验证数据库是否完整，经过仔细验证，上层应用可以正常运行，数据记录基本没有缺失，数据库成功挂载。用户方认可本次数据恢复结果。
