存储硬盘离线VXFS文件系统恢复教程

服务器数据恢复故障描述

客户的服务器共有8块450GB SAS硬盘，其中7块硬盘组成一个RAID5阵列，1块热备盘。阵列中2块硬盘损坏并离线，导致RAID5阵列瘫痪，进而影响上层LUN无法正常使用。经工程师检测硬盘无物理故障，无坏道，随后北亚工程师将所有磁盘镜像成文件。

数据恢复过程

一、RAID组结构及掉线盘分析

服务器的LUN都是基于RAID组的，所以需要先对底层RAID组的信息作出分析，再依据这些数据重构原始的RAID组。通过分析得知4号盘为hot Spare盘。继续分析Oracle数据库页在每个磁盘中分布的情况，进而得出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文件系统的部分元数据可能破坏，需要进行手工修复。

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

六、恢复所有用户文件并检测数据文件是否完整

在HP-Unix机器上mount文件系统后，将所有用户数据均备份至指定磁盘空间。

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

七、启动Oracle数据库

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

八、数据恢复验证及结果

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

【北亚小贴士】

故障发生后保存现场环境良好，没用做相关危险的操作，对后期的数据恢复有很大的帮助。