服务器数据恢复—raid5阵列上层Oracle数据库数据恢复案例

avatar
作者
筋斗云
阅读量:0

服务器数据恢复环境&故障:
一台服务器上有8块SAS硬盘,其中的7块硬盘组建了一组RAID5阵列,另外1块硬盘作为热备盘使用。划分了6个LUN,服务器上部署有oracle数据库。
RAID5磁盘阵列中有2块硬盘出现故障并离线,RAID5阵列瘫痪,上层LUN无法正常使用。经过硬件工程师检测,所有硬盘(包括离线的2块盘)均无物理故障以及坏道。

服务器数据恢复过程:
1、将服务器中所有磁盘编号标记后取出,以只读方式将所有磁盘进行扇区级全盘镜像。镜像完成后将所有磁盘按照编号还原到原服务器中,后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。

2、基于镜像文件分析所有磁盘的底层数据。通过分析获取到raid相关信息(条带大小,磁盘顺序及数据走向等),依据这些信息虚拟重组原RAID5阵列。
3、仔细分析每一块硬盘中的数据,通过北亚企安自主开发的RAID校验程序做校验,将最先掉线的硬盘剔除出raid。
4、服务器中的的LUN都是基于RAID的,分析LUN在RAID5阵列中的分配情况,以及LUN分配的数据块MAP。
5、将每一个LUN的数据块分布MAP提取出来。北亚企安数据恢复工程师针对这些信息编写相应的程序,解析所有LUN的数据MAP,然后根据数据MAP导出所有LUN的数据。

6、分析所有导出的LUN,发现所有LUN中均包含HP-Unix的LVM逻辑卷信息。尝试解析每个LUN中的LVM信息,发现其中一共有三套LVM:其中一个LVM中划分了一个LV,存放OA服务器端的数据;第二个LVM中也划分了一个LV,存放临时备份数据;第三个LVM由剩余4个LUN组成,划分了一个LV,存放Oracle数据库文件。北亚企安数据恢复工程师编写LVM解释程序,尝试将每个LVM中的LV都解释出来,但解释过程中程序报错。
7、分析程序报错的原因,并让开发工程师debug程序出错的位置,同时安排高级文件系统工程师检测所有恢复出来的LUN,检测是否会因为存储瘫痪而导致LMV逻辑卷的信息损坏。经过检测,发现存储瘫痪确实导致LVM信息损坏。尝试人工修复损坏的区域,并同步修改程序,重新解析LVM逻辑卷。
8、搭建HP-Unix环境,将解释出来的LV卷映射到HP-Unix,并尝试Mount文件系统,结果Mount文件系统出错。尝试使用“fsck –F vxfs” 命令修复vxfs文件系统,修复完成后还是不能挂载。怀疑底层vxfs文件系统的部分元数据可能被破坏。
9、分析解析出来的LV,并根据VXFS文件系统的底层结构校验此文件系统的完整性。经过分析发现底层VXFS文件系统确实有问题,原来当存储瘫痪的同时此文件系统正在执行IO操作,因此导致部分文件系统元文件损坏。手工修复这些损坏的元文件,直到VXFS文件系统能够正常解析。将修复好的LV挂载到HP-Unix小机上,尝试Mount文件系统,这回文件系统没有报错,成功挂载。
10、在HP-Unix机器上mount文件系统后,将所有用户数据均备份至指定磁盘空间。
部分文件目录截图:

11、使用Oracle数据库文件检测工具“dbv”检测每个数据库文件的完整性,没有发现错误。使用北亚企安自主研发的Oracle数据库检测工具进行检测,发现部分数据库文件和日志文件校验不一致。安排高级数据库工程师修复此类文件后再次校验,直到所有文件校验均完全通过。
12、将恢复出来的Oracle数据库附加到原始生产环境的HP-Unix服务器中,尝试启动Oracle数据库,Oracle数据库启动成功。

13、由用户方配合,启动Oracle数据库和OA服务端,在本地安装OA客户端。通过OA客户端对最新的数据记录以及历史数据记录进行验证,并且安排用户方单位不同部门人员进行远程验证。经过多方面验证,确认数据完整无误。数据恢复工作完成。

    广告一刻

    为您即时展示最新活动产品广告消息,让您随时掌握产品活动新动态!