某大学数据恢复报告

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

 本案例详细介绍了数据库恢复的过程,包括RAID重组和数据库数据的修复与验证。

  故障设备

  IBM DS5020 光纤存储

  故障描述

  存储上一共16块FC硬盘,单盘容量600G。存储前面板10号和13号硬盘亮***故障灯,存储映射到redhat上的卷挂载不上,业务崩溃。

  存储恢复流程

  通过IBM storage manager连接到存储查看当前存储状态,存储报告逻辑卷状态失败,再查看物理磁盘状态,发现6号盘报告“警告”,10号和13号盘报告“失败”,通过IBM storage manager将当前存储的完整日志状态备份下来,解析备份出来的存储日志获得了关于逻辑卷结构的部分信息。

  将16块FC盘粘贴标签,按照原始槽位号登记后从存储中移除,使用我们的FC盘镜像设备“DELL R510+SUN3510”对16块FC盘进行粗略测试,结果发现16块盘均能正常识别,分别检测16块盘的SMART状态,结果6号盘的SMART状态为“警告”状态和在IBM storage manager中报告一致。

  在windows环境下首先将设备识别出来的FC盘在磁盘管理器中标记为脱机状态,从而为原始磁盘提供了一个写保护功能,然后使用winhex软件对原始磁盘进行扇区级别镜像操作,将原始磁盘中的所有物理扇区镜像到windows系统下的逻辑磁盘并以文件形式保存。在镜像过程中发现6号磁盘的镜像速度很慢,结合先前对硬盘SMART状态检测时发现的问题综合判断,6号盘应该存在大量损坏以及不稳定扇区,导致在windows下的一般应用软件无法对其进行操作。

  使用专业坏道硬盘镜像设备对6号硬盘进行坏道镜像操作,在镜像过程中同时观察镜像的速度和稳定性,发现6号盘的坏道并不多,但是存在大量的读取响应时间长等不稳定扇区,于是调整6号盘的拷贝策略,将遇到坏道跳过扇区数和响应等待时间等参数均作一些修改。继续对6号盘进行镜像操作。同时观察剩余盘在windows环境下使用winhex镜像的情况。

  经过镜像操作后,在windows平台下使用winhex镜像的磁盘已经全部镜像完成,查看winhex生成的日志,发现在IBM storage manager和硬盘SMART状态中均没有报错的1号盘也存在坏道,10号和13号盘均存在大量不规律的坏道分布,根据坏道列表使用winhex定位到目标镜像文件分析发现,ext3文件系统的一些关键源数据信息有的已经被坏道所破坏,只能等待6号盘镜像完毕后,通过同一条带进行xor以及根据文件系统上下文关系的方式手动修复被损坏的文件系统。

  坏道镜像设备报告6号盘镜像完成,但是先前为了最大限度做出有效扇区以及为了保护磁头设置的拷贝策略会自动跳过一些不稳定扇区,所以现在的镜像是不完整的,于是调整拷贝策略,继续镜像被跳过的扇区,6号盘所有扇区全部镜像完毕。

  得到了所有硬盘的物理扇区镜像,在windows平台下使用winhex将所有镜像文件全部展开,根据我们对ext3文件系统的逆向以及日志文件的分析,得到了16块FC盘在存储中的盘序,RAID的块大小,RAID的校验走向和方式等信息,于是尝试通过软件的方式虚拟重组RAID,RAID搭建完成后进一步解析ext3文件系统,通过和用户沟通提取出了一些oracle的dmp文件,用户尝试进行恢复。

  在dmp恢复的过程中,oracle报告为imp-0008错误,联系北亚的oracle工程师,通过仔细分析导入dmp文件的日志文件,发现恢复的dmp文件存在问题而导致dmp导入数据失败。立刻重新分析raid结构,以及进一步确定ext3文件系统被破坏的程度,又经过数小时的工作,重新恢复dmp文件和dbf原始库文件,将恢复出来的dmp文件移交给用户进行数据导入测试,结果测试顺利没有发现问题,说明这次的数据恢复是成功的,接着对恢复出来的dbf原始库文件进行校验检测,所有文件均能通过测试。

  北亚的数据库工程师到达现场,和用户沟通后决定使用恢复出来的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备份。全库备份完成,没有报错。将应用程序连接到数据库,进行应用层面的数据验证。

  数据验证结束,数据库修复完成,数据恢复成功。





本文转自 张宇 51CTO博客,原文链接:http://blog.51cto.com/zhangyu/1738696,如需转载请自行联系原作者
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
9月前
|
数据挖掘 Windows
【服务器数据恢复】服务器迁移数据时数据丢失的数据恢复案例
一台安装Windows操作系统的服务器。工作人员在迁移该服务器中数据时突然无法读取数据,服务器管理界面出现报错。经过检查发现服务器中一个lun的数据丢失。
|
1月前
|
Linux Windows
硬盘误删文件还能救?专业数据恢复工具大全
电脑里的硬盘或是移动硬盘都承载着我们日常生活和工作中的重要数据,比如珍贵的照片、关键的工作文件。一旦这种重要资料丢失了,会令人非常焦虑。好消息是,大多数情况下,即便硬盘上的文件被意外删除、分区被格式化,甚至硬盘出现逻辑故障(比如硬盘打不开提示格式化),专业的数据恢复工具仍然能够帮助我们找回丢失的数据。本文会详细介绍一些常见且功能强大的硬盘数据恢复工具,帮助大家选择最适合的解决方案。
|
3月前
|
存储 SQL 数据库
虚拟化数据恢复—Vmware虚拟机误还原快照的数据恢复案例
虚拟化数据恢复环境: 一台虚拟机从物理机迁移到ESXI虚拟化平台,迁移完成后做了一个快照。虚拟机上运行了一个SQL Server数据库,记录了数年的数据。 ESXI虚拟化平台上有数十台虚拟机,EXSI虚拟化平台连接了一台EVA存储,所有的虚拟机都存放在EVA存储上。 虚拟化故障: 工组人员误操作将数年前迁移完成后做的快照还原了,也就意味着虚拟机状态还原到数年前,近几年数据都被删除了。 还原快照相当于删除数据,意味着部分存储空间会被释放。为了不让这部分释放的空间被重用,需要将连接到这台存储的所有虚拟机都关掉,需要将不能长时间宕机的虚拟机迁移到别的EXSI虚拟化平台上。
142 50
|
7月前
|
存储 运维 数据挖掘
服务器数据恢复—IBM V7000数据恢复案例
服务器存储数据恢复环境: 某品牌P740小型机+AIX+Sybase+V7000磁盘阵列柜,磁盘阵列柜中有12块SAS机械硬盘(其中包括一块热备盘)。 服务器存储故障: 磁盘阵列柜中有一块磁盘出现故障,运维人员用新硬盘替换掉故障盘并开始同步数据。当数据同步的进度不到一半的时候,磁盘阵列柜中另一个磁盘也出现了问题,导致逻辑盘无法挂接在小型机上,业务中断。通过存储的管理界面查看,发现两块硬盘显示故障脱机,其中10号槽位故障硬盘为热备盘。 磁盘阵列柜中一共创建了2组Mdisk,加到一个pool中,现在的故障表现是主要的数据pool无法加载,部分通用卷均无法挂载。
服务器数据恢复—IBM V7000数据恢复案例
|
5月前
|
存储 算法 安全
硬盘数据恢复工具,测评八款软件 帮你恢复删除的文件
在日常使用电脑的时候,很多用户都有过误删除重要文件、硬盘无法访问或是格式化后丢失重要数据的经历。幸运的是,这些重要的数据并非在删除或硬盘格式化后就完全消失不见了,我们借助硬盘数据恢复工具仍然有很大几率恢复丢失的数据。今天会和大家讨论一下硬盘数据恢复工具的工作原理和局限性,并且测评几款常用的工具软件,希望可以帮助大家在丢失数据的时候可以快速找得解决方案。
|
7月前
|
存储 负载均衡 算法
服务器数据恢复—EVA存储介绍&常见故障和数据恢复
EVA存储常见故障: 1、RSS中多个磁盘掉线,超过冗余保护级别。 2、加入新磁盘,进行数据迁移时,新磁盘存在物理故障。 3、VDISK被删除或EVA初始化。 4、突发性主机与存储无法连接。无法discover存储。
服务器数据恢复—EVA存储介绍&常见故障和数据恢复
|
8月前
|
存储 小程序 数据库
服务器数据恢复—异常断电导致存储不可用的数据恢复案例
服务器存储数据恢复环境: 一台存储中有一组由12块SAS硬盘组建的RAID6磁盘阵列,划分为一个卷,分配给几台Vmware ESXI主机做共享存储。该卷中存放了大量Windows虚拟机,这些虚拟机系统盘是统一大小,数据盘大小不确定,数据盘是精简模式。 服务器存储故障: 机房断电导致服务器存储异常关机,加电后存储无法使用。
服务器数据恢复—异常断电导致存储不可用的数据恢复案例
|
8月前
|
运维 数据挖掘
服务器数据恢复—某品牌X3650服务器硬盘离线崩溃的数据恢复案例
一台某品牌X3650M3服务器,服务器中有一组raid5磁盘阵列,上层采用zfs文件系统。 服务器未知原因崩溃,工作人员排查故障后发现服务器的raid5阵列中有两块硬盘离线导致该阵列不可用,服务器内的数据丢失。 数据恢复工程师在现场对故障服务器raid5阵列中的磁盘进行硬件故障检测,经过检测发现该raid5阵列中离线的两块硬盘均无硬件问题。
|
9月前
|
存储 Oracle 关系型数据库
服务器数据恢复—北亚企安服务器数据恢复案例集锦
服务器数据恢复案例之服务器raid6中3个磁盘离线导致阵列崩溃的数据恢复案例 服务器数据恢复案例之服务器RAID5两个磁盘指示灯显示红色导致服务器崩溃的数据恢复案例 服务器数据恢复案例之服务器硬盘出现坏道/坏扇区离线导致服务器崩溃的数据恢复案例
|
9月前
|
数据挖掘 数据库 虚拟化
服务器数据恢复-异常断电导致服务器数据丢失的数据恢复案例
服务器数据恢复环境: dell某型号服务器中有一组通过raid卡组建的raid10,该raid阵列中一共有4块磁盘。上层部署XenServer虚拟化平台,作为网站服务器使用。 服务器故障: 服务器异常断电导致服务器上的一台虚拟机不可用。需要恢复这台虚拟机上的数据库数据。
服务器数据恢复-异常断电导致服务器数据丢失的数据恢复案例