服务器数据恢复环境：
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、经过北亚企安数据恢复工程师团队的会诊，{BANNED}最佳终确认服务器数据恢复方案：
方案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数据库底层结构有深入的研究，并且有处理类似故障类型的经验，所以才能顺利恢复出用户需要的数据。
阅读(362) | 评论(0) | 转发(0) |
