Linux 服务器RAID 5磁盘阵列数据恢复

Linux服务器RAID5磁盘阵列数据恢复的案例,这个案例的RAID 5 磁盘阵列崩溃,以下是该案例的简单介绍。

某案例的现场环境:

Linux 服务器;

RAID 5 硬盘阵列,6块200GB 硬盘;

阵列的总容量 1TB,共8个分区。

其中:第一个分区容量16MB,文件系统为 EXT2, 用于系统引导,其他7个分区的文件系统都是 XFS。第5个分区的容量为 900GB。

故障现象:阵列中的第2块硬盘由于存在大量坏扇区早已掉线,盘上的数据已经不“新鲜”,故该盘对恢复RAID 阵列而言已无任何价值,使用他反倒会造成数据错乱。最新掉线的是5号盘,由于它的掉线导致了整个RAID5阵列最终崩溃。5号盘的掉线原因是,在硬盘前部有少量物理坏扇区。因此恢复该RAID5 阵列的数据,只能依靠第 0、1、3、4、5号盘进行。

提示:目前还没有一款数据恢复软件能够恢复 XFS 文件系统的数据。

某公司恢复方案一:

首先利用一块 IDE 接口的RAID 卡, 4块 250GB 的硬盘组成一个1TB 容量的RAID0 的磁盘阵列。将客户的0、1、3、4、5号盘通过Raid Reconstructor 软件进行重构。将重构后的RAID 5镜像复制到RAID0 阵列上。以上操作过程历时24小时。

在Windows 2003 系统上利用共享软件 XFS32,试图在Windows 2003 系统上, 挂载(Mount)RAID0 的7个XFS分区。通过努力最终挂载上5个XFS 分区,但容量900GB 的第5个分区挂载时出错失败。这也意味着客户的700GB 数据无法直接访问,方案一失败。

方案二:

安装 Linux (RedHat 9)系统在恢复主机上,并重新编译 Linux内核,使之支持 XFS文件系统分区(在缺省的情况下, Linux 只支持标准的 EXT2/EXT3分区)。

目标是在Linux 系统下,用mount 命令挂载 RAID0 阵列上的第5个分区。但当Linux系统启动后发现,当前使用的RAID 卡不支持Linux系统。系统将RAID0 阵列识别为4块独立的250GB的硬盘。方案二失败。

方案三:

现在面临了2种选择:

1.重新更换新的支持Linux 的RAID 卡,这首先意味着要增加恢复成本(RAID卡的成本大约1000多元人民币)。更重要的是对新RAID 卡要重建RAID0,重新生成客户的RAID 5 的镜像。这需要花费大约24小时以上的时间,但由于要恢复的数据对客户十分重要,每耽误一天,客户损失就高达数万元。这种选择显然不是最佳的。

2. 在Windows 2003系统上建立VMware虚拟机,在虚拟机上安装同样的Red Hat 9  Linux 系统,打上支持XFS 文件系统的补丁。由于VMware是运行在Windows 2003系统之上的,所以在虚拟机上运行的操作系统都能识别RAID0阵列。

启动Linux,用mount命令直接挂载RAID0 阵列上的第5个XFS 分区,结果还是出错失败。使用FSCK程序修复该分区的数据结构,显示超级块修复成功,再用mount命令直接挂载RAID0 阵列上的第5个XFS 分区,挂载成功,分区可以直接访问。在Linux系统下检测数据,700GB数据完整无损,数据恢复成功,历时2小时。

案例总结:方案一之所以失败,是因为共享程序 XFS32本身不具有文件系统的数据结构的修复能力,所以当XFS分区的数据结构有轻微损坏时,就无法挂载。造成XFS分区的数据结构有轻微损坏的原因是,客户RAID5阵列中的第5块硬盘前部有少许坏扇区。方案二的失败是由于该公司自身的硬件环境造成的。在方案三中如果选择 1,是方案二的补救方案,理论上客户的数据是可以恢复的。但由于时间因素决定了这次数据恢复操作的价值和成功率,所以这种选择显然不是最好的。

在本案例中由于使用了VMware虚拟机,不但节约了恢复成本,减少了恢复时间,还为客户减少了数万元的经济损失。充分说明了VMware虚拟机在数据恢复中的作用和应用价值。

注意:如果本案例中要恢复的RAID 5的容量大于1TB,就不能使用VMware虚拟机了,因为VMware虚拟机目前还不支持容量1TB 以上的硬盘设备。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wygfxx.html