服务器数据恢复环境：
8块SAS硬盘中的7块硬盘组成RAID5阵列，1块作为热备盘。
服务器故障：
故障服务器存储中的RAID5阵列有2块硬盘损坏离线，RAID5阵列瘫痪，影响上层LUN无法正常使用。管理员联系我们数据恢复中心进行数据恢复，硬件工程师检测硬盘没有发现物理故障和坏道。
服务器数据恢复过程：
1、备份数据。使用数据恢复工具将所有磁盘镜像备份。
2、分析RAID结构。
故障服务器的LUN都是基于RAID的，需要先分析底层RAID的信息，再依据分析获取到的raid相关信息重构原始RAID。通过分析获知4号盘为hot Spare盘。分析Oracle数据库页在每个磁盘中的分布情况得出RAID组的条带大小，磁盘顺序及数据走向等RAID组的重
要信息。
3、分析RAID掉线盘。
利用分析获取到的RAID信息，通过北亚自主开发的RAID虚拟程序将原始的RAID拟出来。仔细分析每一块硬盘中的数据，通过北亚自主开发的RAID校验程序对条带做校验，将最先掉线的硬盘剔除出raid。
4、分析RAID组中的LUN信息。
将RAID最新的状态虚拟出来以后分析LUN在RAID中的分配情况和LUN分配的数据块MAP。只需要将底层6个LUN的数据块分布MAP提取出来，然后针对这些信息编写相应的程序对所有LUN的数据MAP做解析，根据数据MAP导出所有LUN的数据。
5、解析LVM逻辑卷。
分析生成出来的所有LUN，发现所有LUN中均包含HP-Unix的LVM逻辑卷信息。尝试解析每个LUN中的LVM信息，发现一共有三套LVM：其中一套LVM中划分了一个LV，存放OA服务器端的数据，另外一套LVM中划分了一个LV，存放临时备份数据。其他4个LUN组成一套LVM并划分了一个LV，存放Oracle数据库文件。北亚数据恢复工程师编写解释LVM的程序尝试将每套LVM中的LV卷解释出来，但解释程序出错。
6、修复LVM逻辑卷。
仔细分析报错的原因，由开发工程师debug程序出错的位置并由高级文件系统工程师检测恢复出来的LUN，检测存储瘫痪是否导致LMV逻辑卷的信息损坏。经过仔细检测，发现存储瘫痪确实导致了LVM信息损坏。尝试人工对损坏的区域进行修复，并修改LVM解释程序重新解析LVM逻辑卷。
7、解析VXFS文件系统。
搭建HP-Unix环境并将解释出来的LV卷映射到HP-Unix，尝试Mount文件系统。结果Mount文件系统出错，尝试使用“fsck –F vxfs” 命令修复vxfs文件系统，修复完成后还是不能挂载，怀疑底层vxfs文件系统的部分元数据被破坏，需要进行手工修复。
8、修复VXFS文件系统。
仔细分析解析出来的LV，并根据VXFS文件系统的底层结构校验此文件系统是否完整。经过分析发现底层VXFS文件系统有问题，原因是存储瘫痪的时候文件系统正在执行IO操作，因此部分文件系统元文件没有更新导致损坏。对这些损坏的元文件进行手工修复让VXFS文件系统能够正常解析。再次将修复好的LV卷挂载到HP-Unix小机上，尝试Mount文件系统没有报错，成功挂载。
9、恢复所有用户文件。
在HP-Unix机器上mount文件系统后将所有用户数据均备份至指定磁盘空间。部分文件目录截图如下：
10、检测数据库文件是否完整。
使用Oracle数据库文件检测工具“dbv”检测每个数据库文件是否完整，没有发现错误。使用北亚自主研发的Oracle数据库检测工具检测发现有部分数据库文件和日志文件校验不一致，数据库工程师对此类文件进行修复并再次校验，直到所有文件校验完全通过。
11、启动Oracle数据库。
由于我们数据恢复中心提供的HP-Unix环境没有此版本的Oracle数据库，和用户协调将原始环境带至北亚数据恢复中心，然后将恢复出来的Oracle数据库附加到原始生产环境的HP-Unix服务器中并尝试启动Oracle数据库，启动成功。部分截图如下：
12、数据验证。
由用户方配合启动Oracle数据库，启动OA服务端，在本地电脑端安装OA客户端。通过OA客户端对最新的数据记录以及历史数据记录进行验证，并且安排不同部门人员进行远程验证。最终数据验证无误，数据完整，数据恢复成功。
数据恢复结论：
由于故障发生后保存现场环境良好，没有做相关危险的操作，对后期的数据恢复有很大的帮助。整个数据恢复过程中虽然遇到好多技术瓶颈，但也都一一解决。最终在预期的时间内完成整个数据恢复，恢复的数据用户方也相当满意，Oracle数据库服务，OA服务端等所有服务能够正常启动。
阅读(417) | 评论(0) | 转发(0) |
