服务器数据恢复环境：
北京某公司的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。
北亚企业安全数据恢复-vmware虚拟机数据恢复
4、分析扫描到的Indoe，找出数据MAP的位置。 它的索引指向的内容不是普通数据，所有节点上的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文件。 直到用户需要的数据全部恢复。
服务器数据验证：
所有重要数据恢复后，用户将安排工程师验证恢复数据的完整性和准确性。 经过反复验证和测试，用户确认数据完整有效。 至此数据恢复工作完成。
北亚企业安全数据恢复
