共计 2760 个字符，预计需要花费 7 分钟才能阅读完成。
服务器数据恢复环境：
IBM X 系列服务器 + 柏科某型号存储。服务器上部署 VMware ESXi 虚拟主机，存储上寄存虚拟机文件。
虚拟主机采纳的 Windows Server 操作系统，部署宏桥和索菲 2 套利用，数据库是 SQL Server。
虚构磁盘：数据盘（精简模式）+ 快照数据盘。
服务器故障：
机房异样断电导致服务器上某台虚拟机无奈失常启动。管理员查看虚拟机配置文件，发现此虚拟机的配置文件除了磁盘文件外其余的配置文件全副失落，xxx-flat.vmdk 磁盘文件和 xxx-000001-delta.vmdk 快照文件还在。分割 VMware 原厂工程师，VMware 工程师须要新建一个虚拟机来解决故障问题，但发现 ESXi 存储空间有余。于是管理员将故障虚拟机下的 xxx-flat.vmdk 磁盘文件删除，而后 VMware 工程师重建了一个虚拟机并且调配了固定大小的虚构磁盘。
服务器数据恢复过程：
1、在 VMware vSphere Client 上将挂载的存储设备中的 VMFS 卷卸载。而后将存储上的 VMFS 卷通过网线连贯到北亚企安备份服务器上，应用工具将整个 VMFS 卷以扇区的形式镜像到备份空间上。后续的数据分析和数据恢复操作均基于镜像文件进行，防止对原始数据造成二次毁坏。
2、基于镜像文件剖析 VMFS 卷的底层，发现异常断电导致故障虚拟机目录下的目录项被毁坏，然而不影响虚拟机的重要数据，能够通过人工进行修复。
如果人为删除某个文件，目录项对应的数据区索引也会被同时清掉，然而不会影响删除文件的理论数据。能够依据被删除的虚构磁盘文件中的文件系统以及虚构磁盘中的文件类型在 VMFS 卷自由空间中进行碎片的匹配和合并这种形式来复原删除的虚构磁盘文件。
然而本案例是在上述的两个问题同时产生的状况下又新建一台虚拟机并且调配了虚构磁盘。
通过剖析发现新调配的虚构磁盘曾经全副清零了（在创立虚构磁盘的时候会抉择创立磁盘的类型），这个新建的虚拟机所占用的磁盘空间全副被清零。如果新调配的虚构磁盘占用了删除虚拟机磁盘所开释的空间，那么此局部空间的数据是无奈复原的。
故障虚拟机的目录项区域：
3、通过北亚企安数据恢复工程师团队的会诊，最终确认服务器数据恢复计划：
计划 a、复原删除的 VMDK 文件。依据删除虚构磁盘文件中的文件系统以及虚构磁盘中的文件类型在 VMFS 卷的自由空间中进行碎片匹配和合并，复原删除的虚构磁盘文件。将快照文件和复原的虚构磁盘文件合并成一个残缺的虚构磁盘文件，而后利用文件系统解释工具解释虚构磁盘文件中的所有文件。
计划 b、复原 MSSQL 数据库文件。如果计划 a 施行成果不现实，能够依据 SQL Server 数据库文件构造对 VMFS 卷自由空间中合乎 SQL Server 页构造的数据区域进行统计、剖析和聚合，生成一个能够失常应用的.MDF 格局的文件。
计划 c、复原 MSSQL 数据库备份文件。因为数据库每天都在做备份。如果上述 2 种计划施行过后还有一些数据库没有复原进去，就只能应用备份文件来复原数据库了。依据把握的备份文件.bak 的构造，对 VMFS 卷自由空间中合乎 SQL Server 备份文件构造的数据区域进行统计、剖析和聚合，生成一个能够失常导入到 SQL Server 数据库中.BAK 格局的文件。
4、服务器数据恢复施行过程：
计划 a 施行过程：依照计划 a 进行底层剖析，依据 VMFS 卷的构造以及删除虚构磁盘的文件系统信息，在底层的自由空间中扫描合乎删除虚拟机磁盘的区域，统计其数量和大小是否合乎删除虚构磁盘的大小。依据虚构磁盘中文件系统的信息将这些扫描到的碎片进行排列组合，后果发现好多碎片缺失。从新扫描这些缺失的碎片，这些碎片的确无奈找到。将扫描到的碎片依照虚构磁盘原始的程序重组，没有找到的碎片暂且留空。应用虚构磁盘快照程序合并重组好的父盘和快照盘，生成一个新的虚构磁盘。解释虚构磁盘中的文件系统，因为缺失好多数据，文件系统解释过程中呈现很多报错，提醒某些文件损坏。
解析完文件系统后发现没有找到原始的数据库文件，而宏桥备份和索菲备份这两个目录的目录构造失常。然而尝试将备份导入到数据库中时，数据库导入程序提醒报错。
导入.BAK 文件报错信息：
计划 b 施行过程：因为计划 a 中并没有将原始的数据库文件复原进去，并且很多备份文件无奈失常应用。因而采纳计划 b 来复原尚未复原进去的数据库文件。
依据 SQL Server 数据库的构造去自由空间中找到数据库的开始地位。依据 SQL Server 数据库的结构特征，数据库的第 9 个页会记录本数据库的数据库名。依据这个特色核查该数据库的头部页是否是正在查找的。SQL Server 数据库的每个页都会记录数据库页编号和文件号，依据这些特色北亚企安数据恢复工程师编写数据库扫描程序在底层扫描所有合乎数据库页的数据碎片。将扫描进去的碎片按程序重组成一个残缺 MDF 文件，通过 MDF 校验程序检测整个 MDF 文件的完整性。校检实现后发现只有 cl_system3.dbf 和 erp42_jck.dbf 这 2 个文件没有找到外，其余数据库均校验胜利。
cl_system3.dbf 和 erp42_jck.dbf 因为底层有很多碎片没有找到（可能被笼罩），因而校验不通过。
cl_system3.dbf 文件中某个碎片失落的区域：
计划 c 施行过程：
上述两个计划施行后并没有将所有的数据库文件全副复原进去。cl_system3.dbf 和 erp42_jck.dbf 这 2 个文件因局部页缺失，无奈应用，须要采纳备份来复原这两个数据库文件。然而查看完这两个文件的备份后发现 cl_system3.dbf 因为备份机制没有备份进去，而 erp42_jck.dbf 只有某个月的全副增量备份。
因为 erp42_jck.dbf 文件中只缺失大量的页，能够依据缺失的页号在增量备份中查找到缺失的页，而后将找到的页补到 erp42_jck.dbf 文件中，从而复原一部分失落的数据库页。通过上述办法补完页后还是缺失局部页，无奈失常应用，只能通过北亚企安自主开发的数据库解析程序将 erp42_jck.dbf 文件中比拟重要的几十张表导出，并胜利导入到新建的数据库中。
验证数据：
在一台服务器中搭建和原始环境一样的数据库环境，由用户方通过近程工具连贯到该服务器并装置宏桥利用。由用户方工程师验证数据库的完整性，通过重复认真验证后，确认数据库没有问题，下层利用能够失常运行，数据记录也根本没有缺失。
数据库胜利挂载：
服务器数据恢复总结：
本案例先是断电导致服务器中局部文件失落；而后人为删掉局部数据，又从新写入局部数据，导致局部数据被笼罩；又因为数据库备份机制导致局部数据库的备份不可用；所以本案例复原难度系数很高。因为北亚企安数据恢复工程师团队对 SQL Server 数据库底层构造有深刻的钻研，并且有解决相似故障类型的教训，所以能力顺利复原出用户须要的数据。
