服务器数据恢复环境:
WinServer操作系统服务器,部署Hyper-V虚拟机环境;
虚拟机的硬盘文件和配置文件存储在一台存储设备中;
该存储设备配置:一组4盘raid5阵列存放虚拟机数据+单块盘存放虚拟机数据备份。
服务器故障:
由于MD3200存储中虚拟机的数据文件丢失,导致整个Hyper-V服务瘫痪,虚拟机无法使用。
服务器故障检测:
1、检测物理故障,结果没有发现物理故障问题,所有硬盘均正常。
2、检测操作系统:操作系统正常运行,未发现错误进程。
3、检测丢失数据硬盘的文件系统:打开正常。继续分析丢失数据硬盘的文件系统,发现文件系统的元文件创建时间(即文件系统的创建时间)与数据丢失的时间相同。这种情况意味着文件系统被人为重写,即分区被格式化了。
4、检查系统日志:系统日志数据丢失之前及当天的系统日志已被清空,但是审核日志和服务日志还在,恰巧格式化分区的操作只记录在系统日志中。这种情况再次印证这次数据灾难是人为导致的。
5、尝试恢复系统日志,从底层数据查看发现需要恢复的系统日志已被新的日志记录覆盖,无法恢复。
6、分析所有分区,发现只有两个分区的文件系统被重新写入新的文件系统。因为两个分区的格式化需要有两个独立的过程,这种针对性的操作再次证明本次数据灾难由人为操作导致。
服务器数据恢复过程:
1、将故障存储设备中所有的硬盘编号取出,以只读方式对所有硬盘做全盘镜像,后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始数据造成二次破坏。
备份所有硬盘数据:
2、镜像完成后,基于镜像文件分析RAID5磁盘阵列相关信息如条带大小、条带走向等。根据这些信息重组raid5磁盘阵列。
重组RAID5磁盘阵列:
打开RAID5磁盘阵列:
3、分析硬盘底层数据发现还残留着许多以前文件系统的目录项及文件索引。经过核对发现这些文件索引指向的数据都是用户丢失的文件内容。北亚企安数据恢复工程师编写提取文件索引项的小程序扫描并提取所有文件的文件索引项。
4、分析提取出来的文件索引项,发现这些索引项都是不连续的,大多数都是以16K或8K对齐的。正常情况下文件索引项是连续的,大小为固定的1K,每个文件索引项对应一个文件或目录。而扫描出来的这些不连续并且不完整的文件索引项是无法正常索引到文件内容的,因此需要处理这些扫描出来的文件索引项。
在扫描出来的文件索引项中搜索” .VHD”,能找到一个” .VHD”的文件记录,然后将这个片连续的文件索引项提取出来。
接着再查看这段提取出来的文件索引项中是否有指向下一段文件索引项的记录或者H20属性。如果有则根据文件索引项中的特征去匹配下一段文件索引项,如果没有则跳过这段文件索引项。
根据以上方法能找到了大多数的文件索引项片段,而缺失的文件索引项片段有可能被破坏了,可以从数据备份盘中去查找缺失的文件索引项片段,最终可以找到大部分的文件索引项。
文件索引项截图:
5、找到所有能找到的文件索引项之后,根据文件索引项的编号将其拼接成整个目录项结构。以下是搜索到的部分文件索引项,虽然小部分文件索引项被破坏,但这些找到的文件索引项已经足够拼接整个目录结构。
扫描到的文件索引项碎片:
6、将重建好的目录结构替换现有文件系统中的目录结构并修改部分校验值,然后解释这个目录结构就可以看到丢失的数据了。
解释出来的目录结构:
为了验证数据是否正确,将其中一个最新的VHD文件拷贝到一台支持附加VHD的服务器上,尝试附加此VHD,结果附加成功。检查VHD中最新的数据的完整度,没有发现问题后将所有数据恢复到一块硬盘中。
恢复出来的所有虚拟机数据文件:
7、在一台测试服务器上搭建Hyper-V环境,将恢复出来的虚拟机文件连接到这台服务器上,通过导入虚拟机的方式将恢复出来的数据都迁移到新的Hyper-V环境,然后让用户亲自验证所有虚拟机。
虚拟机导入的过程:
8、用户验证所有虚拟机没有问题后,将所有数据拷贝至用户准备好的服务器中。用导入的方式将虚拟机导入到用户准备好的Hyper-V环境中。导入过程中和导入后都没有报错,尝试启动所有虚拟机都没有发现问题。本次数据恢复工作完成。
标签:数据恢复,Hyper,文件,虚拟机,文件系统,索引,服务器 From: https://blog.51cto.com/sun510/6056852