当前位置：首页 > news >正文

服务器数据恢复—光纤存储FC硬盘数据恢复案例

news 来源：原创 2025/7/18 10:07:56

服务器存储数据恢复环境：
某品牌光纤存储上共有16块FC硬盘。存储上的卷映射到Linux操作系统上。Linux操作系统上运行Oracle数据库。

服务器存储故障&检测：
存储上2块硬盘故障灯亮起，存储映射到linux操作系统上的卷挂载不上，业务中断。
使用storage manager连接到存储查看存储目前状态，发现逻辑卷状态失败；6号盘报告“警告”，10号盘和13号盘报告“失败”；通过storage manager将当前存储的完整日志状态备份下来，解析备份的日志获取关于逻辑卷结构的部分信息。
将16块FC盘标记后从存储中取出，使用专业设备检测后发现16块盘均能正常识别，6号盘的SMART状态为“警告”，和在storage manager中的报告结果一致。
将所有磁盘以只读方式进行扇区级全盘镜像。在镜像过程中观察镜像的速度和稳定性，发现6号盘的镜像速度异常，结合之前检测结果，基本上可以判断6号盘应该存在损坏或者不稳定扇区。经过观察发现6号盘的坏道并不多，但是存在大量的读取响应时间长的不稳定扇区。调整镜像策略继续对6号盘做镜像。
所有磁盘镜像完成后，查看日志，发现在storage manager和硬盘SMART状态检测中均没有发现问题的1号盘也存在坏道，10号和13号盘均存在大量不规律的坏道。根据坏道列表定位到目标镜像文件，分析后发现ext3文件系统的部分关键源数据信息已经被坏道破坏。只能等所有磁盘镜像完毕后，
通过同一条带进行xor以及根据文件系统上下文关系手动修复被损坏的文件系统。
虽然通过调整镜像策略完成6号盘的镜像，但是调整后的镜像策略会自动跳过一些不稳定扇区，所以做出来的镜像是不完整的。再次调整镜像策略，继续镜像被跳过的扇区，直到全部镜像完成。
基于镜像文件分析所有磁盘底层数据。通过对ext3文件系统的逆向分析以及对日志文件的分析，获取到16块FC盘在存储中的盘序、RAID的块大小、RAID的校验走向和方式等重组RAID所需要的信息。尝试使用上述获取到的信息重组RAID，重组完成后解析ext3文件系统。和用户沟通后，提取出一些oracle的dmp文件，用户尝试使用这些dmp文件恢复Oracle数据库数据。
在使用dmp文件恢复Oracle数据库的过程中，数据库报告imp-0008错误。对导入dmp文件的日志文件进行分析，发现恢复出来的dmp文件存在问题。重新分析raid结构，进一步确定ext3文件系统被破坏的程度，重新恢复dmp文件和dbf原始库文件。将恢复出来的dmp文件进行导入测试，这次没有发现问题。对恢复出来的dbf原始库文件进行校验检测，所有文件均能通过检测。

Oracle数据库恢复过程：
1、拷贝数据库文件到原数据库服务器，目标路径为/home/oracle/tmp/syntong。
在根目录下创建一个oradata文件夹，将备份的syntong文件夹拷贝到oradata目录下。更改oradata文件夹及其所有文件的属组和权限。
2、备份原数据库环境，包括ORACLE_HOME下product文件夹下的相关文件。配置监听，使用原机中的splplus连接到数据库。尝试启动数据库到nomount状态，查询基本状态，确认环境和参数文件均没有问题。尝试启动数据库到mount状态，查询状态没有问题。启动数据库到open状态时报错。

3、进一步检测和分析后基本上可以判断此故障发生原因是控制文件和数据文件信息不一致，这一类问题通常是因为断电或异常关机导致的。
4、逐个检测数据库文件，没有发现有文件存在物理损坏。
5、在mount状态下备份控制文件：alter database backup controlfile to trace as ' /backup/controlfile'。查看&修改备份的控制文件，获取重建控制文件命令。将这些命令复制到一个新建脚本文件controlfile.sql中。
6、关闭数据库，删除/oradata/syntong/下的3个控制文件。启动数据库到nomount状态，执行controlfile.sql 脚本。

7、完成控制文件的重建后，启动数据库。仍然报错，需要进一步处理。

执行恢复命令：

做介质恢复，直到返回报告。
8、尝试open数据库。
SQL> alter database open resetlogs;
9、数据库启动成功。把原temp表空间的数据文件加入到对应的temp表空间中。
10、对数据库进行各种常规检查，没有发现任何问题
11、进行emp备份。全库备份完成，没有报错。将应用程序连接到数据库验证数据。
12、经过仔细验证，用户方确认数据库数据没有问题，认可数据恢复结果。

相关文章：