标签：工具 关机 员工 tfs 位置 ilo 工程师 丢失 磁盘
【服务器数据恢复故障描述】北京某公司的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文件。
将客户所有重要的数据恢复完成后，由客户方安排工程师对恢复的所有数据做完整性及准确性检测，数据最终确定完全没有问题，数据恢复成功。
标签：工具 关机 员工 tfs 位置 ilo 工程师 丢失 磁盘
原文地址：http://blog.51cto.com/sun510/2145290
