您所在的位置:首页 > 成功案例 > RAID数据恢复

EMC Isilon服务器存储误删除数据恢复过程

最新动态来源:本站原创点击数:97更新时间:2018/7/17

【服务器数据恢复故障描述】
北京某公司的EMC服务器采用高端网络NAS(Isilon S200),共有三个节点,每一节点配置12块硬盘,单盘接口为SATA硬盘,容量为3T。管理员工作中误删除虚拟机,其中包括数据库、MP4、AS、TS类型的视频文件等。需要进行数据恢复的虚拟机NFS协议共享到ESX主机,视频文件通过CIFS协议共享给虚拟机(WEB服务器)。NFS共享的所有数据(也就是所有虚拟机)被删除而CIFS共享的数据则没有被删除。

【服务器数据恢复第一步:备份】
在数据恢复过程中为保障数据安全、以免对数据造成二次破坏,数据恢复之前需要将所有硬盘进行全部备份。在本例中由于磁盘数量太多且单盘容量太大(单节点12块盘,3个节点36块盘,单盘3TB,一共108TB),因此备份周期会较长。

【服务器数据恢复第二步:数据分析】
服务器数据备份完成后在Isilon的web管理界面中将Isilon正常关机。将备份好的服务器数据放到数据恢复平台中对数据进行分析。由于数据丢失的原因是误删除,所以可以不用过多考虑该服务器的冗余级别,需要重点分析的是文件删除后Indoe及数据MAP是否发生变化。由于服务器中被删除的虚拟磁盘文件大小都在64G或以上,该服务器中再无其他大文件。数据恢复工程师决定编写扫描所有文件Indoe的程序,将文件不小于64G大小的indoe全部扫描出来,通过对Indoe进行扫描找出数据MAP位置,其index指向的内容已不再是正常数据,并且所有节点上的Indoe均是同样的情况。再仔细分析Inode,发现大文件的数据MAP会有多层(树结构),并且数据MAP中会记录文件的唯一ID,因此可以尝试找到文件最底层的数据MAP。抱着侥幸心理对文件最底层的数据MAP做遍历跟踪操作,发现最低层的数据MAP果然还在。

【服务器数据恢复过程】
通过文件的Inode进行唯一ID的提取工作,然后对所有符合该ID的数据MAP做聚合。并根据数据MAP中的VCN号做排序,工程师通过分析发现每个文件的前17088项数据MAP都不存在,理论上则每个文件的前17088项数据是真的没办法恢复了。
通过仔细的数据换算得知丢失的数据MAP项总共才包含不到1G的数据,删除的文件全是虚拟机的vmdk文件,里面都是NTFS的文件系统,NTFS文件系统的MFT基本都在3G的位置。如此看来只需要在每个vmdk文件的头部手动伪造一个MBR和DBR就可以解释vmdk里面的数据了。对扫描到的数据MAP做解释,并根据VCN号的顺序导出数据,没有MAP的情况保留为零。
数据恢复工程师将一个vmdk文件进行导出,但文件比实际情况要小、vmdk中MFT的位置也与自身描述不符。手动随机验证了几个MPA发现都能指向数据区,而程序解释MAP的方式也都没有问题。出现这种情况的原因可能为文件稀疏!
数据恢复工程师重新调整了代码部分后再次导出vmdk,这次导出的数据正常且MFT的位置也在相应位置。手工伪造一个MBR,分区表以及DBR,再用北亚开发的文件系统解释工具成功解释其文件系统,导出vmdk里面的数据库及视频文件。
在验证了此vmdk中的数据库及视频文件没问题后,批量导出所有重要的vmdk文件,再手工一个一个的去修改每个vmdk文件。

【服务器数据恢复成功】
将客户所有重要的数据恢复完成后,由客户方安排工程师对恢复的所有数据做完整性及准确性检测,数据最终确定完全没有问题,数据恢复成功。

北京北亚数据恢复中心:4006 505 646