共计 1275 个字符，预计需要花费 4 分钟才能阅读完成。
服务器数据恢复环境：
北京某公司的 EMC NAS，总共有 3 个节点，每个节点配置 12 块 STAT 硬盘。
NAS 中寄存有 vmware 虚拟机（WEB 服务器）和视频文件。
虚拟机通过 NFS 协定共享到 ESX 主机，视频文件通过 CIFS 协定共享给虚拟机（WEB 服务器）。
服务器故障：
因为工作人员误操作将包含 MSSQL 数据库，大量 MP4、ASF 和 TS 格局的视频文件删除。NFS 共享的所有数据（虚拟机）被删除而 CIFS 共享的数据则没有被删除。
服务器数据恢复过程：
1、对故障存储中所有硬盘以只读形式进行全盘镜像。后续的数据分析和数据恢复操作都基于镜像进行，防止对原始数据造成二次毁坏。
2、基于镜像文件剖析所有硬盘中的数据。因为数据是被人为删除的，须要剖析文件被删除后，文件的 Indoe 及数据 MAP 是否发生变化。
3、因为被删除的虚构磁盘文件大小都在 64G 或者以上，而且存储中没有其余类型的、文件大小超过 64G 的大文件。北亚企安数据恢复工程师编写 Indoe 扫描程序，将大小合乎 64G 或以上的文件的 Indoe 都扫描进去。
4、剖析扫描进去的 Indoe，找出数据 MAP 地位，其 index 指向的内容不是失常数据，并且所有节点上的 Indoe 均是同样的状况。
5、剖析 Inode，发现大文件的数据 MAP 会有多层（树结构）, 并且数据 MAP 中会记录文件的惟一 ID，因而能够尝试找到文件底层的数据 MAP。
6、对文件底层的数据 MAP 做遍历跟踪操作后发现底层的数据 MAP 果然还在。
7、从文件的 Inode 取出文件的惟一 ID，聚合所有合乎该 ID 的数据 MAP。依据数据 MAP 中的 VCN 号排序，发现每个文件的前 17088 项数据 MAP 都不存在，这意味着每个文件的前 17088 项数据没法复原。
8、通过换算发现失落的数据 MAP 项总共蕴含不到 1G 的数据，而删除的文件全是虚拟机的 vmdk 文件, 外部采纳的 NTFS 文件系统，而 NTFS 文件系统的 MFT 根本都在 3G 的地位，也就是只须要在每个 vmdk 文件的头部手动伪造一个 MBR 和 DBR 就能够解释 vmdk 外面的数据。
9、解释扫描到的数据 MAP，依据 VCN 号的程序导出数据，没有 MAP 的状况就保留为零。通过一直的测试，尝试导出一个 vmdk 文件，发现导出的 vmdk 文件比理论状况要小，并且 vmdk 中 MFT 的地位也与本身形容不符。
10、随机验证几个 MAP 发现都能指向数据区，程序解释 MAP 的形式也都没有发现问题。所以初步判断呈现这种状况的起因可能是文件稠密。
11、调整代码后从新导出方才的 vmdk 文件，这次 vmdk 文件大小符合实际，且 MFT 的地位正确。手工伪造一个 MBR、分区表以及 DBR，应用北亚企安自主开发的文件系统解释程序胜利解释其文件系统，导出该 vmdk 文件里的数据库及视频文件。
12、验证此 vmdk 中的数据库及视频文件没有问题后，批量导出所有的 vmdk 文件，再手工批改每个 vmdk 文件。直至复原出所有用户须要的数据。
服务器数据验证：
将所有重要数据恢复实现后，由用户方安顿工程师对复原进去的数据做完整性及准确性验证。通过重复验证测试，用户方确认数据残缺无效。本次数据恢复工作实现。
