Chinaunix首页 | 论坛 | 博客
  • 博客访问: 336397
  • 博文数量: 586
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 5895
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-02 14:16
文章分类

全部博文(586)

文章存档

2024年(151)

2023年(218)

2022年(181)

2020年(12)

2019年(24)

我的朋友

分类: 服务器与存储

2024-06-13 13:29:19

服务器存储数据恢复环境:
EMC Isilon S200集群存储,共三个节点,每节点配置12块SATA硬盘。

服务器存储故障:
工作人员误操作删除虚拟机,虚拟机中数据包括数据库、MP4、AS、TS类型的视频文件等。需要恢复数据的虚拟机通过NFS协议共享到ESX主机,视频文件通过CIFS协议共享给虚拟机(WEB服务器)。
通过NFS协议共享的所有数据(虚拟机)被删除,而通过CIFS协议共享的数据没有被删除。


服务器存储数据恢复过程:
1、将所有节点中硬盘编号后取出,硬件工程师检测后没有发现有硬盘存在硬件故障和明显坏道。将所有磁盘以只读方式进行扇区级全盘镜像,镜像完成后将所有磁盘按照编号还原到原节点中,后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。

2、所有数据备份完成后,在Isilon的web管理界面中将Isilon正常关机。

基于镜像文件对底层数据进行分析。由于是误删除数据,所以需要分析数据删除后Indoe及数据MAP是否发生变化。由于被删除的虚拟磁盘文件大小都在64G或以上,而且存储中无其他大文件。北亚企安数据恢复工程师编写程序扫描所有文件Indoe,将大小不小于64G的文件indoe全部扫描出来。通过扫描Indoe找出数据MAP位置,发现其index指向的内容已不再是正常数据,并且所有节点上的Indoe均是同样的情况。
3、分析Inode,发现大文件的数据MAP会有多层(树结构),并且数据MAP中会记录文件的唯一ID,因此可以尝试找到文件{BANNED}最佳底层的数据MAP。北亚企安数据恢复工程师尝试对文件底层数据MAP做遍历跟踪操作,发现底层的数据MAP还在。

4、通过文件的Inode提取唯一ID,然后将所有符合该ID的数据MAP做聚合。根据数据MAP中的VCN号排序,北亚企安数据恢复工程师分析发现每个文件的前17088项数据MAP都不存在,理论上这些数据是无法恢复了。
5、通过数据换算得知丢失的数据MAP项的大小不到1GB,删除的文件是虚拟机的vmdk文件,里面都是NTFS文件系统,而NTFS文件系统的MFT一般都在3GB的位置,只需要在每个vmdk文件的头部伪造一个MBR和DBR就可以解释vmdk里面的数据。解释扫描到的数据MAP并根据VCN号的顺序导出数据,没有MAP的情况保留为零。
6、将其中一个vmdk文件导出,但导出的文件比实际情况要小,vmdk中MFT的位置也与自身描述不符。随机验证了几个MPA发现都能指向数据区,程序解释MAP的方式也都没有问题,出现这种情况的原因可能为文件稀疏!
7、重新调整部分代码再次导出vmdk,这次导出的数据正常且MFT的位置也在相应位置。手工伪造一个MBR,分区表以及DBR,再用北亚企安自主开发的文件系统解释工具解释文件系统,导出vmdk里面的数据库及视频文件。

8、经过验证,此vmdk中的数据库及视频文件没有发现问题,批量导出所有vmdk文件,再手动修改每个vmdk文件。
9、将所有数据恢复完成后,用户方工程师对所有恢复出来的数据做完整性及准确性检测,经过检测没有发现问题,本次数据恢复工作完成。
阅读(444) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~