共计 1465 个字符，预计需要花费 4 分钟才能阅读完成。
服务器数据恢复环境：
SUN ZFS 系列某型号存储阵列；
40 块磁盘组建的存储池（其中 4 块磁盘用作全局热备盘），池内划分出若干空间映射到服务器应用；
服务器应用 Windows 操作系统。
服务器故障：
服务器在工作时因为未知起因解体，排除断电、进水或者误操作等内部因素。管理员重启服务器后发现无奈进入零碎，须要复原该存储内的所有数据。
服务器数据恢复过程：
1、对故障存储中所有硬盘以只读形式做镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。
2、剖析磁盘镜像，发现故障设施是通过 ZFS 文件系统来治理所有磁盘。磁盘内记录零碎元信息的 NVLIST 较为凌乱，只能粗略得悉以下信息：故障存储中的磁盘被分为三组，每组 12 块；每个组应用 ZFS 文件系统独有的 RAIDZ 治理磁盘。RAIDZ 级别为 2，即每个组最多可缺失 2 块磁盘；故障存储内的 4 块全局热备全副启用。
Tips：ZFS 文件系统中的池被称为 ZPOOL。ZPOOL 的子设施能够有很多类型：块设施、文件、磁盘等等。本案例中所采纳三组 RAIDZ 作为子设施。
3、通过进一步剖析，发现三组 RAIDZ 内有两组别离启用的热备盘个数为 1 和 3。在热备盘启用后，第一组内又呈现一块离线盘，第二组内则又呈现两块离线盘。通过下面剖析失去的论断能够模仿故障现场：三组 RAIDZ 中的第一组和第二组别离呈现离线盘，热备盘及时进行替换；在热备盘无冗余的状态下第一组 RAIDZ 又呈现一块离线盘，第二组 RAIDZ 则又呈现两块离线盘，ZPOOL 进入高负荷状态（每次读取数据都须要通过校验能力失去正确数据）。当第二组 RAIDZ 呈现了第三块离线盘时候，RAIDZ 解体、ZPOOL 下线、服务器解体。
4、因为 ZFS 文件系统治理的存储池与惯例存储不同。惯例 RAID 在存储数据时只会依照特定的规定组建池，不关怀文件在子设施上的地位。而 ZFS 文件系统在存储数据时会为每次写入的数据调配适当大小的空间，并计算出指向子设施的数据指针。ZFS 文件系统的这种个性决定了 RAIDZ 缺盘时无奈间接通过校验失去数据，必须将整个 ZPOOL 作为一个整体进行解析。于是，北亚企安数据恢复工程师手工截取事务块数据，并编写程序获取最大事务号入口。
获取文件系统入口：
获取到文件系统入口后，北亚企安数据恢复工程师编写数据指针解析程序进行地址解析。
解析数据指针：
获取到文件系统入口点在各磁盘的散布状况后，数据恢复工程师开始手工截取并剖析文件系统内部结构。因为入口散布所在的磁盘组无缺失盘，可间接提取信息。依据 ZFS 文件系统的数据存储构造找到用户映射的 LUN 名称，进而找到其节点。
5、通过剖析发现故障存储中的 ZFS 文件系统版本与开源版本有很大差异，无奈应用之前开发的解析程序进行解析，所以北亚企安数据恢复工程师从新编写了数据提取程序提取数据。
6、因为磁盘组内缺盘个数较多，每个 IO 流都须要通过校验失去，所以提取进度极为迟缓。与用户沟通后得悉，此 ZVOL 卷映射到 XenServer 作为存储设备，用户所需的文件在其中一个大小约为 2T 的 vhd 内。提取 ZVOL 卷头部信息，依照 XenStore 卷存储构造进行剖析，发现这个 2T 的 vhd 在整个卷的尾部，计算其起始地位后从此地位开始提取数据。
7、Vhd 提取结束后，验证其外部的压缩包、图片和视频等文件，均可失常关上。分割用户亲自验证数据，通过重复验证后确定文件数量与零碎自动记录的文件数量相差无几，缺失的那局部极少数量的文件可能因为是最新生成还未刷新到磁盘。验证文件可用性，文件全副可失常关上，本次数据恢复工作实现。
