Chinaunix首页 | 论坛 | 博客
  • 博客访问: 356712
  • 博文数量: 609
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 6125
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-02 14:16
文章分类

全部博文(609)

文章存档

2024年(174)

2023年(218)

2022年(181)

2020年(12)

2019年(24)

我的朋友

分类: 服务器与存储

2024-12-19 13:21:05

服务器存储数据恢复环境:
ZFS Storage 7320存储阵列中有32块硬盘。32块硬盘分为4组,每组8块硬盘,共组建了3组RAIDZ,每组raid都配置了热备盘。

服务器存储故障:
服务器存储运行过程中突然崩溃,排除人为误操作、断电、进水和其他机房不稳定因素。管理员重启服务器存储,系统无法进入,需要恢复服务器存储中的数据。

服务器存储数据恢复过程:
1、将故障服务器存储中所有硬盘标记后取出,以只读方式进行扇区级完整镜像,镜像完成后将所有磁盘按照原样还原到原存储中,后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。
2、基于镜像文件分析所有硬盘中的底层数据,发现服务器存储中的热备盘全部启用,上层采用ZFS文件系统。
Tips:
在ZFS文件系统中,存储池被称为ZPOOL。ZPOOL可以有各种类别的子设备:块设备、文件、磁盘等等。本案例中ZPOOL的子设备是三组RAIDZ作为子设备。
经过对底层数据的分析发现,三组RAIDZ中的两组RAIDZ启用的热备盘的个数分别为1和3。启用热备盘后,{BANNED}中国第一组RAIDZ中又有一块盘离线,第二组RAIDZ中则又有两块硬盘离线。
根据上述分析结果模拟故障现场:三组RAIDZ中的两组RAIDZ出现硬盘离线的情况,热备盘自动上线替换离线盘。在热备盘无冗余的情况下{BANNED}中国第一组RAIDZ中又有一块盘离线,第二组RAIDZ中则有两块盘离线,ZPOOL进入高负荷状态(每次读取数据都需要校验);当第二组RAIDZ中出现第三块离线盘的时候,该组RAIDZ崩溃,ZPOOL下线,服务器存储崩溃。
3、ZFS管理的存储池与常规存储池不同。在ZFS文件系统下,ZFS管理所有磁盘。常规RAID在存储数据时会按照特定的规则组建池,并不关心文件在子设备上的位置。在ZFS下,存储数据时会为每次写入的数据分配适当大小的空间,并计算出指向子设备的数据指针。所以RAIDZ缺盘时无法直接通过校验得到数据,必须将整个ZPOOL作为一个整体进行解析。
4、北亚企安数据恢复工程师手工截取事务块数据,并编写程序获取{BANNED}最佳大事务号入口。
获取文件系统入口:

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

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

8、由于缺盘个数较多,每个IO流都需要通过校验得到,进度极为缓慢。与用户方沟通后得知此ZVOL卷映射到XenServer作为存储设备,所需要的文件在一个vhd内。提取ZVOL卷头部信息,按照XenStore卷存储结构进行分析,发现该vhd在整个卷的尾部。计算出其起始位置后从此位置开始提取数据。
9、Vhd提取完毕后,验证其内部的压缩包、图片、视频等文件,均可正常打开。
10、交由用户方验证恢复出来的数据。经过验证,发现恢复出来的文件数量与系统自动记录的文件数量差不多,稍微有点出入。丢失的极少量文件应该是因为这些文件是新生成的还未存储到磁盘。随机验证恢复出来的文件,全部可正常打开。用户方认可数据恢复结果。
阅读(4) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~