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

全部博文(608)

文章存档

2024年(172)

2023年(218)

2022年(181)

2020年(12)

2019年(24)

我的朋友

分类: 服务器与存储

2022-07-11 11:09:16

服务器数据恢复环境:
EMC服务器,采用NAS(Isilon S系列存储);
共三个节点,每一节点配置12块SATA接口、单盘容量为3T的硬盘。




服务器故障:
管理员误删除虚拟机,被误删除的虚拟机中存储的是数据库、MP4、AS、TS类型的视频文件等。被误删除的虚拟机是通过NFS协议共享到ESX主机,视频文件通过CIFS协议共享给虚拟机(WEB服务器),NFS共享的所有数据(虚拟机)被删除而CIFS共享的数据则没有被删除。管理员联系我们数据恢复中心进行数据恢复。

服务器数据恢复过程:
1、将所有硬盘进行备份。
2、服务器数据备份完成后在Isilon的web管理界面中将Isilon正常关机。将备份好的服务器数据放到北亚数据恢复平台中对数据进行分析。


3、本案例服务器数据丢失的原因是误删除,所以不用过多考虑冗余级别,需要重点分析的是数据删除后Indoe及数据MAP是否发生变化。
4、由于服务器中被删除的虚拟磁盘文件大小都在64G或以上,除此之外没有其他大文件。北亚数据恢复工程师编写扫描所有文件Indoe的程序,将文件不小于64G的indoe全部扫描出来。通过对Indoe进行扫描找出数据MAP位置,发现其index指向的内容已不再是正常数据,并且所有节点上的Indoe均是同样的情况。
5、再次分析Inode,发现大文件的数据MAP会有多层(树结构),并且数据MAP中会记录文件的唯一ID,数据恢复工程师尝试找到文件最底层的数据MAP。数据恢复工程师对文件最底层的数据MAP做遍历跟踪操作,发现最低层的数据MAP还存在。
6、通过文件的Inode对文件的唯一ID进行提取工作,然后对所有符合该ID的数据MAP做聚合。并根据数据MAP中的VCN号做排序,数据恢复工程师通过分析发现每个文件的前17088项数据MAP都不存在,理论上每个文件的前17088项数据是无法恢复。
7、通过数据换算确定丢失的数据MAP项的大小一共不到1G,删除的文件全是虚拟机的vmdk文件,里面都是NTFS的文件系统,NTFS文件系统的MFT基本都在3G的位置。只需要在每个vmdk文件的头部手动伪造一个MBR和DBR就可以解释vmdk里面的数据了。
8、对扫描到的数据MAP做解释,并根据VCN号的顺序导出数据,没有MAP的情况保留为零。
9、数据恢复工程师将vmdk文件导出,发现文件比实际情况要小、vmdk中MFT的位置也与自身描述不符。手动随机验证了几个MPA发现都能指向数据区,而程序解释MAP的方式也都没有问题。出现这种情况的原因可能为文件稀疏!
10、北亚数据恢复工程师重新调整了代码再次导出vmdk,这次导出的数据正常且MFT的位置也在相应位置。手工伪造一个MBR,分区表以及DBR,再用北亚开发的文件系统解释工具解释文件系统成功,导出vmdk里面的数据库及视频文件。
11、验证vmdk中的数据库及视频文件没有发现问题,批量导出所有重要的vmdk文件,再手动的去修改每个vmdk文件。


服务器数据恢复结果:
将所有重要的数据恢复完成后,由服务器管理员对恢复出来的所有数据做完整性及准确性检测,最终确定数据完全没有问题,数据恢复成功。
阅读(384) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~