服务器数据恢复—RAIDZ硬盘“惹祸”导致服务器崩溃的数据恢复过程

服务器数据恢复环境&故障：
一台服务器有32块硬盘，采用Windows操作系统。
服务器在正常运行的时候突然变得不可用。没有异常断电、进水、异常操作、机房不稳定等外部因素。服务器管理员重启服务器，但是服务器无法进入系统。管理员联系北亚企安数据恢复工程师要求恢复服务器数据。

服务器数据恢复过程：
1、将故障服务器上所有硬盘做好标记后取出，经过硬件工程师检测后没有发现有硬盘存在硬件故障。将所有硬盘以只读方式进行扇区级完整镜像，镜像完成后将所有硬盘根据标记按照原样还原到原服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行，避免对原始磁盘数据造成二次破坏。
2、基于镜像文件分析所有磁盘底层数据，经过分析发现：故障服务器采用zfs文件系统。所有磁盘组建了几组RAIDZ。热备盘全部启用。
在服务器ZFS文件系统中，池被称为ZPOOL。ZPOOL的子设备可以有很多种类，包括块设备、文件、磁盘等等，本案例中就是三组RAIDZ作为子设备。
经过分析发现，三组RAIDZ中的两组RAIDZ分别启用1个和3个热备盘。热备盘启用后，第一组RAIDZ又有一块盘离线，第二组RAIDZ则有两块硬盘离线。
通过上述分析结果模拟故障：三组RAIDZ中的两组RAIDZ出现离线盘，热备盘自动上线替换。热备盘无冗余状态下，其中一组RAIDZ出现离线硬盘的RAIDZ又有一块盘离线，另外一组RAIDZ中又出现两块离线盘。ZPOOL进入高负荷状态；2块盘离线的RAIDZ中又有第三块盘离线，RAIDZ崩溃、ZPOOL下线、服务器崩溃。
3、重组ZPOOL，追踪数据入口。
ZFS对所有磁盘进行统一管理。在数据存储时，ZFS会为每次写入的数据分配适当大小的空间，并计算得到指向子设备的数据指针。这种精细化的管理方式使得ZFS能够更高效地利用磁盘空间，并且在数据存储和检索时更加灵活和智能。
当出现缺盘情况时，常规RAID和ZFS的处理方式也截然不同。常规RAID通常可以通过校验机制，利用剩余磁盘上的数据来恢复丢失的数据，因为它在存储时已经按照固定的规则分布了校验信息。
但对于ZFS管理的存储池，当RAIDZ（ZFS的一种RAID实现方式）缺盘时，无法直接进行校验得到数据。这是因为ZFS的存储特性使得数据和校验信息的分布更为复杂，必须将整个ZPOOL（ZFS存储池）作为一个整体进行解析，才能尝试恢复数据。这种方式虽然在缺盘恢复时相对复杂，但也保证了数据的完整性和一致性。
北亚企安数据恢复工程师手工截取事务块数据，编写程序获取最大事务号入口。
获取文件系统入口：

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

获取到文件系统入口点在各磁盘分布情况后，数据恢复工程师开始手工截取并分析文件系统内部结构。经过分析发现入口分布所在的磁盘组无缺失盘，可直接提取信息。根据ZFS文件系统的数据存储结构顺利找到映射的LUN名称，进而找到其节点。
4、经过分析发现此存储中的ZFS版本与开源版本有较大差别，无法使用原先开发的解析程序进行解析，所以数据恢复工程师重新编写数据提取程序。

由于磁盘组内缺盘个数较多，每个IO流都需要通过校验得到，提取进度极为缓慢。与用户方沟通后得知，此ZVOL卷映射到XenServer作为存储设备，用户方所需的文件在其中一个vhd内。提取ZVOL卷头部信息，按照XenStore卷存储结构进行分析，发现该vhd在整个卷的尾部，计算得到其起始位置后从此位置开始提取数据。
5、Vhd提取完成后，验证其内部的压缩包及图片、视频等文件，均可正常打开。
交由用户方验证数据，经过验证发现文件数量与系统自动记录的文件个数一致。验证文件可用性，文件全部可正常打开，服务器数据恢复工作完成。