HP存储raid5两块硬盘离线lvm下vxfs文件系统恢复数据过程

故障描述

  HP FC MSA2000存储，因为RAID5阵列中出现2块硬盘损坏并离线，而此时只有一块热备盘成功激活，所以致使RAID5阵列瘫痪，上层LUN没法正常使用，用户联系联系北亚数据，整个存储空间由8块450GB SAS的硬盘组成，其中7块硬盘组成一个RAID5的阵列，剩余1块作成热备盘使用。

  因为存储是由于RAID阵列中某些磁盘掉线，从而致使整个存储不可用。所以接收到磁盘之后先对全部磁盘作物理检测，检测完后发现没有物理故障。接着使用坏道检测工具检测磁盘坏道，发现也没有坏道。

解决方法：

一、备份数据

  考虑到数据的安全性以及可还原性，在作数据恢复以前须要对全部源数据作备份，以防万一其余缘由致使数据没法再次恢复。使用dd命令或winhex工具将全部磁盘都镜像成文件。备份完部分数据以下图：

 

二、分析故障缘由

  因为前两个步骤并无检测到磁盘有物理故障或者是坏道，由此推断多是因为某些磁盘读写不稳定致使故障发生。由于HP MSA2000控制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定，HP MSA2000控制器就认为是坏盘，就将认为是坏盘的磁盘踢出RAID组。而一旦RAID组中掉线的盘到达到RAID级别容许掉盘的极限，那么这个RAID组将变的不可用，上层基于RAID组的LUN也将变的不可用。目前初步了解的状况为基于RAID组的LUN有6个，均分配给HP-Unix小机使用，上层作的LVM逻辑卷，重要数据为Oracle数据库及OA服务端。

三、分析RAID组结构

  HP MSA2000存储的LUN都是基于RAID组的，所以须要先分析底层RAID组的信息，而后根据分析的信息重构原始的RAID组。分析每一块数据盘，发现4号盘的数据同其它数据盘不太同样，初步认为多是hot Spare盘。接着分析其余数据盘，分析Oracle数据库页在每一个磁盘中分布的状况，并根据数据分布的状况得出RAID组的条带大小，磁盘顺序及数据走向等RAID组的重要信息。

四、分析RAID组掉线盘

  根据上述分析的RAID信息，尝试经过北亚自主开发的RAID虚拟程序将原始的RAID组虚拟出来。但因为整个RAID组中一共掉线两块盘，所以须要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其余硬盘明显不同，所以初步判断此硬盘多是最早掉线的，经过北亚自主开发的RAID校验程序对这个条带作校验，发现除掉刚才分析的那块硬盘得出的数据是最好的，所以能够明确最早掉线的硬盘了。

五、分析RAID组中的LUN信息

  因为LUN是基于RAID组的，所以须要根据上述分析的信息将RAID组最新的状态虚拟出来。而后分析LUN在RAID组中的分配状况，以及LUN分配的数据块MAP。因为底层有6个LUN，所以只须要将每个LUN的数据块分布MAP提取出来。而后针对这些信息编写相应的程序，对全部LUN的数据MAP作解析，而后根据数据MAP并导出全部LUN的数据。

 

六、解析LVM逻辑卷

  分析生成出来的全部LUN，发现全部LUN中均包含HP-Unix的LVM逻辑卷信息。尝试解析每一个LUN中的LVM信息，发现其中一共有三套LVM，其中45G的LVM中划分了一个LV，里面存放OA服务器端的数据，190G的LVM中划分了一个LV，里面存放临时备份数据。剩余4个LUN组成一个2.1T左右的LVM，也只划分了一个LV，里面存放Oracle数据库文件。编写解释LVM的程序，尝试将每套LVM中的LV卷都解释出来，但发现解释程序出错。

七、修复LVM逻辑卷

  仔细分析程序报错的缘由，安排开发工程师debug程序出错的位置，并同时安排高级文件系统工程师对恢复的LUN作检测，检测LVM信息是否会因存储瘫痪致使LMV逻辑卷的信息损坏。通过仔细检测，发现确实由于存储瘫痪致使LVM信息损坏。尝试人工对损坏的区域进行修复，并同步修改程序，从新解析LVM逻辑卷。

八、解析VXFS文件系统

  搭建HP-Unix环境，将解释出来的LV卷映射到HP-Unix，并尝试Mount文件系统。结果Mount文件系统出错，尝试使用“fsck –F vxfs” 命令修复vxfs文件系统，但修复结果仍是不能挂载，怀疑底层vxfs文件系统的部分元数据可能破坏，须要进行手工修复。

九、修复VXFS文件系统

  仔细分析解析出来的LV，并根据VXFS文件系统的底层结构校验此文件系统是否完整。分析发现底层VXFS文件系统果真有问题，原来当时存储瘫痪的同时此文件在系统正在执行IO操做，所以致使部分文件系统元文件没有更新以及损坏。人工对这些损坏的元文件进行手工修复，保证VXFS文件系统可以正常解析。再次将修复好的LV卷挂载到HP-Unix小机上，尝试Mount文件系统，文件系统没有报错，成功挂载。

十、恢复全部用户文件

在HP-Unix机器上mount文件系统后，将全部用户数据均备份至指定磁盘空间。全部用户数据大小在1.2TB左右。部分文件目录截图以下：

 

十一、检测数据库文件是否完整

  使用Oracle数据库文件检测工具“dbv”检测每一个数据库文件是否完整，发现并无错误。再使用北亚自主研发的Oracle数据库检测工具（检验更严格），发现有部分数据库文件和日志文件校验不一致，安排高级数据库工程师对此类文件进行修复，并在次校验，直到全部文件校验均彻底经过。

十二、启动Oracle数据库

  因为咱们提供的HP-Unix环境没有此版本的Oracle数据，所以和用户协调将原始生成环境带至北亚数据恢复中心，而后将恢复的Oracle数据库附加到原始生产环境的HP-Unix服务器中，尝试启动Oracle数据库，Oracle数据库启动成功。部分截图以下：

 

1三、数据验证

  由用户方配合，启动Oracle数据库，启动OA服务端，在本地笔记本安装OA客户端。经过OA客户端对最新的数据记录以及历史数据记录进行验证，而且有用户安排远程不一样部门人员进行远程验证。最终数据验证无误，数据完整，数据恢复成功。

因为故障发生后保存现场环境良好，没用作相关危险的操做，对后期的数据恢复有很大的帮助。整个数据恢复过程当中虽然遇到好多技术瓶颈，但也都一一解决。最终在预期的时间内完成整个数据恢复，恢复的数据用户方也至关满意，Oracle数据库服务，OA服务端等全部服务可以正常启动。