您所在的位置:首页 > 成功案例 > RAID数据恢复

磁盘坏道离线导致Raid崩溃的数据恢复案例

最新动态来源:本站原创点击数:152更新时间:2024/8/8

服务器存储数据恢复环境&故障情况:
一台光纤存储中有一组由16块硬盘组成的raid。
该存储出现故障导致数据丢失。RAID中2块盘掉线,还有1块盘smart状态为“警告”。
 
服务器存储数据恢复过程:
1、通过该存储自带的存储管理软件将当前存储的完整日志状态备份,解析备份出来的存储日志,获取到关于逻辑卷结构的部分信息。
2、在windows环境下把raid中状态正常的硬盘标记为脱机,然后将所有磁盘进行全盘镜像,在镜像过程中发现smart状态为“警告”的那块硬盘镜像速度异常缓慢,数据恢复工程师推测问题原因是该盘存在不稳定扇区和坏道。更换专业设备单独对该盘做镜像,将专业设备中的“遇到坏道响应”、“等待时间”和“跳过坏扇区数据”等参数进行调整后进行备份。
3、将存储中所有硬盘都镜像完成后,查看镜像工具生成的日志,发现在存储管理软件中和SMART状态中均没有发现问题的1块盘也存在坏道,掉线的2块盘均存在大量不规律的坏道分布。根据坏道列表定位到目标镜像文件,分析后发现该磁盘阵列中文件系统的部分关键数据处于坏道区。于是北亚企安数据恢复工程师通过同条带xor手动修复。
4、将备份出来的raid中的所有硬盘的数据展开,通过对ext3文件系统的逆向分析以及对日志文件的分析,获取到raid的盘序、raid块大小,raid的校验走向和校验方式等重组raid所必需的信息。
5、通过分析获取到的raid信息虚拟重组raid,然后解析ext3文件系统并提取数据库文件。
6、在提取数据库文件的过程中出现报错,数据库报告imp-0008错误。于是数据恢复工程师重新对raid结构进行分析,再一次提取dmp文件和dbf原始库文件,这回所有文件正常且无报错。
 
服务器存储中数据库数据恢复过程:
1、拷贝数据库文件到原服务器中/home/oracle/tmp/syntong目录下作为备份。在根目录下创建了一个oradata文件夹,将整个syntong文件夹拷贝到oradata目录下。然后更改oradata文件夹及其中所有文件的属组和权限。
2、备份原数据库环境,包括ORACLE_HOME下product文件夹下的相关文件。配置监听,使用原服务器中的splplus连接到数据库。尝试启动数据库到nomount状态。进行基本状态查询,发现环境和参数文件没有问题。 尝试启动数据库到mount状态,进行状态查询也没有发现问题。启动数据库到open状态。
出现报错:
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/oradata/syntong/system01.dbf'
ORA-01207: file is more recent than control file - old control file
3、经过进一步的检测和分析,初步判断出现此报错的原因是控制文件和数据文件信息不一致,这是一类通常由于断电或突然关机所引起的故障。
4、逐个检测数据库文件,没有发现有数据库文件被物理破坏。
5、在mount状态下备份控制文件,alter database backup controlfile to trace as ' /backup/controlfile'。查看&修改备份的控制文件,获取到其中的重建控制文件命令。将这些命令复制到一个新建脚本文件controlfile.sql中。
6、关闭数据库,删除/oradata/syntong/下的3个控制文件。 启动数据库到nomount状态,执行controlfile.sql脚本。
SQL>startup nomount
SQL>@controlfile.sql
7、重建控制文件后,直接启动数据库,再次报错,需要进一步处理。
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/free/oracle/oradata/orcl/system01.dbf'
然后执行恢复命令:
recover database using backup controlfile until cancel;
Recovery of Online Redo Log: Thread 1 Group 1 Seq 22 Reading mem 0
Mem# 0 errs 0: /free/oracle/oradata/orcl/redo01.log
做介质恢复,直到返回报告,恢复完成。
8、尝试open数据库。
SQL> alter database open resetlogs;
9、数据库启动成功。把原来temp表空间的数据文件加入到对应的temp表空间中。
10、对数据库进行各种常规检查,没有发现任何错误。
11、进行emp备份。全库备份完成,没有报错。将应用程序连接到数据库,在应用层面验证数据,也没有发现问题。
12、经过用户方仔细检验后,确认恢复出来的数据库数据没有问题,认可数据恢复结果。