共计 1252 个字符，预计需要花费 4 分钟才能阅读完成。
服务器数据恢复环境：
一台服务器通过 FreeNAS（本案例应用的是 UFS2 文件系统）实现 iSCSI 存储，整个 UFS2 文件系统作为一个文件挂载到 ESXi 虚拟化零碎（装置在另外 2 台服务器上）上。该虚拟化零碎一共有 5 台虚拟机，其中有 3 台虚拟机中的数据比拟重要：一台虚拟机上部署了 ASP.net+SqlServer 和 PHP+mysql；第二台虚拟机装置的 FreeBSD，部署了 MySQL 数据库；第三台虚拟机寄存的是代码数据。
本案例利用构架档次：FreeNAS(UFS2 文件系统–> 一个大的稠密模式的文件) –> ESXi (VMFS 文件系统层) -> 单台虚拟机的虚构磁盘 (windows-NTFS 文件系统 /FreeBSD-UFS2 文件系统)。
服务器故障：
作为 iSCSI 存储的服务器在失常运行过程中异样断电，重启后虚拟化零碎无奈连贯该服务器，FreeNAS 的 UFS2 文件系统呈现问题，管理员对 UFS2 文件系统进行了修复，然而 ESXI 虚拟化零碎无奈辨认原有的数据和 UFS2 文件系统。
服务器数据恢复过程：
1、对 FreeNAS 层做只读镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止数据恢复操作对原始数据造成二次毁坏。
2、基于镜像文件剖析整个存储，只发现了一个文件名为 iscsidata 的、大小数百 GB 的文件。
3、依据 UFS2 文件系统的二进制构造定位到 iscsidata 文件的 Inode 数据，通过检测发现该文件被重建过，inode 指针指向的数据量很少，在 FreeNAS 层无奈解决问题，所以就无奈进行下一步的 VMFS 层剖析。
4、因为 iscsidata 文件重建过，过程和大小都和原 iscsidata 文件统一，应该有局部指针块被笼罩。原 iscsidata 文件的 inode 和新建的 iscsidata 文件的 inode 在同一个地位，尝试搜寻没有发现其它有用的 inode。
5、北亚企安数据恢复工程师编写程序收集有用的指针块。
因为 iscsidata 文件采纳的稠密模式，放宽收集条件后收集到了大量三级指针块和二级指针块。
6、通过剖析发现所有收集到的三级指针块都是有效的，没有找到 iscsidata 文件应用的三级指针块，应该是在新建 iscsidata 文件时被笼罩。
7、剖析收集到的二级指针块并对大量的二级指针块的指向数据进行 DUMP，而后从磁盘中的数据定位到二级指针。通过这种形式获取到大量 DUMP 的数据。
8、剖析 VMFS 层。因为 VMFS 从新格式化过，原始 UFS2 的指针已失落，所以 VMFS 元文件不可用。
9、通过单台虚拟机层 (windows(NTFS) 和 FreeBSD(UFS2)的文件系统构造)，向上定位到 VMFS 层，而后通过 VMFS 层定位到 DUMP 出的单个 64GB 文件。通过屡次组合，最终将三台重要虚拟机的虚构磁盘完全恢复。将复原出的网页数据和数据库数据上传到筹备好的零碎中，拉起利用并对数据进行检测，没有发现任何问题。
10、通过用户方的认真检测后，确认 3 台重要虚拟机中的数据胜利复原，认可本次数据恢复后果。本次服务器数据恢复工作实现。