EMC Isilon(OneFS)数据恢复案例详解

简介:

【故障描述】

    某大学因黑客入侵,导致其“教学系统”的重要数据被删除。其中包括“教学系统”中的MSSQL数据库,以及大量的MP4、ASF和TS类型的视频教学文件。整体存储架构采用EMC高端网络NAS(Isilon S200),节点数量为3个,每个节点配置12块3T STAT硬盘,无SSD。所有数据一共分两部分,一部分数据为vmware虚拟机(WEB服务器),通过NFS协议共享到ESX主机,另一部分数据为视频教学文件,通过CIFS协议共享给虚拟机(WEB服务器)。黑客只删除了NFS共享的所有数据(也就是所有虚拟机),而CIFS共享的数据则没有被删除。

wKioL1XgD7iRHMbAAAHND0lmxTA723.jpg

【数据备份】

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

wKiom1XgDh-SaO9XAANaQBSng4Q482.jpg

【数据分析】

    备份完所有数据后,在Isilon的web管理界面中将Isilon正常关机。再将所有节点上的所有硬盘贴上标签,并依次取出再放到北亚提供的数据恢复平台中,开始分析所有硬盘中的数据。

wKioL1XgEmOScQWxAAIjM92U7Xc367.jpg

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

wKiom1XgDy-iwm48AAJpIJ7aiB8373.jpg

    由于客户数据是被删除了,因此不用过多考虑存储的冗余级别,重点需要分析文件删除后,文件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的位置也与自身描述不符。是程序的问题?还是数据MAP本身已损坏?手动随机验证了几个MPA发现都能指向数据区,而程序解释MAP的方式也都没有问题。就在我百思不得其解的时候,我突然想到Isilon这么高端的存储不可能没有文件稀疏吧!否则空间得浪费多少啊!立马根据数据MAP验证了一下,发现文件果然是稀疏的。

    修改代码,重新导出刚才的vmdk,这次vmdk大小符合实际大小,且MFT的位置也在相应位置。手工伪造一个MBR,分区表以及DBR,再用北亚开发的文件系统解释工具成功解释其文件系统,导出vmdk里面的数据库及视频文件。

    在验证了此vmdk中的数据库及视频文件没问题后,批量导出所有重要的vmdk文件,再手工一个一个的去修改每个vmdk文件。

wKiom1XgEePjHbUXAAKq8CwJu_Q438.jpg

【数据验收】

    将客户所有重要的数据恢复完成后,由客户方安排工程师对恢复的所有数据做完整性及准确性检测,经过长达1天的验证工作。数据最终确定完全没有问题,数据恢复成功。

【数据恢复总结】

    整个恢复过程耗时一个月,虽然过程很曲折,但是结果很满意。










本文转自 张宇 51CTO博客,原文链接:http://blog.51cto.com/zhangyu/1689331,如需转载请自行联系原作者
目录
相关文章
|
7月前
|
存储 算法 数据挖掘
NetApp数据恢复—NetApp存储中虚拟机的数据恢复案例
NetApp存储数据恢复环境: 北京某公司的一台NetApp某型号存储,通过96块磁盘组建了两组存储池,这2组存储池互为镜像。存储池内划分卷并映射到ESXI作为数据存储使用,卷内有几百台虚拟机。 NetApp存储故障: 操作过程中由于未知原因导致卷丢失,卷内虚拟机无法访问。管理员对该NetApp存储进行检查并试图恢复数据但是没有成功,于是联系我们数据恢复中心恢复数据。
NetApp数据恢复—NetApp存储中虚拟机的数据恢复案例
|
7月前
|
存储 运维 Oracle
【NetApp数据恢复】NetApp存储卷被误删除的数据恢复案例
NetApp数据恢复环境: NetApp某型号存储,存储中有数十块SAS硬盘,该型号NetApp存储硬盘是扇区大小是520字节。存储中的lun都映射给小型机使用,存放Oracle数据库文件,采用ASM裸设备存储方式。 NetApp存储故障: 由于业务发展需要重新规划存储空间,工作人员直接将存储卷全部删除并重新分配。当删除卷还没有开始重新分配的时候,上层业务宕机,运维工程师紧急排查故障情况,发现业务服务器上的磁盘都消失了,无法访问数据。
【NetApp数据恢复】NetApp存储卷被误删除的数据恢复案例
|
存储 运维 数据库
XSAN数据恢复-昆腾存储XSAN数据恢复案例
XSAN数据恢复环境: 昆腾存储,MAC OS操作系统,存放视频类数据(MXF、MOV等格式文件)。 XSAN故障&检测: 将存储空间从XSAN架构迁移到STORNEXT架构后,存储空间中数据全部丢失。 故障存储中一共有9个数据卷:1个META信息卷+8个DATA信息卷。北亚企安数据恢复工程师分析META信息卷&读取其中的元信息,初步判断数据丢失的原因是在迁移存储空间的时候,工作人员误将整个存储系统格式化,导致全部数据丢失。
XSAN数据恢复-昆腾存储XSAN数据恢复案例
|
存储 Unix 数据挖掘
Netapp数据恢复—Netapp存储误删除lun的数据恢复案例
Netapp存储数据恢复环境: 北京某公司一台netAPP存储,72块SAS硬盘划分了若干个lun。 Netapp存储故障: 工作人员误操作删除了12个lun。
Netapp数据恢复—Netapp存储误删除lun的数据恢复案例
|
5月前
|
存储 运维 数据挖掘
服务器数据恢复—IBM V7000数据恢复案例
服务器存储数据恢复环境: 某品牌P740小型机+AIX+Sybase+V7000磁盘阵列柜,磁盘阵列柜中有12块SAS机械硬盘(其中包括一块热备盘)。 服务器存储故障: 磁盘阵列柜中有一块磁盘出现故障,运维人员用新硬盘替换掉故障盘并开始同步数据。当数据同步的进度不到一半的时候,磁盘阵列柜中另一个磁盘也出现了问题,导致逻辑盘无法挂接在小型机上,业务中断。通过存储的管理界面查看,发现两块硬盘显示故障脱机,其中10号槽位故障硬盘为热备盘。 磁盘阵列柜中一共创建了2组Mdisk,加到一个pool中,现在的故障表现是主要的数据pool无法加载,部分通用卷均无法挂载。
服务器数据恢复—IBM V7000数据恢复案例
|
6月前
|
存储 数据挖掘 数据库
服务器数据恢复—EMC Isilon存储数据恢复案例
服务器存储数据恢复环境: EMC Isilon S200集群存储,共三个节点,每节点配置12块SATA硬盘。 服务器存储故障: 工作人员误操作删除虚拟机,虚拟机中数据包括数据库、MP4、AS、TS类型的视频文件等。需要恢复数据的虚拟机通过NFS协议共享到ESX主机,视频文件通过CIFS协议共享给虚拟机(WEB服务器)。 通过NFS协议共享的所有数据(虚拟机)被删除,而通过CIFS协议共享的数据没有被删除。
服务器数据恢复—EMC Isilon存储数据恢复案例
|
2月前
|
存储 数据挖掘 索引
NetApp数据恢复—NetApp存储中RAID数据恢复案例
NetApp某型号存储,WAFL文件系统。 工作人员误操作将该NetApp存储中的重要数据删除。
|
3月前
|
存储 数据挖掘 索引
NetApp数据恢复—NetApp存储误删除数据恢复案例
NetAapp某型号存储,WAFL文件系统。工作人员误操作将NetApp存储中重要数据删除。
|
7月前
|
存储 运维 Oracle
Netapp数据恢复—Netapp存储中lun被误删除的数据恢复案例
NetApp存储数据恢复环境: NetApp FAS某型号存储,该NetApp存储中有96块扇区大小是520字节的SAS硬盘。存储中的lun都映射给小型机使用,存放Oracle数据库文件,采用ASM裸设备存储方式。 NetApp存储故障: 工作人员误操作删除了该NetApp存储上所有lun。 和工作人员沟通后得知:由于业务需要,需要重新规划该NetApp存储的存储空间,工作人员直接把存储卷全部删除并重新分配。在完成卷的删除但还没有重新分配的时候,上层业务宕机。运维工程师紧急排查故障情况,发现跑业务的服务器上的磁盘都“消失”了,无法访问数据。
 Netapp数据恢复—Netapp存储中lun被误删除的数据恢复案例
|
7月前
|
存储 Unix 数据挖掘
【Netapp数据恢复】Netapp存储误删除lun的数据恢复案例
某单位一台Netapp存储,该Netapp存储内共有数十块SAS硬盘。 工作人员误操作删除了Netapp存储中12个lun,删除的数据包括客户信息和其他重要数据。
【Netapp数据恢复】Netapp存储误删除lun的数据恢复案例