-4006-505-646

EMC Isilon(OneFS)存储数据恢成功复案例

【科普Isilon的存储结构】

Isilon内部使用的是分布式文件系统OneFS。在Isilon存储集群里面每个节点均为单一OneFS文件系统,所以Isilon在支持横向扩展的同时并不会影响数据正常使用。在存储集群工作时,所有节点提供相同的功能,节点与节点之前没有主备之分。当用户往存储集群中存储文件时,OneFS层会将文件分成128K的片段分别存到不同的节点中,而在节点层又会将128K的片段分成8K的小片段分别存到该节点的不同硬盘中。而用户文件的Indoe信息、目录项及数据MAP则会分别存储在所有节点中,这样可以确保用户不管从那个节点都可以访问到所有数据。Isilon在初始化时会让用户选择相应的存储冗余模式,不同的冗余模式所提供的数据安全级别也不一样(默认3个节点采用N+2:1模式)。

【存储数据恢复故障描述】
某公司管理员由于误操作将服务器中包括MSSQL数据库,以及大量的MP4、ASF和TS类型的视频文件等重要数据删除。需要进行数据恢复的这台服务器整体存储架构采用EMC高端网络NAS(Isilon S200),节点数量为3个,每个节点配置12块3T STAT硬盘,无SSD。需要进行数据恢复的数据包括vmware虚拟机(WEB服务器)和视频文件,虚拟机通过NFS协议共享到ESX主机,视频文件通过CIFS协议共享给虚拟机(WEB服务器)。NFS共享的所有数据(也就是所有虚拟机)被删除而CIFS共享的数据则没有被删除。

【备份服务器数据】
因考虑到数据安全性,避免对数据造成二次破坏,需对所有硬盘进行全部备份。但是由于磁盘数量太多(单节点12块盘,3个节点36块盘),且单盘容量太大(单盘3TB,一共108TB),因此备份周期会较长。最终客户决定,只对存储中现有数据进行备份,并且由北亚备份一次,客户再备份一次,以确保现有数据安全。

【服务器数据分析】
服务器数据备份完成后在Isilon的web管理界面中将Isilon正常关机。再将所有节点上的所有硬盘贴上标签,并依次取出再放到数据恢复平台中,开始分析所有硬盘中的数据。
由于客户数据是被删除了,因此不用过多考虑存储的冗余级别,重点需要分析文件删除后,文件Indoe及数据MAP是否发生变化。删除的虚拟磁盘文件都在64G或以上,并且存储中没有其他类型的大文件。编写扫描所有文件Indoe的程序,将文件大小符合64G或以上的Indoe都扫描出来。再仔细分析扫描出来的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文件比实际情况要小,并且vmdk中MFT的位置也与自身描述不符。手动随机验证了几个MPA发现都能指向数据区,而程序解释MAP的方式也都没有问题。所以猜测到可能为文件稀疏!
将代码进行部分调整后重新导出刚才的vmdk,这次vmdk大小符合实际大小,且MFT的位置也在相应位置。手工伪造一个MBR,分区表以及DBR,再用北亚开发的文件系统解释工具成功解释其文件系统,导出vmdk里面的数据库及视频文件。
在验证了此vmdk中的数据库及视频文件没问题后,批量导出所有重要的vmdk文件,再手工一个一个的去修改每个vmdk文件。

【数据验收】
将客户所有重要的数据恢复完成后,由客户方安排工程师对恢复的所有数据做完整性及准确性检测,数据最终确定完全没有问题,数据恢复成功。
北京北亚数据恢复中心:4006 505 646