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

【故障描述】

某大学因黑客入侵，导致其“教学系统”的重要数据被删除。其中包括“教学系统”中的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正常关机。再将所有节点上的所有硬盘贴上标签，并依次取出再放到北亚提供的数据恢复平台中，开始分析所有硬盘中的数据。

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

由于客户数据是被删除了，因此不用过多考虑存储的冗余级别，重点需要分析文件删除后，文件Indoe及数据MAP是否发生变化。和客户沟通后，删除的虚拟磁盘文件都在64G或以上，并且存储中没有其他类型的大文件。编写扫描所有文件Indoe的程序，将文件大小符合64G或以上的Indoe都扫描出来。再仔细分析扫描出来的Indoe，发现Indoe中记录的数据MAP位置，其index指向的内容已不再是正常数据，并且所有节点上的Indoe均是同样的情况。再仔细分析Inode，发现大文件的数据MAP会有多层（树结构）,并且数据MAP中会记录文件的唯一ID，因此可以尝试找到文件最底层的数据MAP。抱着侥幸心理对文件最底层的数据MAP做遍历跟踪操作，发现最低层的数据MAP果然还在。

【数据恢复分析步骤】

1、编写程序，从文件的Inode中取出文件的唯一ID，然后对所有符合该ID的数据MAP做聚合。并根据数据MAP中的VCN号做排序，发现每个文件的前17088项数据MAP都不存在，也就意味着每个文件的前17088项数据是真的没办法恢复了（心情一下跌落低谷）。

2、仔细换算了一下发现丢失的数据MAP项总共才包含不到1G的数据，而删除的文件全是虚拟机的vmdk文件，里面都是NTFS的文件系统，而NTFS文件系统的MFT基本都在3G的位置，也就是只需要在每个vmdk文件的头部手动伪造一个MBR和DBR就可以解释vmdk里面的数据了（真不知到是巧合呢！还是巧合呢！）。赶紧编写代码，对扫描到的数据MAP做解释，并根据VCN号的顺序导出数据，没有MAP的情况保留为零。

3、经过不断的测试，程序终于编好了，先导出一个vmdk文件来看看。结果令我大吃一惊，导出的vmdk文件比实际情况要小，并且vmdk中MFT的位置也与自身描述不符。是程序的问题？还是数据MAP本身已损坏？手动随机验证了几个MPA发现都能指向数据区，而程序解释MAP的方式也都没有问题。就在我百思不得其解的时候，我突然想到Isilon这么高端的存储不可能没有文件稀疏吧！否则空间得浪费多少啊！立马根据数据MAP验证了一下，发现文件果然是稀疏的。

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

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

【数据验收】

整个恢复过程耗时较长，虽然在恢复研究过程中遇到了一些问题，但是好在数据可以正常恢复。将客户所有重要的数据恢复完成后，由客户方安排工程师对恢复的所有数据做完整性及准确性检测，经过长达1天的验证工作。数据最终确定完全没有问题，至此数据恢复成功。

EMC Isilon(OneFS)数据恢复案例详解相关推荐

ibm v7000配置文档_IBM_V7000底层结构及服务器数据恢复案例详解
[IBM原理详解] IBM_V7000(全名IBM Storwize V7000)是IBM推出的新一代中端存储系统,尽管定位中端,Storwize V7000却提供了以往高端存储才具备的强大存储管理功 ...
python代码案例详解-我用Python抓取了7000 多本电子书案例详解
安装安装很简单,只要执行: pip install requests-html 就可以了. 分析页面结构通过浏览器审查元素可以发现这个电子书网站是用 WordPress 搭建的,首页列表元素很简单 ...
python代码案例详解-第7.20节案例详解：Python抽象类之真实子类
第7.20节案例详解:Python抽象类之真实子类上节介绍了Python抽象基类相关概念,并介绍了抽象基类实现真实子类的步骤和语法,本节结合一个案例进一步详细介绍. 一. 案例说明本节定义了图形 ...
java同步方法完成案例_Java同步代码块和同步方法原理与应用案例详解
本文实例讲述了java同步代码块和同步方法.分享给大家供大家参考,具体如下: 一点睛所谓原子性WOmoad:一段代码要么执行,要么不执行,不存在执行一部分被中断的情况.言外之意是这段代码就像原子一 ...
《微信小程序：开发入门及案例详解》—— 3.4 小结
本节书摘来自华章出版社<微信小程序:开发入门及案例详解>一书中的第3章,第3.4节,作者李骏边思,更多章节内容可以访问云栖社区"华章计算机"公众号查看. 3.4 小 ...
代码检查规则：Python语言案例详解
在之前的文章中代码检查规则:Java语言案例详解学习了Java的检查规则.我们今天将学习<代码检查规则:Python语言案例详解>,内容主要分为两个部分:Python的代码检查规则和Pyt ...
代码检查规则：Java语言案例详解
本节课程为<代码检查规则:Java语言案例详解>, 通常情况下Java的代码检查规则可以分为以下十类: 接下来,让我们具体来看看每个分类的内容. 一.源文件规范该类规范主要从文件名.文件 ...
python装饰器setter_第7.27节 Python案例详解： @property装饰器定义属性访问方法getter、setter、deleter...
上节详细介绍了利用@property装饰器定义属性的语法,本节通过具体案例来进一步说明. 一. 案例说明本节的案例是定义Rectangle(长方形)类,为了说明问题,除构造函数外,其他方法都只 ...
Ajax基本案例详解之load的实现
Ajax的load实现: 看这篇之前建议大家去看看前面两篇文章: 1.Ajax基本案例详解之$.ajax的实现 2.Ajax基本案例详解之$.get的实现现在写一下$.load()里面的主要内容: ...
Ajax基本案例详解之$.getjson的实现
Ajax的$.gethson实现: 看这篇之前建议大家去看看前面两篇文章: 1.Ajax基本案例详解之$.ajax的实现 2.Ajax基本案例详解之$.get的实现现在写一下$.getjson里面的 ...

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

EMC Isilon(OneFS)数据恢复案例详解相关推荐

最新文章

热门文章