【案例分析】服务器数据恢复

服务器数据恢复环境：
IBM某型号服务器，安装VMware虚拟主机；
柏科某系列存储，存放虚拟机文件；
VMware ESXi 5.5版本操作系统；
虚拟机操作系统：Windows Server 2008；
SQL Server 2008数据库服务器，管理宏桥和索菲两套应用数据库；
虚拟磁盘：200G数据盘（精简模式）+ 160G快照数据盘。

服务器故障&分析：

意外断电导致某台虚拟机不能正常启动，经过检查发现此虚拟机除了磁盘文件以外其他配置文件全部丢失，xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还在。管理员咨询VMware工程师后尝试新建一个虚拟机，但发现ESXi存储空间不足，于是将故障虚拟机下的xxx-flat.vmdk磁盘文件删除释放空间，重新建了一个虚拟机并分配了固定大小的虚拟磁盘。但是问题依旧没有解决，数据丢失。管理员联系我们数据恢复中心进行数据恢复。
备份数据。服务器数据恢复工程师在VMware vSphere Client上将挂载的存储中VMFS卷以正常方式卸载掉。然后将存储上的VMFS卷通过网线的方式连接到备份服务器上，使用专业工具将整个VMFS卷以扇区的方式镜像到已准备好的备份空间，之后的分析和数据恢复操作均在镜像文件上进行。
分析故障原因。经过分析VMFS卷的底层数据发现，ESXi主机的突然断电导致故障虚拟机目录下的目录项被破坏，这种破坏还不会影响到虚拟机的重要数据，可以通过人工进行修复。如果人为删除某个文件的话，则目录项对应的数据区索引会被清掉，也不会影响删除文件的实际数据。这种情况可根据删除虚拟磁盘文件中的文件系统以及虚拟磁盘中的文件类型在VMFS卷自由空间中进行碎片匹配和合并，最终恢复删除的虚拟磁盘文件。但是在上述的两种情况之下又新建了一台虚拟机并且分配了虚拟磁盘，经过分析发现这个新建的虚拟机所占用的磁盘空间全部被清零。 如果新虚拟磁盘占用了删除虚拟机磁盘所释放的空间，那么此部分空间将无法恢复。

故障虚拟机的目录项区域：

【文章福利】笔者推荐自己的Linux内核源码交流群:【 869634926】整理了一些个人觉得比较好的Linux内核相关学习书籍、Linux内核视频资料共享在群里面，有需要的可以自行添加

服务器数据恢复方案：

经过北亚数据恢复工程师团队的会诊，最终确定三个数据恢复方案。

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文件是否完整。在校验过程中，发现只有2个文件有部分碎片没有找到，其余数据库文件均校验成功。

其中一个文件中某个碎片丢失的区域：

3、实施方案三

方案一和方案二实施后并没有将所有的数据库文件全部恢复出来，有2个文件因缺失部分页导致其无法正常使用。因此需要利用备份来恢复这两个数据库文件。但是在检查完这两个文件的备份后发现其中一个文件的全部备份因备份机制故障没有备份出来，而另外一个文件的全部备份则没有，只有全部增量备份。

由于其中一个文件只缺失少量的页，可以根据缺失的页号在增量备份中查找，再将找到的页补到这个文件中，服务器数据恢复工程师通过这个方法恢复出一部分丢失的数据库页。但是补完后发现还是缺失部分页，无法正常使用。服务器数据恢复工程师只好通过北亚自主开发的数据库解析程序将这个文件中比较重要的几十张表成功导出，并导入到新建的数据库中。

验证数据：
在本地服务器中搭建和原始环境一样的数据库环境（SQL Server 2008），管理员通过远程工具连接到验证服务器并安装层宏桥应用软件，由用户方工程师验证数据库是否完整，经过仔细的验证后数据库基本没有问题，上层应用可以正常运行，数据记录也基本没有缺失，数据恢复成功。

华为某型号服务器raid6数据恢复案例

服务器数据恢复环境：
华为某型号服务器；
10块硬盘组成raid6；
EXT3文件系统，划分2个lun。

服务器故障&分析：
服务器在工作过程中raid6瘫痪不可用，管理员对故障服务器的raid进行重新搭建的操作并且初始化raid，初始化进行到40%左右时强行停止了初始化，部分数据已经遭到严重破坏。管理员在多家数据恢复公司数据恢复失败之后联系到我们数据恢复中心。
导致服务器丢失数据的原因是raid6瘫痪，管理员随后使用原raid6中的9块硬盘搭建riad5并进行了长时间的初始化，这种操作对原始数据造成不可逆的损坏。在后来的服务器数据恢复操作过程中也证明了第二个LUN可以使用常规的RAID6数据恢复方法恢复出数据，但存放重要数据的第一个lun中的数据恢复成功的可能性极低。在我们数据恢复中心接到故障服务器之前已经有多家数据恢复公司对故障服务器进行了数据恢复操作，但均未能成功恢复出需要的重要数据。

服务器数据恢复过程：
1、对故障服务器中的所有磁盘进行镜像备份。
2、服务器数据恢复工程师分析故障服务器中原RAID6的RAID和磁盘的组织结构，再分析新搭建的RAID5的RAID和磁盘的组织结构。在进行实际操作时由于重新搭建RAID5导致RAID6和RAID5的底层信息大量重合，对这些数据进行分析区分非常困难，服务数据恢复工程师花费很长时间进行分析区分。

3、服务器数据恢复工程师通过分析获取到原raid6和新搭建的raid5信息后进行数据恢复算法的研究，发现可以通过其他方式恢复服务器原始的数据。服务器数据恢复工程师编写程序和校正算法，将服务器中原raid6中的第一和第二个LUN分别镜像到搭好的两个存储上。

4、恢复服务器数据。服务器数据恢复工程师验证第二个LUN数据完全正常，但第一个LUN中被破坏的一小部分数据极其重要。EXT3的根目录和第一个块组的I节点全在这部分数据里面，服务器数据恢复工程师尝试几款常用的数据恢复软件进行扫描恢复，但效果都不理想，估计前几家数据恢复公司没有成功恢复出来数据的原因就在于此。

5、在这种情况下服务器数据恢复工程师对损坏的EXT3文件系统进行修复。北亚服务器数据恢复工程师编一个小程序对EXT3文件系统进行孤目录查找，重建根目录和I节点，用文件系统解析程序打开完全正常，但为了保证原始数据的权限和属性，在LINUX下进行简单修复，LINUX可以正常挂载，然后从LINUX中把文件拷贝到格式化为EXT3 的单块磁盘的分区上。这样用户使用数据时，不再需要任何设置，文件目录结构和属性都和原来一模一样。本次数据恢复完成，数据可用性100%。