服务器数据恢复环境：
EMC 服务器，采纳 NAS（Isilon S 系列存储）；
共三个节点，每一节点配置 12 块 SATA 接口、单盘容量为 3T 的硬盘。
服务器故障：
管理员误删除虚拟机，被误删除的虚拟机中存储的是数据库、MP4、AS、TS 类型的视频文件等。被误删除的虚拟机是通过 NFS 协定共享到 ESX 主机，视频文件通过 CIFS 协定共享给虚拟机（WEB 服务器），NFS 共享的所有数据（虚拟机）被删除而 CIFS 共享的数据则没有被删除。管理员分割咱们数据恢复核心进行数据恢复。
服务器数据恢复过程：
1、将所有硬盘进行备份。
2、服务器数据备份实现后在 Isilon 的 web 治理界面中将 Isilon 失常关机。将备份好的服务器数据放到北亚数据恢复平台中对数据进行剖析。
3、本案例服务器数据失落的起因是误删除，所以不必过多思考冗余级别，须要重点剖析的是数据删除后 Indoe 及数据 MAP 是否发生变化。
4、因为服务器中被删除的虚构磁盘文件大小都在 64G 或以上，除此之外没有其余大文件。北亚数据恢复工程师编写扫描所有文件 Indoe 的程序，将文件不小于 64G 的 indoe 全副扫描进去。通过对 Indoe 进行扫描找出数据 MAP 地位，发现其 index 指向的内容已不再是失常数据，并且所有节点上的 Indoe 均是同样的状况。
5、再次剖析 Inode，发现大文件的数据 MAP 会有多层（树结构）, 并且数据 MAP 中会记录文件的惟一 ID，数据恢复工程师尝试找到文件最底层的数据 MAP。数据恢复工程师对文件最底层的数据 MAP 做遍历跟踪操作，发现最低层的数据 MAP 还存在。
6、通过文件的 Inode 对文件的惟一 ID 进行提取工作，而后对所有合乎该 ID 的数据 MAP 做聚合。并依据数据 MAP 中的 VCN 号做排序，数据恢复工程师通过剖析发现每个文件的前 17088 项数据 MAP 都不存在，实践上每个文件的前 17088 项数据是无奈复原。
7、通过数据换算确定失落的数据 MAP 项的大小一共不到 1G，删除的文件全是虚拟机的 vmdk 文件，外面都是 NTFS 的文件系统，NTFS 文件系统的 MFT 根本都在 3G 的地位。只须要在每个 vmdk 文件的头部手动伪造一个 MBR 和 DBR 就能够解释 vmdk 外面的数据了。
8、对扫描到的数据 MAP 做解释，并依据 VCN 号的程序导出数据，没有 MAP 的状况保留为零。
9、数据恢复工程师将 vmdk 文件导出，发现文件比理论状况要小、vmdk 中 MFT 的地位也与本身形容不符。手动随机验证了几个 MPA 发现都能指向数据区，而程序解释 MAP 的形式也都没有问题。呈现这种状况的起因可能为文件稠密！
10、北亚数据恢复工程师从新调整了代码再次导出 vmdk，这次导出的数据失常且 MFT 的地位也在相应地位。手工伪造一个 MBR，分区表以及 DBR，再用北亚开发的文件系统解释工具解释文件系统胜利，导出 vmdk 外面的数据库及视频文件。
11、验证 vmdk 中的数据库及视频文件没有发现问题，批量导出所有重要的 vmdk 文件，再手动的去批改每个 vmdk 文件。
服务器数据恢复后果：
将所有重要的数据恢复实现后，由服务器管理员对复原进去的所有数据做完整性及准确性检测，最终确定数据齐全没有问题，数据恢复胜利。