服务器数据恢复StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例

Posted 2023-03-22

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了服务器数据恢复StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例相关的知识，希望对你有一定的参考价值。

服务器数据恢复环境：

服务器+10个磁盘柜，每个磁盘柜24块磁盘；

9个磁盘柜的磁盘用来存储数据，另外1个磁盘柜用来存储元数据；

存储元数据的24块磁盘的组成结构：9组RAID1磁盘阵列+1组4盘位的RAID10磁盘阵列+4个全局热备盘；

存储数据的9×24=216块磁盘的组成结构：36组6盘RAID5阵列；36组RAID5磁盘阵列分为2个存储系统。

服务器数据恢复环境架构：

【服务器数据恢复】StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例_服务器数据恢复

注：Meta_LUN(元数据卷) Data_LUN（用户数据卷）

服务器故障：

存储数据的其中一个存储系统中一组RAID5阵列由于2块磁盘先后故障离线，该RAID5阵列失效，导致整个存储系统崩溃，无法使用。

服务器数据恢复过程：

1、将故障RAID5阵列中的6块成员盘编号标记，从磁盘柜中取出并接入到北亚企安数据备份服务器上，以只读方式对所有硬盘进行全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，避免服务器数据恢复过程中误操作对原始数据造成二次破坏。

备份过程：

【服务器数据恢复】StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例_StorNext文件系统数据恢复_02

在备份过程中发现故障RAID5阵列中的1块离线硬盘存在大量的坏道，无法继续备份。由硬件工程师对该故障盘开盘&更换固件并进行修复，经过处理后硬盘可以继续备份，但坏道仍然存在。

部分镜像文件：

【服务器数据恢复】StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例_数据恢复_03

2、基于镜像文件对故障RAID5阵列进行分析，获取RAID相关信息，利用这些信息虚拟重组RAID5阵列，将RAID中的LUN恢复成镜像文件。经过分析发现后离线硬盘损坏较为严重，存在大量坏道。

登录存储设备的管理界面，获取到StorNext文件系统中和卷相关的一些基本信息。

【服务器数据恢复】StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例_raid5数据恢复_04

3、分析StorNext文件系统中的Meta卷和Data卷，发现该StorNext文件系统包含2个Data卷，每一个完整的Data卷都是由多组RAID中的LUN组成。通过分析这些LUN北亚企安数据恢复工程师研究出LUN之间组合的算法规律，虚拟重组出完整的Data卷。

【服务器数据恢复】StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例_服务器数据恢复_05

4、分析Meta卷中的节点信息，目录项信息以及Meta卷和Data之间的对应关系。针对一个Meta卷管理多个Data卷的情况，北亚企安数据恢复工程师研究出Meta卷到Data卷的索引算法。

文件节点：

【服务器数据恢复】StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例_StorNext文件系统数据恢复_06

目录块：

【服务器数据恢复】StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例_raid5数据恢复_07

5、通过上面通过分析研究获取到的全部信息，北亚企安数据恢复工程师编写程序扫描Meta卷中的节点信息和目录项信息，解析目录项和节点并获取完整的StorNext文件系统目录结构。解析每一个节点中的指针信息，并将这些信息记录在数据库中。

文件信息：

【服务器数据恢复】StorNext文件系统下RAID5硬盘存在大量坏道离线导致阵列崩溃的数据恢复案例_服务器数据恢复_08

6、北亚企安数据恢复工程师编写文件提取程序读取数据库，结合解析出的信息以及两个Data卷之间的聚合算法提取数据。

数据验证：

随机抽样检测恢复出来的数据，没有发现。将数据移交给用户亲自验证，经过验证用户确认恢复数据完整可用。虽然故障硬盘存在大量坏道，所幸核心数据没有破坏，本次数据恢复工作完成。

Unix下zfs文件系统重组RAID-5恢复方法

存储做的RAID-5， SCSI硬盘，操作系统是FreeBSD，文件系统是zfs。

本案例共有12块硬盘，11块硬盘里有数据，1块硬盘是热备盘。其中第6块数据硬盘出现故障，重组时需要将其剔除。

物理盘：

物理盘是指创建RAID所用的每块独立的物理硬盘，组建RAID后，它们叫做RAID的成员盘。

去RAID化：

出现故障后，把物理盘从服务器的槽位上取下来进行检测和分析。离开了服务器的槽位，也就离开了RAID控制器，这些硬盘就称为被“去RAID化”了。

1 分析步骤

主要内容:

·初步判断RAID-5起始扇区

·块大小(条带大小)分析

·RAID-5成员盘盘序

·校验方向

·数据走向

1.1 初步判断RAID-5起始扇区

RAID起始扇区是指RAID内的数据在每块物理盘(创建RAID所用的每块独立的物理硬盘)上的起始位置。起始扇区只存在于一块物理盘，大多数情况是0扇区。找到起始扇区是第一步。本实例是用12块硬盘组成的RAID-5，第6块硬盘出现故障。恢复实例中，我们用WinHex将11块有数据的硬盘去RAID化。如图1所示。

图1

用WinHex的同步功能将11块盘定位在0扇区，可以看到11块盘中只有3块盘的0扇区有“55 AA”标志，分别是1,2,6号硬盘，如图2所示。有这个标志说明是MBR磁盘结构。

图2

接下来分析哪个硬盘是起始扇区。我们先来看第6块硬盘。第6块硬盘的结尾显示这是一个GPT头备份并且只有128MB大小。如图3所示。

图3

剩下的1号磁盘和2号磁盘中0扇区有起始扇区或校验。这是初步判断起始扇区。

1.2 块大小(条带大小)分析

条带也称块，它是RAID处理数据的基本单元，不同的RAID条带大小有所不同。分析条带大小的方法有很多，一个校验区的大小是一个条带的大小，根据这一点，我们针对这个RAID-5实例做分析。此实例使用的是zfs文件系统，用WinHex同步显示11块物理盘的某个扇区，比如53654656扇区，发现此扇区只有1号盘跟其他盘显示的不一样，这是位于1号盘的校验区。顺着1号盘53654656扇区上下寻找，找到连续的128个扇区。这128个扇区就是这个RAID-5的条带大小。由此条带大小定位结束。

1.3 RAID-5成员盘盘序

以上内容说的1号盘指的不是RAID的第一个盘，也就是说物理盘的顺序并不一定是RAID的顺序，需要人工校验。用WinHex同步定位11块硬盘的53654656扇区。发现1号盘与其他盘不同，这个是1号盘的校验区。接着分析1号盘的下一个条带，即53654656+128=53654784扇区，得出2号盘跟其他盘不同，所以2号盘从53654784扇区开始的条带是校验区。以此方式继续下去，接着是3号盘的校验区，4号盘的校验区……得出的校验区如图4所示，“P”字母即表示校验区。我们按照校验区的位置，即可得到盘序，而这个实例的盘序正好是从1号盘开始依次递增的。盘序我们已经得出，又因分析步骤1得出1号盘和2号盘的0扇区为起始扇区或为校验区。对于左结构来说，0扇区是起始扇区的物理盘一定是RAID-5的1号盘，对于右结构来说，0扇区是起始扇区的物理盘一定是RAID-5的2号盘。

图4

1.4 校验方向

RAID-5的基本结构有左同步、左异步、右同步、右异步。左和右是对校验方向来说的，区别如表1和表2所示。我们做的RAID-5实例很明显是右走向的。

表1

我们由上文校验区的走向得出整个RAID-5的校验方向，即右方向，如图4所示。左同步、左异步结构中的校验块都是从最后一块物理盘开始，右同步、右异步结构中的校验快都是从第一块物理盘开始。

判断校验方向的方法有两种，一种是先分析起始扇区，再分析条带大小，然后是盘序，盘序分析后校验方向很容易就看出来了。另一种，如果盘序没有确定下来，只确定了起始扇区和条带大小，可以采用反推法。使用反推法分析，在盘序还没有确定下来的情况下，有这个校验区可以算出某个盘中第一个校验区是第几个条带。具体方法如下找到某个校验区，比如3号盘的53654912扇区，用这个扇区对条带大小与盘数的乘积取余。即53654912MOD(128*12)=256。计算的结果等于256，表示256号扇区是校验。而位于此扇区的3号盘处于第3个条带，并且是第3个条带的开始扇区，包括256号扇区在内的以后的128个扇区是3号盘的第一个校验区。接着判断1号盘下一个条带，1号盘下一个条带显示3号盘是校验区。接着判断3号盘下一个条带，3号盘下一个条带显示3号盘是校验区。由此校验方向也能得出来。

1.5 数据走向

同步异步说的是数据的走向。异步结构中，各条带组内的数据块均由低号盘向高号盘依次写入。同步结构中，每个条带组内第一个数据块写在校验块所在物理盘的下一个物理盘，若后面还有物理盘，则顺序往后写，若校验块所在物理盘后没有物理盘，则从校验块所在物理盘前面的物理盘开始从低号盘向高号盘顺序写入。