一、服务器故障描述
1、架构环境概述
服务器：IBM X 3850系列服务器（用于VMware虚拟主机）。
存储阵列：柏科RD220i系列存储（用于存放虚拟机文件）。
操作系统：VMware ESXi 5.5版本。
2、故障虚拟机概述
操作系统：Windows Server 2008（虚拟机操作系统）。
应用环境：SQL Server 2008数据库服务器（管理宏桥和索菲两套应用数据库）。
虚拟磁盘：200G数据盘（精简模式）+ 160G快照数据盘。
故障描述：因意外断电，导致某台虚拟机不能正常启动，查看虚拟机的配置文件时发现此虚拟机的配置文件除了磁盘文件以外其他配置文件全部丢失。此时xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还存在。找VMware工程师诊断后，尝试新建一个虚拟机来解决故障，但发现ESXi存储空间不足。因此就将故障虚拟机下的xxx-flat.vmdk磁盘文件删除了，这时ESXi存储就有200多G的剩余空间了，而后VMware工程师就重新建了一个40G的虚拟机，并且分配了固定大小的虚拟磁盘。
二、故障分析
1、备份数据
在VMware vSphere Client上将挂载的RD220i存储中VMFS卷以正常方式卸载掉。然后将RD220i存储上的VMFS卷通过网线的方式连接到备份服务器上，接着使用专业的工具将整个VMFS卷以扇区的方式镜像到已准备的备份空间上，以确保客户的数据安全，之后的分析和恢复操作均在备份的数据上进行。
2、分析故障原因
仔细分析VMFS卷的底层数据发现，ESXi主机的突然断电导致故障虚拟机目录下的目录项出现破坏，但是这种破坏不会影响虚拟机的重要数据，只是破坏了文件的目录项而已，可以通过人工修复即可解决。而人为删除某个文件的话，则目录项对应的数据区索引会被清掉，也不会影响删除文件的实际数据。这种情况可根据删除虚拟磁盘文件中的文件系统以及虚拟磁盘中的文件类型在VMFS卷自由空间中进行碎片匹配和合并，最终也可恢复删除的虚拟磁盘文件。但是在上述的两种情况之下又新建了一台虚拟机，并且分配了虚拟磁盘。经过仔细分析发现分配的40G虚拟磁盘已经全部清零了（在创建虚拟磁盘的时候会选择创建磁盘的类型），也是这个新建的虚拟机所占用的磁盘空间全部被清零。 如果新虚拟磁盘占用了删除虚拟机磁盘所释放的空间，那么此部分空间将无法恢复的。
如下图：（是故障虚拟机的目录项区域）
图一：
三、实施方向
1、实施方向一：恢复删除的VMDK文件
根据删除虚拟磁盘文件中的文件系统以及虚拟磁盘中的文件类型在VMFS卷的自由空间中进行碎片匹配和合并，最终恢复删除的虚拟磁盘文件，再利用快照合并程序将快照文件和恢复的虚拟磁盘文件合并成一个完整的虚拟磁盘文件，然后利用专业的文件系统解释工具解释虚拟磁盘文件中的所有文件。
2、实施方向二：恢复MSSQL数据库文件
如果方向一实施的效果不太理想，接下来可根据SQL Server数据库文件的结构，对VMFS卷自由空间中符合SQL Server页结构的数据区域进行统计、分析和聚合，最终生成一个可以正常使用的.MDF格式的文件。
3、实施方向三：恢复MSSQL数据库备份文件
由于数据库每天都在做备份，虽然每天一次增量备份，15天一次全部备份。但是如果上述两种方案实施过后还有一些数据库无法恢复的话，则只能利用恢复备份文件来恢复数据库了。根据掌握的备份文件.bak的结构，对VMFS卷自由空间中符合SQL Server备份文件结构的数据区域进行统计、分析和聚合，最终生成一个可以正常导入到SQL Server数据库中.BAK格式的文件。
四、恢复数据
1、方向一实施过程
按照方向一的思路进行底层分析，根据VMFS卷的结构以及删除虚拟磁盘的文件系统信息，在底层的自由空间中扫描符合删除虚拟机磁盘的区域，并统计其数量和大小是否符合删除虚拟磁盘的大小。再根据虚拟磁盘中的文件系统的信息将这些扫描到的碎片进行排列组合，结果发现中间有好多碎片缺失，仔细再对这些缺失的碎片进行重新扫描，发现这些碎片确实没有找到。接着将扫描到的碎片安照虚拟磁盘原本的顺序重组，对于没有找到的碎片暂且留空。接下来利用虚拟磁盘快照程序将重组好的父盘和快照盘进行合并，生成一个新的虚拟磁盘。再用专业工具解释虚拟磁盘中的文件系统，因缺失好多数据，文件系统解释过程中报好多错误，提示某些文件损坏。
图二：
在解析完文件系统后发现没有找到原始的数据库文件，而宏桥备份和索菲备份这两个目录的目录结构正常。但是在尝试将备份导入数据库中时，数据库导入程序提示报错。
图三
图四：
导入.BAK文件报错信息如下:
图五：
2、方向二实施过程
由于方向一中并没有将原始的数据库文件恢复出来，并且其中好多备份文件都无法正常使用。因此需采用第二套方案来恢复尚未恢复的数据库文件。根据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这里个文件因缺失部分页导致其无法正常使用。因此需要采用备份来恢复这两个数据库文件，但是在检查完这两个文件的备份后发现cl_system3.dbf的3月30号全部备份因备份机制故障导致没有备份出来，而erp42_jck.dbf的3月份备份全部没有，只有4月份的全部增量备份，
图八：
由于erp42_jck.dbf文件中只缺失少量的页，因此可以根据缺失的页号在增量备份中查找，再将找到的页补到erp42_jck.dbf文件中，这样可以恢复一部分丢失的数据库页。最终补完后还是缺失部分页，无法正常使用。但是可以通过自主开发的数据库解析程序将erp42_jck.dbf文件中用户比较重要的几十张表成功导出，并成功导入到新建的数据库中。
五、验证数据
在本地服务器中搭建和原始环境一样的数据库环境（SQL Server 2008），由客户通过Teamviewer远程工具连接到验证服务器，并安装上层宏桥应用软件。再由客户安排工程验证数据库是否完整，经过仔细的验证后，数据库恢复基本没问题。上层应用可以正常运行，数据记录也都基本没有缺失，数据恢复成功。
数据库成功挂载，
图九：
六、恢复总结
由于客户数据先是被突然断电导致其部分文件丢失，接着人为删掉了部分数据，并且又重新写入部分数据，导致其存在数据覆盖的可能性。最后又因数据库的备份机制原因导致部分数据库的备份数据没有，因此整个恢复难度很大。由于对SQL Server数据库底层结构足够了解，并且有处理过类似故障类型的经验。所以整个恢复过程中还算比较顺利。数据库均正常恢复，并且验证没有问题，整个数据恢复成功。