遇到ZFS文件系统如此棘手的问题，这种办法简单又高效！

Posted 2021-11-29

一、ZFS文件系统

ZFS是一款128bit文件系统，总容量是现有64bit文件系统的1.84x10^19倍，其支持的单个存储卷容量达到16EiB（2^64byte，即 16x1024x1024TB）；一个zpool存储池可以拥有2^64个卷，总容量最大256ZiB（2^78byte）；整个系统又可以拥有2^64个存储 池。可以说在相当长的未来时间内，ZFS几乎不太可能出现存储空间不足的问题。另外，它还拥有自优化，自动校验数据完整性，存储池/卷系统易管理等诸多优点。较ext3系统有较大运行速率，提高大约30%-40%。

二、存储环境部署：

用户所使用存储设备型号为ORACLE-SUN-ZFS7320，共使用40块磁盘组建存储池，其中四块磁盘作为全局热备。池内划分出若干空间映射到服务器使用，服务器操作系统为Windows。

三、故障情况：

在使用过程中进行文件迁移时存储突然发生故障，无法读取数据。设备管理界面报错如图所示：

四、用户所需数据：

恢复映射到windows服务器的其中一个大小为12T LUN中的丢失数据。在了解到上述情况后，开始制定恢复方案。

五、磁盘镜像

为防止对客户原始磁盘内数据造成破坏，首先分别对各磁盘进行镜像拷贝。拷贝过程中发现有两块磁盘内有物理坏道无法生成镜像，对其进行标注。

六、分析磁盘底层数据

获取到磁盘镜像后进行分析，发现其采用ZFS文件系统管理所有磁盘。但磁盘内记录系统元信息的NVLIST较为混乱，只能粗略得出以下信息：

1、磁盘被分为三组，每组12块.

2、单个组内使用ZFS特有的RAIDZ管理所有磁盘.

3、RAIDZ级别为2,即每个组内可缺失磁盘个数最大为2.

4、全局热备全部启用.
七、故障推测
在ZFS文件系统中，池被称为ZPOOL。ZPOOL的子设备可以有很多种类，包括块设备、文件、磁盘等等，在本案例中所采用的是其中的一种------三组RAIDZ作为子设备。
经过分析发现，三组RAIDZ内有两组分别启用热备盘个数为1和3。在启用热备盘后，第一组内仍出现一块离线盘，第二组内则出现两块。以此进行故障现场模拟：三组RAIDZ内第一二组分别出现离线盘，热备盘及时进行替换；热备盘无冗余状态下第一组出现一块离线盘，第二组出现两块离线盘，ZPOOL进入高负荷状态（每次读取数据都需要进行校验得到正确数据）；第二组内出现第三块离线盘，RAIDZ崩溃，ZPOOL下线。
八、ZPOOL重组
ZFS管理的存储池与常规存储不同，所有磁盘都由ZFS进行管理。常规RAID在存储数据时，只按照特定的规则组建池，不关心文件在子设备上的位置。而ZFS在数据存储时会为每次写入的数据分配适当大小的空间，并计算得到指向子设备的数据指针。这种特性使得RAIDZ缺盘时无法直接进行校验得到数据，必须将整个ZPOOL作为一个整体进行解析。
九、追踪最新数据入口
在ZFS文件系统内每次发生文件系统状态更新时都会产生新的文件系统入口，所以需要根据其内部记录的事务块获取最新状态下的入口指针。手工截取事务块数据，编写程序获取最大事务号入口：

获取到最新状态的文件系统入口后，编写数据指针解析程序进行地址解析：

获取到文件系统入口点在各磁盘分布情况后，开始手工截取并分析文件系统内部结构，入口分布所在的磁盘组无缺失盘，可直接提取信息。根据ZFS文件系统的数据存储结构顺利找到客户映射的LUN名称，进而找到其节点。
十、运行提取程序
编辑配置文件，提取ZVOL卷：

由于磁盘组内缺盘个数较多，每个IO流都需要通过PQ校验得到，提取进度极为缓慢。与客户沟通后得知，此ZVOL卷映射到XenServer作为存储设备，客户所需的文件在其中一个大小约为1.8T的vhd内。提取ZVOL卷头部信息，按照XenStore卷存储结构进行分析，发现1.8Tvhd在整个卷的尾部，计算得到其起始位置后从此位置开始提取数据。
十一、验证数据完整性
Vhd提取完毕后，对其内部的压缩包及图片、视频等文件进行验证，均可正常打开。经用户验证数据，确定文件数量与系统自动记录的文件个数所差无几，丢失文件可能是最新生成还未刷新到磁盘。验证文件可用性，文件可正常打开，验收完成，至此数据恢复工作结束。