服务器数据恢复—如何让ZFS文件系统数据“起死回生”？

服务器数据恢复环境&故障：
一台配有32块硬盘的服务器在运行过程中突然崩溃不可用。经过初步检测，基本上确定服务器硬件不存在物理故障。管理员重启服务器后问题依旧。需要恢复该服务器中的数据。

服务器数据恢复环境：
1、将服务器中硬盘做好标记后取出，硬件工程师检测后没有发现有硬盘存在硬件故障，都可以正常读取。使用专业工具对所有硬盘进行扇区级全盘镜像。镜像完成后按照原样将所有硬盘还原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，避免对原始磁盘数据造成二次破坏。
2、基于镜像文件分析所有磁盘底层数据。通过分析获取到和故障服务器有关的信息：服务器通过zfs文件系统管理所有磁盘。服务器中的32块硬盘共创建了4组raidz阵列。两组raidz阵列硬盘离线后都启用了热备盘，热备盘上线后这两组raidz阵列中又有硬盘离线。
3、ZFS管理的存储池与常规存储池有所不同。常规RAID阵列存储数据，按照特定的规则组建池，不关心文件在子设备上的位置。ZFS存储数据会为每次写入的数据分配适当大小的空间，并计算出指向子设备的数据指针。ZFS的这种特性导致RAIDZ阵列在缺盘时无法直接通过校验得到数据，而是需要将整个ZPOOL作为整体进行解析。
4、手工截取事务块数据，数据恢复工程师编写程序获取最大事务号入口。
获取文件系统入口：

北亚企安数据恢复—zfs文件系统数据恢复

5、获取到文件系统入口后，北亚企安数据恢复工程师编写数据指针解析程序解析地址。
解析数据指针：

北亚企安数据恢复—zfs文件系统数据恢复

6、获取到文件系统入口点在各磁盘分布情况后，北亚企安数据恢复工程师手工截取并分析文件系统内部结构。由于入口点所在的磁盘组无缺失盘，可直接提取数据。根据ZFS文件系统的数据存储结构顺利找到映射的LUN名称，进而找到其节点。
7、分析后发现在本案例中的ZFS版本与开源版本有较大差别，无法使用已开发的解析程序进行解析。于是数据恢复工程师重新编写了数据提取程序。

北亚企安数据恢复—zfs文件系统数据恢复

8、由于磁盘组内缺盘个数较多，每个IO流都需要通过校验得到，恢复数据的速度极为缓慢。与用户方沟通后得知，此ZVOL卷映射到XenServer作为存储设备。用户方所需的文件在其中一个vhd内。提取ZVOL卷头部信息，按照XenStore卷存储结构进行分析，发现该vhd在整个卷的尾部，计算得到其起始位置后从此位置开始提取数据。
9、Vhd提取完成后，验证其内部的压缩包、图片、视频等文件，均可正常打开。
10、用户方验证数据后，确定文件数量与系统自动记录的文件个数相差无几。出现文件数量出入的原因应该是这些没有恢复出来的文件是最新生成的，还未存放到磁盘。验证文件的可用性，文件全部可正常打开。用户方认可数据恢复结果。

审核编辑 黄宇