共计 2302 个字符，预计需要花费 6 分钟才能阅读完成。
虚拟机数据恢复环境：
Dell PS 系列服务器（用于 VMware 虚拟主机）；
VMware ESXi5.5 版本；
虚拟机操作系统：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 虚构磁盘曾经全副清零了（在创立虚构磁盘的时候会抉择创立磁盘的类型），也就是说这个新建的虚拟机所占用的磁盘空间全副被清零。如果新虚构磁盘占用了删除虚拟机磁盘所开释的空间，那么此局部空间将无奈复原的。
图一：（故障虚拟机的目录项区域）
3、虚拟机数据恢复实施方案一：
a、底层剖析。依据 VMFS 卷的构造以及删除虚构磁盘的文件系统信息，在底层的自由空间中扫描合乎删除虚拟机磁盘的区域，并统计其数量和大小是否合乎删除虚构磁盘的大小。
b、依据虚构磁盘中的文件系统的信息将扫描到的碎片进行排列组合，后果发现两头有好多碎片缺失，再对这些缺失的碎片进行从新扫描，发现这些碎片的确没有找到。
c、将扫描到的碎片依照虚构磁盘本来的程序重组，对于没有找到的碎片暂且留空。
d、利用虚构磁盘快照程序将重组好的父盘和快照盘进行合并，生成一个新的虚构磁盘。
e、用业余工具解释虚构磁盘中的文件系统，因缺失好多数据，文件系统解释过程中有很多报错，提醒某些文件损坏。
图二（解释完的文件系统）：
f、在解析完文件系统后发现没有找到原始的数据库文件，而宏桥备份和索菲备份这两个目录的目录构造失常。然而在尝试将备份导入数据库中时，数据库导入程序提醒报错。
图三（宏桥备份和索菲备份的局部目录构造）：
导入.BAK 文件报错信息如下：
4、虚拟机数据恢复实施方案二：
a、因为计划一中没有将原始的数据库文件复原进去，并且其中好多备份文件都无奈失常应用。因而采纳第二套计划来复原尚未复原的数据库文件。
b、依据 SQL Server 数据库的构造去自由空间中找到数据库的开始地位。在数据库的构造中，数据库的第 9 个页会记录本数据库的数据库名。因而依据这个特色能够核查此数据库的头部页是否是正在查找的。并且数据库的每个页中都会记录数据库页编号以及文件号，所以依据这些特色编写数据库扫描程序，
而后利用程序去底层扫描所有合乎数据库页的数据碎片。
c、将扫描进去的碎片按程序重组成一个残缺 MDF 文件，再通过 MDF 校验程序检测整个 MDF 文件是否残缺。在整个校验过程中，只有 cl_system3.dbf 和 erp42_jck.dbf 因有局部碎片没有找到外，其余数据库均校验胜利。校验完的 MDF 文件如下：
d、cl_system3.dbf 和 erp42_jck.dbf 因底层有很多碎片没有找到（初步狐疑可能被笼罩），因而校验不通过。如下是 cl_system3.dbf 文件中某个碎片失落的区域：
5、虚拟机数据恢复实施方案三：
a、因为上述两个计划并没有将所有的数据库文件全副复原进去，还有 cl_system3.dbf 和 erp42_jck.dbf 这 2 个文件因缺失局部页无奈失常应用。因而须要采纳备份来复原这两个数据库文件，然而在查看完这两个文件的备份后发现 cl_system3.dbf 的 3 月某一天的数据因备份机制故障没有备份进去，而 erp42_jck.dbf 的 3 月份备份则全副没有，只有 4 月份的全副增量备份：
因为 erp42_jck.dbf 文件中只缺失大量的页，因而能够依据缺失的页号在增量备份中查找，再将找到的页补到 erp42_jck.dbf 文件中，这样能够复原一部分失落的数据库页。补完后还是缺失局部页，无奈失常应用。然而通过北亚自主开发的数据库解析程序将 erp42_jck.dbf 文件中比拟重要的几十张表胜利导出，并胜利导入到新建的数据库中。
验证数据：
在本地服务器中搭建和原始环境一样的数据库环境（SQL Server 2008），由管理员通过 Teamviewer 近程工具连贯到验证服务器，并装置下层宏桥应用软件。验证数据库根本没有发现问题，下层利用能够失常运行，数据记录也都根本没有缺失，数据库胜利挂载。本次数据恢复实现。
