ITPub博客

首页 > IT基础架构 > 服务器/存储 > 服务器超负荷导致RAID5故障的数据恢复案例

服务器超负荷导致RAID5故障的数据恢复案例

原创 服务器/存储 作者:北亚数据恢复 时间:2023-07-07 14:33:30 0 删除 编辑

服务器数据恢复环境:

一台IBM某型号服务器,4块SAS磁盘组建了一组RAID5磁盘阵列。服务器安装的windows server操作系统,上面运行了一

个Oracle单节点,数据存储为文件系统,无归档。该oracle数据库的数据量不大,只有一个用户,使用默认的users表空间

,users空间下只有一个不大的数据文件。


服务器故障:

由于服务器超负荷运行,RAID5磁盘阵列出现问题。为了保证服务器能正常稳定运行,工作人员做了重建RAID的操作,在重

建RAID过程中由于RAID中的一块磁盘出现故障,RAID初始化中止,少量数据被同步而破坏,但是RAID5磁盘阵列已经可以

访问。

服务器操作系统虽然出现错误,但还能正常启动。oracle数据库所在D盘分区报错无法打开,工作人员做了chkdsk后能正常打

开D盘分区,但oracle数据库无法启动。工作人员在D盘上重装了oracle数据库并导入了以前备份的dmp文件,但数据和出故

障前的oracle数据库数据相差太多。


服务器数据恢复过程:

1、将故障服务器中所有磁盘编号后取出,以只读方式进行全盘镜像备份,后续的数据分析和数据恢复操作都基于镜像文件

进行,避免对原始磁盘数据造成二次破坏。

2、基于镜像文件分析RAID。因为重建RAID会给数据造成严重的破坏,但经过对底层数据的分析发现重建的RAID的块大小

、盘序都和原来的RAID一致。在初始化过程中仅同步了前面部分的少量数据,RAID数据损坏不大,数据库还没被破坏。

3、Chkdsk并不会破坏用户数据区,chkdsk只对文件系统元数据区进行修改。执行chkdsk操作后oracle数据库文件没有被

破坏,最多只是文件的MFT或目录项被破坏。真正对数据破坏严重的操作是重装Oracle数据库和导入dmp文件,这一系列

操作不仅对文件系统元数据区造成了破坏,还将用户数据区进行了覆盖。

4、基于镜像文件分析D盘的NTFS文件系统,发现所有原oracle数据文件的MFT均被覆盖,NTFS日志也被轮回覆盖,从

NTFS元数据区找不到可利用信息。数据恢复工程师只能使用北亚企安自主研发的Oracle恢复程序对整个D盘分区进行恢复。

5、经过程序的扫描,发现Oracle实例为ANSORA,扫描出一个原始完整的控制文件和一个原始完整的undotbs表空间数据

文件。重要的system和users表空间数据文件都被不同程度的破坏:其中system表空间的数据文件仅剩中后部的十多MB,

原始文件应该约有几百MB;users表空间的数据文件有部分被覆盖,仅剩几

MB。提取出找到的数据,然后对损坏严重的数据库进行修复。

6、由于system表空间不可用,无法得到数据字典。经过沟通,用户方确认了有重要的三张表,从imp回去的数据库中获取

到这三张表的结构,再从恢复users表空间的数据文件中找到对应的segment。但有一张表无法对应上,再次沟通得知这一

张表有过更改字段的操作,北亚企安数据恢复工程师只能重新构建新的表结构对应上users表空间数据文件中segment,然

后通过dul工具提取这三张表的数据。

7、提取完成数据后由用户方工程师进行验证,经过反复验证,用户方工程师确认恢复出来的数据有效。本次数据恢复工作

完成。


来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/31380569/viewspace-2962976/ ,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
从事服务器数据恢复、磁盘阵列数据恢(DEll、HP、IBM、华为、NetApp等),虚拟化数据恢复(VSAN、VMware、Kvm等),数据库数据恢复(Oracle、Sql Server、MySql、Mongodb等),小型机数据恢复等方面的。24h数据救援13439392933

注册时间:2016-08-02

  • 博文量
    1128
  • 访问量
    877449