RAIDZ多块磁盘离线导致RAIDZ崩溃的数据恢复案例
最新动态来源：本站原创点击数：299更新时间：2024/1/17
服务器数据恢复环境：
ORACLE SUN ZFS某型号存储，共40块磁盘组建存储池，其中的36块磁盘分为三组，每组12块，单个组使用ZFS特有的RAIDZ管理所有磁盘，RAIDZ级别为2；另外的4块磁盘作为全局热备。存储池内划分出若干空间映射到服务器使用。
服务器故障：
服务器正常运行过程中崩溃，服务器管理员重启设备后无法进入系统。通过对服务器和存储的初步检测以及和管理人员的沟通，排除了断电、进水、异常操作等外部因素。
服务器数据恢复过程：
1、将存储中所有磁盘编号后取出，硬件工程师检测后没有发现有硬盘存在硬件故障。以只读方式将所有磁盘进行扇区级全盘镜像，镜像完成后按照编号将所有磁盘还原到原存储中。后续的数据分析和数据恢复操作都基于镜像文件进行，避免对原始磁盘数据造成二次破坏。
2、基于磁盘镜像文件分析底层数据，发现全局热备盘全部启用。
在ZFS文件系统中，ZPOOL（池）的子设备有很多种类：块设备、文件、磁盘等，本案例中三组RAIDZ作为子设备。
分析底层数据发现，三组RAIDZ中的两组RAIDZ分别启用的热备盘个数为1和3。北亚企安数据恢复工程师基于获取到的信息推断故障过程：热备盘启用后，在热备盘无冗余状态下，第一组RAIDZ中又有一块磁盘离线，第二组RAIDZ中则又有两块磁盘离线，ZPOOL进入高负荷状态；直到第二组RAIDZ中第三块盘离线，RAIDZ崩溃，ZPOOL下线，服务器崩溃。
ZFS管理的存储池中所有磁盘都由ZFS进行管理。常规RAID按照特定的规则组建池，并不关心文件在子设备上的位置；而ZFS会为每次写入的数据分配适当大小的空间，并计算得到指向子设备的数据指针。RAIDZ这种特性导致RAIDZ缺盘时无法直接通过校验得到数据，而必须将整个ZPOOL作为一个整体进行解析。
3、手工截取事务块数据，北亚企安数据恢复工程师编写程序获取最大事务号入口。
获取到文件系统入口后，北亚企安数据恢复工程师编写数据指针解析程序解析地址。
4、获取到文件系统入口点在各磁盘分布情况后，北亚企安数据恢复工程师手动截取&分析文件系统内部结构。由于入口分布所在的磁盘组无缺失盘，可直接提取信息。根据ZFS的数据存储结构顺利找到映射的LUN名称，然后找到其节点。
5、北亚企安数据恢复工程师编写解析程序解析ZFS&提取数据。
6、由于磁盘组内缺盘数目较多，每个IO流都需要通过校验得到，提取进度极为缓慢。通过和用户沟通后得知用户需要恢复的数据在一个vhd内，经过分析发现这个vhd在ZVOL卷的尾部，计算其起始位置后从此位置开始提取数据。
7、Vhd提取完毕后，验证其内部的压缩包、图片、视频等文件，均可正常打开。
8、用户方对数据进行验证，经过验证发现恢复出来的文件数量与系统自动记录的文件数量基本一致，文件全部可以正常打开。本次服务器数据恢复工作完成。