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 以上的硬盘设备。