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