EVA 4400存储硬盘故障导致数据丢失怎么恢复?

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介:

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

  3、恢复ORACLE ASM数据
  (1) ASM磁盘组修复解析
  对EVA存储层恢复出来的LUN进行分析,重组ASM磁盘组,并对ASM磁盘组进行解析。
总共有13个LUN,通过分析每个LUN前端的结构数据,可以根据ASM磁盘头结构来区分哪些LUN是属于ASM磁盘组的。通过分析,总共有2套ASM磁盘组。每个磁盘组包含的LUN中分区的情况如下:
图二:
2

图三:
3
  
通过ASM结构解析工具,对每个磁盘组进行解析和修复。可以解析出此ASM中存储的所有数据库文件。
图四:
4
  (2) 数据库文件解析导出
对解析出的数据库文件,分别按文件类型分组导出。对导出的文件进行初步检测。
图五:
5

  通过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共享的方式挂载到虚拟主机上,再将虚拟机一个一个的添加到清单。恢复的部分虚拟机文件如下:
图六:
6
  2、验证vmfs虚拟机
通过NFS将所有虚拟机都添加到虚拟主机以后,将所有虚拟机都加电开机,发现都能启动系统。将所有虚拟机都开机进入系统,验证虚拟机里面的数据都没问题。虚拟机的所有数据都恢复成功。部分虚拟机开机如下:
图七:
7

  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/frombyte
  #passwd oracle
  4. 创建目录并修改权限
  创建目录:
  #mkdir –p/opt/oracle/product/10.2/oracledb/
  #chown -R oracle:dba/opt/oracle
  修改权限:
  #chown oracle:dba/usr/oracle_inst/database/frombyte.com
  #chmod 755/usr/oracle_inst/database/frombyte.com
  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对导出的数据文件进行物理结构检测,以确定文件导出完好。
图八:
8

  通过对所有数据文件的验证,确定所有文件结构正确,没有结构性损坏。
  (2) 挂载启动数据库
  在上面数据库文件物理结构验证通过后,进行启动数据库,是数据库验证的最常用手段和步骤。
  通过一些迁移数据库的手段,修改控制文件中的路径,使oracle识别到这些数据库数据文件,然后按oracle正常步骤启动数据库。
  因为原来数据库实例是有2个,并且是使用的ASM存储。所以在创建数据库实例时,要按照原来配置和命名。
  在此环境下直接启动由于参数配置和数据文件路径变动,造成启动报错。需要对其进行修复。
  5、修复Oracle数据库
  故障修复
  通过一些迁移数据库的手段,修改控制文件中的路径,来让oracle识别到这些数据库数据文件,然后使oracle数据库按正常步骤启动。
以下是dmis数据库启动的截图:
图九:
9

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

  从此启动过程可以看出,整个启动过程正常进行,没有任何报错,基本说明数据库完好恢复。
  七、移交数据
  以及运行情况
  1、移交vmware虚拟机文件和Oracle数据库文件
  验证所有数据没有问题后,将vmware虚拟机文件和Oracle数据库文件拷贝至两块3TB的希捷硬盘中。然后再将拷贝好的数据移交给客户。
  2、运行情况
客户接受数据后,将数据上传至后台,经检测观察,程序可正常运行,无问题。运行情况如下面所示。
图十一:
11

图十二:
12

图十三:
13

运行规定
图十四:
14

图十五:
15

运行变更摘要
图十六:
16

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

相关文章
|
3月前
|
存储 安全 数据挖掘
服务器数据恢复—异常断电导致EVA存储中RAID信息丢失的数据恢复案例
意外断电导致raid硬件损坏或者riad管理信息丢失等raid模块损坏而导致数据丢失的情况非常普遍。正常情况下,磁盘阵列一旦创建完成就不会再对管理模块中的信息进行更改,但是raid管理模块中的信息属于可修改信息,一次或多次的意外断电可能会导致这部分信息被篡改或丢失。断电次数过多甚至会导致raid卡上的元器损坏。
|
5月前
|
存储 运维
服务器数据恢复—EqualLogic存储硬盘出现故障的数据恢复案例
服务器数据恢复环境: 一台某品牌EqualLogic PS 6011型号存储,底层有一组由16块SAS硬盘组建的RAID5阵列,上层存储空间划分了4个卷,格式化为VMFS文件系统,存放虚拟机文件。 服务器故障: 存储设备上两块硬盘指示灯显示黄色,磁盘出现故障导致存储不可用,存储已经过保,用户方联系北亚企安数据恢复中心要求恢复数据。
服务器数据恢复—EqualLogic存储硬盘出现故障的数据恢复案例
|
2月前
|
Oracle 关系型数据库 数据挖掘
服务器数据恢复—硬盘坏道导致raid5阵列崩溃的数据恢复案例
一台ibm x3850服务器,有一组由5块硬盘组建的raid5磁盘阵列,上层是Redhat Linux操作系统,部署了一个oracle数据库。 raid5阵列中2块硬盘离线,阵列崩溃。经过检测发现该raid中的热备盘未激活,硬盘无物理故障,无明显同步表现。
服务器数据恢复—硬盘坏道导致raid5阵列崩溃的数据恢复案例
|
2月前
|
存储 运维 Windows
服务器数据恢复—V7000存储磁盘阵列柜进水导致故障的数据恢复案例
一台v7000存储机头+7个磁盘阵列柜,阵列柜上共有80块SAS机械硬盘,这些磁盘组建了8组Mdisk,加到一个pool中,一共分配了13个lun。服务器安装Windows server操作系统,格式化为NTFS文件系统,存放的数据主要是影像图片资料。
服务器数据恢复—V7000存储磁盘阵列柜进水导致故障的数据恢复案例
|
3月前
|
存储 负载均衡 算法
服务器数据恢复—EVA存储介绍&常见故障和数据恢复
EVA存储常见故障: 1、RSS中多个磁盘掉线,超过冗余保护级别。 2、加入新磁盘,进行数据迁移时,新磁盘存在物理故障。 3、VDISK被删除或EVA初始化。 4、突发性主机与存储无法连接。无法discover存储。
服务器数据恢复—EVA存储介绍&常见故障和数据恢复
|
2月前
|
SQL 数据库 数据安全/隐私保护
服务器数据恢复—raid5阵列故障因操作不当导致数据无法恢复的案例
服务器数据恢复环境: 一台服务器中有一组由4块SCSI硬盘组建的raid5磁盘阵列,划分了一个逻辑卷,操作系统为WINDOWS SERVER,作为SQL SERVER服务器使用。 服务器故障: 运行过程中该服务器raid5磁盘阵列瘫痪,管理员检查服务器发现raid5阵列中已经有3块磁盘离线。管理员选择其中2块离线硬盘进行强制上线操作,强制上线后操作系统无法启动。使用WINPE光盘启动操作系统后,可以看到数据。
|
4月前
|
数据挖掘 数据库
服务器数据恢复—服务器raid磁盘故障离线导致阵列瘫痪的数据恢复案例
服务器数据恢复环境: 一台某品牌DL380服务器中3块SAS硬盘组建了一组raid。 服务器故障: RAID中多块磁盘出现故障离线导致RAID瘫痪,其中一块硬盘状态指示灯显示红色。服务器上运行的数据库在D分区,备份文件存放在E分区。由于RAID瘫痪,D分区无法识别,E分区可识别但是拷贝文件报错。管理员重启服务器,导致RAID中先离线的硬盘上线并开始同步数据,同步没有完成管理员意识到有问题,于是就强制关机了,之后就没有再动过服务器。
服务器数据恢复—服务器raid磁盘故障离线导致阵列瘫痪的数据恢复案例
|
3月前
|
数据挖掘
服务器数据恢复—RAID5阵列重建导致原raid数据丢失的数据恢复案例
一台服务器,有一组由5块硬盘组建的raid5磁盘阵列。 服务器在运行过程中一块有磁盘掉线,由于raid5阵列支持一块磁盘掉线的特性,服务器还在正常工作。不久之后服务器出现故障,管理员在不了解raid配置情况下,以原raid5阵列中的4块盘作为成员盘重建了raid5阵列。结果原raid5阵列中的全部数据丢失。
|
5月前
|
存储 Oracle 关系型数据库
服务器数据恢复—EVA存储raid5阵列多块硬盘离线导致存储崩溃的数据恢复案例
服务器数据恢复环境: 1台某品牌EVA4400控制器+3台EVA4400扩展柜+28块FC硬盘。 服务器故障: 由于两块磁盘掉线导致存储中某些LUN不可用,某些LUN丢失,导致存储崩溃。
服务器数据恢复—EVA存储raid5阵列多块硬盘离线导致存储崩溃的数据恢复案例
|
5月前
|
存储 运维 算法
EVA数据恢复—EVA存储中磁盘掉线导致LUN不可用的数据恢复案例
EVA存储数据恢复环境: EVA控制器+三个扩展柜+数十块FC硬盘。 EVA存储故障&检测: 磁盘掉线导致存储中的部分LUN丢失,部分LUN损坏不可用。 由于是磁盘掉线导致存储中的LUN不可用。拿到所有磁盘后,先由硬件工程师对所有磁盘做物理故障检测,经过检测,没有发现有硬盘存在物理故障,都可以正常读取。使用坏道检测工具检测磁盘坏道,也没有发现有硬盘存在坏道。
EVA数据恢复—EVA存储中磁盘掉线导致LUN不可用的数据恢复案例