EVA 4400存储数据恢复报告

  EVA系列存储是一款以虚拟化存储为实现目的的HP中高端存储设备,平时数据会不断的迁移,加上任务通常较为繁重,所以磁盘的负载相对是较重的,也是很容易出现故障的。EVA是依靠大量磁盘的冗余空间,以及故障后rss冗余磁盘动态迁移来实现整个存储的数据保护,但随着越来越多的磁盘掉线,这种保护会接近临界,直至崩溃。下面以EVA存储故障为例,讲解EVA 4400存储数据恢复。

  一、故障描述

  整个EVA存储结构是由一台EVA4400控制器、EVA扩展柜及若干FC磁盘组成。由于磁盘故障导致存储中LUN不可用,致使上层应用无法正常使用。

  二、检测磁盘

  由于EVA 4400是因为某些磁盘故障导致整个存储不可用,因此接收到磁盘以后先对所有磁盘做物理检测,检测完后发现磁盘并没有物理故障。接着使用坏道检测工具检测磁盘坏道,也并没有发现大量的坏道。

  三、备份数据

  考虑到数据的安全性以及可还原性,在做数据恢复之前需要对所有源数据做备份,以确保源数据的安全。使用Winhex将所有源磁盘都备份到指定的目标空间中。

  四、故障分析

  1、分析故障原因

  由于前两个步骤并没有检测到磁盘有物理故障或者是坏道,由此推断可能是由于某些磁盘读写不稳定导致故障发生。因为EVA控制器检查磁盘的策略很严格,一旦某些磁盘性能不稳定,EVA控制器就认为是坏盘,就将认为是坏盘的磁盘踢出磁盘组。而一旦某个LUN的同一个条带中掉线的盘到达极限,那么这个LUN将变的不可用。也就是如果EVA中所有的LUN都包含这些掉线的盘,那么这些LUN都会受影响。所以部分磁盘故障都会导致整个存储无法正常使用。

  2、分析LUN的结构

  HP-EVA的LUN都是以RAID条目的形式存储数据的,EVA将每个磁盘的不同块组成一个RAID条目,RAID条目的类型可以有很多种。我们需要分析出组成LUN的RAID条目类型,以及这个RAID条目是由哪些盘的哪些块组成。这些信息都存放在LUN_MAP中,每个LUN都有一份LUN_MAP。EVA将LUN_MAP分别存放在不同的磁盘中,使用一个索引来指定其位置。因此去每个磁盘中找这个指向LUN_MAP的索引就可以找到现存LUN的信息了。

  3、分析掉线磁盘

  在前面的故障分析中说了,虽然磁盘没有明显的物理故障,也没有磁盘坏道。但还是会因为性能的原因从EVA磁盘组中脱离。而这些脱离的磁盘中都存放的是一些旧的数据,因此在生成数据的时候需要将这些磁盘都排除掉。但是如何判断哪些磁盘是掉线的呢?由于LUN的RAID结构大多都是RAID5,只需要将一个LUN的RAID条目通过RAID5的校验算法算出校验值,再和原有的校验值做比较就可以判断这个条目中是否有掉线盘。而将一个LUN的所有LUN_MAP都校验一遍就可以知道这个LUN中哪些RAID条目中有掉线盘。而这些RAID条目中都存在的那个盘就一定是掉线盘。排除掉线盘,然后根据LUN_MAP恢复所有LUN的数据即可。

  五、恢复数据

  1、编写数据恢复程序

  上述的故障分析以及解决思路最终都需要使用编程来实现。编写扫描LUN_MAP的程序Scan_Map.exe,扫描全部LUN_MAP,结合人工分析得出最精确的LUN_MAP。编写检测RAID条目的程序Chk_Raid.exe,检测所有LUN中掉线的磁盘,结合人工分析排除掉线的磁盘。编写LUN数据恢复程序Lun_Recovery.exe,结合LUN_MAP恢复所有LUN数据。

  2、恢复所有LUN数据

  根据编写好的程序去实现不同的功能,最后使用Lun_Recovery.exe结合LUN_MAP恢复所有LUN的数据。然后人工核对每个LUN,确认是否和甲方工程师描述的一致。部分LUN的数据恢复如下图:

  3、恢复ORACLE ASM数据

  (1)     ASM磁盘组修复解析

  对EVA存储层恢复出来的LUN进行分析,重组ASM磁盘组,并对ASM磁盘组进行解析。

  总共有13个LUN,通过分析每个LUN前端的结构数据,可以根据ASM磁盘头结构来区分哪些LUN是属于ASM磁盘组的。通过分析,总共有2套ASM磁盘组。每个磁盘组包含的LUN中分区的情况如下图:

  

通过北亚自主开发的ASM结构解析工具,对每个磁盘组进行解析和修复。可以解析出此ASM中存储的所有数据库文件。

  (2)  数据库文件解析导出

  对解析出的数据库文件,分别按文件类型分组导出。对导出的文件进行初步检测。

  通过ASM解析工具恢复出所有的数据库文件。

  六、验证数据

  根据甲方工程师描述所有LUN的数据可以分成两大部份,一部份是Vmware的虚拟机,一部分是ORACLE上的ASM磁盘组数据,ASM磁盘组中存放的是Oracle的dbf数据库文件。由于我们恢复的是LUN,无法看到里面的文件,因此需要将这些LUN同过人工的核对哪些LUN是存放Vmware的数据,哪些是ASM设备,然后将LUN挂载到不同的验证环境中验证恢复的数据是否完整。

  1、部署Vmware虚拟机的验证环境

  在一台dell的服务器上安装了ESX5.5虚拟主机环境,然后通过iSCSI的方式将恢复的LUN挂载到虚拟主机上。在VMware vSphere Client 上扫描vmfs卷,但是发现客户的虚拟主机是ESX4.0的版本,可能因为版本的原因无法直接扫描到vmfs卷,于是换一种验证方式。将所有符合vmware虚拟机的LUN里面的虚拟机文件都生成出来,然后通过NFS共享的方式挂载到虚拟主机上,再将虚拟机一个一个的添加到清单。恢复的部分虚拟机文件如下图:

  2、验证vmfs虚拟机

  通过NFS将所有虚拟机都添加到虚拟主机以后,将所有虚拟机都加电开机,发现都能启动系统。将所有虚拟机都开机进入系统,验证虚拟机里面的数据都没问题。虚拟机的所有数据都恢复成功。部分虚拟机开机如下:

  3、部署Oracle数据库的验证环境

  为了ASM的恢复测试和后期的数据验证工作,需要先搭建好oracle 环境。

  根据甲方工程师提供的环境信息为linux,于是需要搭建同架构的兼容版本Oracle环境。

  以下是安装环境的简单步骤介绍:

  1. 环境检测

  # uname -all

  然后检查各部分存储空间信息,保证空间足够。

  2. 检测安装依赖包

  根据安装说明“  b19068.pdf  ”,检查 oracle10g 所需的补丁包。

  检测:

  # swlist-l bundle |grep "GOLD"

  # swlist-l patch |grep PHNE_31097

  如果没有检测到的,需要到官方网站下载并安装。 安装补丁包:

  swinstall -s /patchCD/GOLDQPK11i -x autoreboot=true -x patch_match_target=true

  3. 创建用户及组

  #groupadd dba

  #useradd -g dba -d /home/oracle oracle

  #passwd oracle

  4. 创建目录并修改权限

  创建目录:

  #mkdir –p/opt/oracle/product/10.2/oracledb

  #chown -R oracle:dba/opt/oracle

  修改权限:

  #chown oracle:dba/usr/oracle_inst/database/

  #chmod 755/usr/oracle_inst/database/

  5. 设置环境变量

  vi /home/oracle/.profile

  6. 安装oracle

  Oracle的安装要求起图形界面,所以要先测试图像界面能正常启动。

  #exoprt  DISPLAY=192.168.0.1.0:0

  $./runInstaller

  图像界面起来之后,先只安装软件,不安装实例。

  7. 测试数据库连接

  #su - oracle

  $sqlplus / as syssdba

  4、验证Oracle数据库

  (1)  验证数据库文件结构

  通过相同版本的oracle 官方检测工具DBV对导出的数据文件进行物理结构检测,以确定文件导出完好。

  通过对所有数据文件的验证,确定所有文件结构正确,没有结构性损坏。

  (2)  挂载启动数据库

  在上面数据库文件物理结构验证通过后,进行启动数据库,是数据库验证的最常用手段和步骤。

  通过一些迁移数据库的手段,修改控制文件中的路径,使oracle识别到这些数据库数据文件,然后按oracle正常步骤启动数据库。

  因为原来数据库实例是有2个,并且是使用的ASM存储。所以在创建数据库实例时,要按照原来配置和命名。

  在此环境下直接启动由于参数配置和数据文件路径变动,造成启动报错。需要对其进行修复。

  5、修复Oracle数据库

  故障修复

  通过一些迁移数据库的手段,修改控制文件中的路径,来让oracle识别到这些数据库数据文件,然后使oracle数据库按正常步骤启动。

  以下是dmis数据库启动的截图:

  以下是gsm数据库启动的截图:

  从此启动过程可以看出,整个启动过程正常进行,没有任何报错,基本说明数据库完好恢复。

  七、移交数据

  以及运行情况

  1、移交vmware虚拟机文件和Oracle数据库文件

  验证所有数据没有问题后,将vmware虚拟机文件和Oracle数据库文件拷贝至两块3TB的希捷硬盘中。然后再将拷贝好的数据移交给客户。

  2、运行情况

  客户接受数据后,将数据上传至后台,经检测观察,程序可正常运行,无问题。运行情况如下面所示。

运行规定

运行变更摘要

  八、数据恢复结论

  由于故障发生后保存现场环境良好,没用做相关危险的操作,对后期的数据恢复有很大的帮助。整个数据恢复过程中虽然遇到好多技术瓶颈,但也都一一解决。最终在预期的时间内完成整个数据恢复,恢复的数据甲方也相当满意。

  九、项目成员列表


工程师


姓名


电话


邮箱


商务


张晓娜


185,1528,3863


zxn#frombyte.com


项目主管


邓奇


185,1528,3878


dq#frombyte.com


初检工程师


张勇


185,1528,3869


zhangyong#frombyte.com


实施工程师


秦颖吉


185,1528,3871


qyj#frombyte.com


实施工程师


张勇


185,1528,3869


zhangyong#frombyte.com


实施工程师


邓奇


185,1528,3878


dq#frombyte.com


审核工程师


张宇

时间: 01-25

EVA 4400存储数据恢复报告的相关文章

分享一例EVA 4400存储硬盘故障数据恢复方案和数据恢复过程

EVA系列存储是一款以虚拟化存储为实现目的的HP中高端存储设备,平时数据会不断的迁移,加上任务通常较为繁重,所以磁盘的负载相对是较重的,也是很容易出现故障的.EVA是依靠大量磁盘的冗余空间,以及故障后rss冗余磁盘动态迁移来实现整个存储的数据保护,但随着越来越多的磁盘掉线,这种保护会接近临界,直至崩溃.下面以EVA存储故障为例,讲解EVA 4400存储数据恢复. 一.故障描述 整个EVA存储结构是由一台EVA4400控制器.EVA扩展柜及若干FC磁盘组成.由于磁盘故障导致存储中LUN不可用,致使

VSAN存储结构解析;存储数据恢复的成功案例分享

今天给大家介绍一的是一款常见存储设备-Vsan的结构原理,相对而言技术性文字较多.VSAN是一种以vSphere内核作为基础开发出来的一款可以扩展使用的分布式存储架构.这款存储在vSphere集群主机中安硬盘及闪存构建出VSAN存储层,通过存储进行管理与控制,最终形成一个共享存储层.伴随着计算机网络的快速发展,vsan的存储结构也在不断的更新换代过程中,传统的存储管理机制中的底层存储不了解虚拟化和文件系统,新一代的存储管理机制将更新为基于对象存储系统.虚拟数据存储.分布式存储.下图为vsan的存

某大学数据恢复报告

本案例详细介绍了数据库恢复的过程,包括RAID重组和数据库数据的修复与验证. 故障设备 IBM DS5020 光纤存储 故障描述 存储上一共16块FC硬盘,单盘容量600G.存储前面板10号和13号硬盘亮***故障灯,存储映射到redhat上的卷挂载不上,业务崩溃. 存储恢复流程 通过IBM storage manager连接到存储查看当前存储状态,存储报告逻辑卷状态失败,再查看物理磁盘状态,发现6号盘报告"警告",10号和13号盘报告"失败",通过IBM stor

某省云数据中心数据恢复报告

一.故障描述 机房突然断电导致整个存储瘫痪,加电后存储依然无法使用.经过用户方工程师诊断后认为是断电导致存储阵列损坏.整个存储是由12块日立硬盘(3T SAS硬盘)组成的RAID-6磁盘阵列,被分成一个卷,分配给几台Vmware的ESXI主机做共享存储.整个卷中存放了大量的Windows虚拟机,虚拟机基本都是模板创建的,因此系统盘都统一为160G.数据盘大小不确定,并且数据盘都是精简模式. 二.备份数据 将故障存储的所有磁盘和备份数据的目标磁盘连入到一台Windows Server 2008的服

HP P2000RAID-5两块盘离线的数据恢复报告

1. 故障描述 存储:HP P2000的存储 操作系统:VMWARE ESX 文件系统:VMFS 磁盘阵列:RAID-5 本案例的RAID-5由10块lT硬盘组成,其中6号盘是热备盘,由于故障导致RAID-5磁盘阵列的两块盘掉线,表现为两块硬盘亮黄灯. 经用户方维护人员检测,故障硬盘应为物理故障,表现为:序列号无法读取,在SAS扩展卡上硬盘无法识别. 2. 数据备份与修复 故障发生后用户方工程师与我公司(北亚数据恢复中心)联系,经过详细咨询,了解到故障比较严重,必须把RAID-5磁盘阵列带到我公

HP-lefthand存储结构分析 / P4500存储数据恢复案例

一.HP-lefthand存储结构介绍 HP-lefhand存储支持搭建RAID5.RAID6.RAID10磁盘阵列,同时还支持卷快照,卷动态扩容等.在存储市场上占有量很大,但是基于存储的自身结构等方面因素也具有非常高的数据恢复需求,服务端和客户端分别如下: Lefthand存储共有三个级别,分别为:物理磁盘.基于多个物理磁盘组成的逻辑磁盘(raid磁盘阵列).由不同的raid阵列组成的逻辑卷. 不同raid阵列中的多个不连续的片段组成为卷,用户的数据即存储在这一空间中,可用于存储文件系统和用户

V7000存储底层结构拆原理+V7000存储数据恢复案例

Storwize V7000(也就是我们常说的V7000)是新推出的一款中端存储系统,这款系统的定位虽然在中端,但是Storwize V7000提供有存储管理功能,这一功能以前只有高端存储才拥有(例如 Storwize V3700,Storwize V5000).底层存储结构支持:RIAD 0/RAID 10/RAID5/RAID 6上层卷支持:普通卷/精简模式的卷/镜像模式的卷/精简镜像模式的卷本文将为大家展示V7000存储的结构原理.配置方法以及Mdisk磁盘掉线的数据恢复方法.[V7000

DELL EqualLogic PS6100存储数据恢复成功案例

DELL EqualLogic PS6100采用虚拟ISCSI SAN阵列,为远程或分支办公室.部门和中小企业存储部署带来企业级功能.智能化.自动化和可靠性.以简化的管理.快速的部署及合理的价格满足了分支办公室和中小企业的存储需求,同时提供全套企业级数据保护和管理功能.可靠的性能.可扩展性和容错功能,是中型企业级存储的起点产品,但某些物理故障或其他操作都可能会对卷或存储造成破坏,因此对系列存储的数据恢复技术才有了用武之地.而发生这些故障之后只能找专业的数据恢复公司做数据挽救工作.北亚数据恢复中心

Mysql数据库delete删除后数据恢复报告

数据库环境部署与故障原因: 本次恢复的数据库安装在客户本地服务器上,服务器操作系统为windows2008 r2 .在当前环境内安装有mysql5.6单实例,引擎类型为innodb,表内数据存储所使用表空间类型为独立表空间.未进行数据库备份,未开启binlog.导致数据丢失的原因是由于人为误操作使用Delete命令进行删除数据时未添加where子句进行筛选导致全表数据被删除,删除后未对该表进行任何操作,需要从数据库层面进行误删除的数据恢复操作. 数据恢复方案制定: 1.故障类型分类:在本案例中,