ITPub博客

首页 > IT基础架构 > 服务器/存储 > 【服务器数据恢复】ZFS文件系统下RAIDZ多块硬盘离线的数据恢复案例

【服务器数据恢复】ZFS文件系统下RAIDZ多块硬盘离线的数据恢复案例

原创 服务器/存储 作者:北亚数据恢复 时间:2023-02-20 11:31:53 0 删除 编辑

服务器数据恢复环境:

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提取完毕后,验证其内部的压缩包、图片和视频等文件,均可正常打开。联系用户亲自验证数据,经过反复验证后确

定文件数量与系统自动记录的文件数量相差无几,缺失的那部分极少数量的文件可能因为是最新生成还未刷新到磁盘。验证

文件可用性,文件全部可正常打开,本次数据恢复工作完成。


来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/31380569/viewspace-2935939/ ,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
从事服务器数据恢复、磁盘阵列数据恢(DEll、HP、IBM、华为、NetApp等),虚拟化数据恢复(VSAN、VMware、Kvm等),数据库数据恢复(Oracle、Sql Server、MySql、Mongodb等),小型机数据恢复等方面的。24h数据救援13439392933

注册时间:2016-08-02

  • 博文量
    1127
  • 访问量
    876602