服务器数据恢复环境:
北京某公司的EMC NAS,总共有3个节点,每个节点配置12块STAT硬盘。
NAS中存放有vmware虚拟机(WEB 服务器)和视频文件。
虚拟机通过NFS协议共享到ESX主机,视频文件通过CIFS协议共享给虚拟机(WEB服务器)。
服务器故障:
由于工作人员误操作将包括MSSQL数据库,大量MP4、ASF和TS格式的视频文件删除。NFS共享的所有数据(虚拟机)被删除而CIFS共享的数据则没有被删除。
服务器数据恢复过程:
1、对故障存储中所有硬盘以只读方式进行全盘镜像。后续的数据分析和数据恢复操作都基于镜像进行,避免对原始数据造成二次破坏。
2、基于镜像文件分析所有硬盘中的数据。由于数据是被人为删除的,需要分析文件被删除后,文件的Indoe及数据MAP是否发生变化。
3、由于被删除的虚拟磁盘文件大小都在64G或者以上,而且存储中没有其他类型的、文件大小超过64G的大文件。北亚企安数据恢复工程师编写Indoe扫描程序,将大小符合64G或以上的文件的Indoe都扫描出来。
4、分析扫描出来的Indoe,找出数据MAP位置,其index指向的内容不是正常数据,并且所有节点上的Indoe均是同样的情况。
5、分析Inode,发现大文件的数据MAP会有多层(树结构),并且数据MAP中会记录文件的唯一ID,因此可以尝试找到文件底层的数据MAP。
6、对文件底层的数据MAP做遍历跟踪操作后发现底层的数据MAP果然还在。
7、从文件的Inode取出文件的唯一ID,聚合所有符合该ID的数据MAP。根据数据MAP中的VCN号排序,发现每个文件的前17088项数据MAP都不存在,这意味着每个文件的前17088项数据没法恢复。
8、经过换算发现丢失的数据MAP项总共包含不到1G的数据,而删除的文件全是虚拟机的vmdk文件,内部采用的NTFS文件系统,而NTFS文件系统的MFT基本都在3G的位置,也就是只需要在每个vmdk文件的头部手动伪造一个MBR和DBR就可以解释vmdk里面的数据。
9、解释扫描到的数据MAP,根据VCN号的顺序导出数据,没有MAP的情况就保留为零。经过不断的测试,尝试导出一个vmdk文件,发现导出的vmdk文件比实际情况要小,并且vmdk中MFT的位置也与自身描述不符。
10、随机验证几个MAP发现都能指向数据区,程序解释MAP的方式也都没有发现问题。所以初步判断出现这种情况的原因可能是文件稀疏。
11、调整代码后重新导出刚才的vmdk文件,这次vmdk文件大小符合实际,且MFT的位置正确。手工伪造一个MBR、分区表以及DBR,使用北亚企安自主开发的文件系统解释程序成功解释其文件系统,导出该vmdk文件里的数据库及视频文件。
12、验证此vmdk中的数据库及视频文件没有问题后,批量导出所有的vmdk文件,再手工修改每个vmdk文件。直至恢复出所有用户需要的数据。
服务器数据验证:
将所有重要数据恢复完成后,由用户方安排工程师对恢复出来的数据做完整性及准确性验证。经过反复验证测试,用户方确认数据完整有效。本次数据恢复工作完成。
审核编辑:汤梓红
-
服务器
+关注
关注
12文章
8987浏览量
85123 -
数据恢复
+关注
关注
10文章
543浏览量
17355
发布评论请先 登录
相关推荐
评论