服务器数据恢复—异常断电导致ESXi虚拟机无法启动的数据恢复案例

本文主要是介绍服务器数据恢复—异常断电导致ESXi虚拟机无法启动的数据恢复案例，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

服务器数据恢复环境：
某大厂PS4000服务器，服务器上部署VMware ESXi虚拟化平台。

服务器故障：
机房断电，重启后服务器中的某台虚拟机不能正常启动。管理员查看虚拟机配置文件，发现无法启动的虚拟机的配置文件除了磁盘文件以外其他配置文件全部丢失，xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还存在。联系VMware原厂工程师进行诊断，VMware原厂工程师尝试新建一个虚拟机，但发现存储空间不足，于是将故障虚拟机下的xxx-flat.vmdk磁盘文件删除了。VMware工程师重新建了一个虚拟机，分配了固定大小的虚拟磁盘，为虚拟机安装了Windows Server操作系统，部署SQL Server数据库（作为宏桥和索菲两套应用的数据库），虚拟机磁盘包括：数据盘（精简模式）+快照数据盘。

服务器数据恢复过程：
1、在VMware vSphere Client上将挂载的存储设备中的VMFS卷以正常方式卸载掉。然后将存储上的VMFS卷通过网线的方式连接到北亚企安备份服务器上，将整个VMFS卷以扇区的方式镜像到备份空间上。之后的数据分析和数据恢复操作均在备份的数据上进行，避免对原始数据造成二次破坏。
2、基于备份文件分析VMFS卷的底层数据，服务器非正常断电导致故障虚拟机目录下的目录项破坏，这种破坏只是破坏了文件的目录项，不会影响虚拟机的重要数据，可以通过人工修复解决。
如果人为删除某个文件的话，则目录项对应的数据区索引会被清掉，也不会影响删除文件的实际数据，这种情况可根据删除虚拟磁盘文件中的文件系统以及虚拟磁盘中的文件类型在VMFS卷自由空间中进行碎片匹配和合并，最终恢复删除的虚拟磁盘文件。
但是在上述的两种情况之下又新建了一台虚拟机，并且分配了虚拟磁盘。经过分析发现分配的虚拟磁盘所使用的空间已经全部清零了，也是说这个新建的虚拟机所占用的磁盘空间全部被清零。如果新分配的虚拟磁盘占用了删除虚拟机磁盘文件所释放的空间，那么这部分空间的数据是无法恢复的。
故障虚拟机的目录项区域：

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

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

导入.BAK文件报错信息：

4、方案B：由于实施方案一并没有将原始的数据库文件成功恢复，而且很多备份文件都无法正常使用。北亚企安数据恢复工程师只能采用方案B来恢复方案A中尚未恢复的数据库文件。
根据SQLServer数据库的结构去自由空间中找到数据库的开始位置。SQLServer数据库的第9个页会记录本数据库的数据库名，根据这个特征核对此数据库的头部页是否是正在查找的。SQLServer数据库的每个页中都会记录数据库页编号以及文件号，北亚企安数据恢复工程师根据这个特征编写数据库扫描程序，去底层扫描所有符合数据库页的数据碎片。按顺序将扫描出来的碎片重组成一个完整MDF文件，通过MDF校验程序检测整个MDF文件的完整性。在整个校验过程中，只有cl_system3.dbf和erp42_jck.dbf这2个文件由于有部分碎片没有找到所以校验不通过之外，其余数据库文件均校验成功。
校验完的MDF文件：

cl_system3.dbf文件中某个碎片丢失的区域：

5、方案B：方案A和方案B的实施并没有将所有的数据库文件全部恢复出来。cl_system3.dbf和erp42_jck.dbf这2个文件因缺失部分页导致其无法正常使用，可以尝试通过备份来恢复这两个数据库文件，但是在检查后发现cl_system3.dbf没有备份，而erp42_jck.dbf只有最近一个月的全部增量备份。

由于erp42_jck.dbf文件中只缺失少量的页，因此可以根据缺失的页号在增量备份中查找页，然后补到erp42_jck.dbf文件中，通过这个方法可以恢复一部分丢失的数据库页。虽然补完后erp42_jck.dbf文件还是缺失部分页，无法正常使用，但是通过北亚企安自主开发的数据库解析程序，数据恢复工程师将erp42_jck.dbf文件中比较重要的几十张表成功导出，并成功导入到新建的数据库中。
6、在本地服务器中搭建和原始环境一样的数据库环境，用户通过远程工具连接到验证服务器，安装宏桥应用软件，由用户方工程验证数据库的完整性。经过用户方工程师的仔细验证，数据库可以成功挂载，上层应用可以正常运行，数据记录基本没有缺失。用户方认可数据恢复结果。