共计 1186 个字符，预计需要花费 3 分钟才能阅读完成。
服务器数据恢复环境：
一台服务器共装备 32 块硬盘，组建了 4 组 RAIDZ，Windows 操作系统 +zfs 文件系统。
服务器故障：
服务器在运行过程中忽然解体，通过初步检测检测没有发现服务器存在物理故障，重启服务器后故障仍旧，须要复原服务器内的大量数据。
通过北亚企安数据恢复工程师的初步检测，发现故障服务器中 4 组 raidz 里有两组 raidz 中的热备盘启动。其中第一组 raidz 启用了一块热备盘，之后又有一块硬盘掉线；第二组 raidz 第一块磁盘离线后又有 2 块硬盘掉线，总共启用了三块热备盘。
这两组 raidz 中硬盘离线后均启用了热备盘替换坏盘，热备盘上线后这 2 组 raidz 中又呈现其余硬盘离线的状况。为了失去正确数据，zpool 在每次读取数据时都会进行校验。第二组 raidz 热备盘上线后又有硬盘离线，服务器彻底解体。
服务器数据恢复过程：
1、将故障服务器中所有磁盘编号后取出，以只读形式将所有磁盘做全盘镜像，镜像实现后将所有磁盘依照编号还原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。
2、ZFS 治理的存储池与惯例 RAID 不同。惯例 RAID 在存储数据时会依照特定的规定组建存储池，并不思考文件在子设施上的地位；而 ZFS 在存储数据时会为每次写入的数据调配适当大小的空间，通过计算获取指向子设施的数据指针。ZFS 的这种个性让 RAIDZ 在缺盘时无奈间接进行校验失去数据，必须将整个 ZPOOL 作为一个整体进行解析。
3、手工截取事务块数据，北亚企安数据恢复工程师编写程序获取最大事务号入口。
获取文件系统入口：
4、获取到文件系统入口后，北亚企安数据恢复工程师编写数据指针解析程序进行地址解析。
解析数据指针：
5、获取到文件系统入口点在各磁盘散布状况后，数据恢复工程师手工截取 & 剖析文件系统内部结构。入口散布所在的磁盘组无缺失盘，可间接提取信息。依据 ZFS 文件系统的数据存储构造顺利找到映射的 LUN 名称，进而找到其节点。
6、因为在此 ZFS 版本与开源版本有较大差异，无奈应用原先开发的解析程序进行解析，所以数据恢复工程师只能从新编写数据提取程序。
7、因为磁盘组内缺盘个数较多，每个 IO 流都须要通过校验失去，提取进度极为迟缓。与用户方沟通后得悉此 ZVOL 卷映射到 XenServer 作为存储设备，用户需的文件在其中一个大小约为 2T 的 vhd 内。提取 ZVOL 卷头部信息，依照 XenStore 卷存储构造进行剖析，发现 2T vhd 在整个卷的尾部，计算失去其起始地位，从起始地位开始提取数据。
8、Vhd 提取结束后，对其外部的压缩包、图片、视频等文件进行验证，均可失常关上。
9、用户发通过验证后，确定复原进去的文件数量与零碎自动记录的文件数量差不多，极小局部失落的文件可能是因为这些文件是新生成的还未刷新到磁盘。用户验证文件的可用性，文件全副可失常关上，本次数据恢复工作实现。
