EVA4400存储硬盘故障数据恢复方案和数据恢复过程.docx

EVA4400存储硬盘故障数据恢复方案和数据恢复过程.docx

《EVA4400存储硬盘故障数据恢复方案和数据恢复过程.docx》由会员分享，可在线阅读，更多相关《EVA4400存储硬盘故障数据恢复方案和数据恢复过程.docx（17页珍藏版）》请在冰点文库上搜索。

EVA4400存储硬盘故障数据恢复方案和数据恢复过程

EVA4400存储硬盘故障数据恢复方案和数据恢复过程

　　EVA系列存储是一款以虚拟化存储为实现目的的HP中高端存储设备，平时数据会不断的迁移，加上任务通常较为繁重，所以磁盘的负载相对是较重的，也是很容易出现故障的。

EVA是依靠大量磁盘的冗余空间，以及故障后rss冗余磁盘动态迁移来实现整个存储的数据保护，但随着越来越多的磁盘掉线，这种保护会接近临界，直至崩溃。

下面以EVA存储故障为例，讲解EVA4400存储数据恢复。

一、故障描述

　　整个EVA存储结构是由一台EVA4400控制器、EVA扩展柜及若干FC磁盘组成。

由于磁盘故障导致存储中LUN不可用，致使上层应用无法正常使用。

二、检测磁盘

　　由于EVA4400是因为某些磁盘故障导致整个存储不可用，因此接收到磁盘以后先对所有磁盘做物理检测，检测完后发现磁盘并没有物理故障。

接着使用坏道检测工具检测磁盘坏道，也并没有发现大量的坏道。

三、备份数据

　　考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以确保源数据的安全。

使用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.jpg

3、恢复ORACLEASM数据

（1）ASM磁盘组修复解析

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

总共有13个LUN，通过分析每个LUN前端的结构数据，可以根据ASM磁盘头结构来区分哪些LUN是属于ASM磁盘组的。

通过分析，总共有2套ASM磁盘组。

每个磁盘组包含的LUN中分区的情况如下：

图二：

2.jpg

图三：

3.jpg

通过ASM结构解析工具，对每个磁盘组进行解析和修复。

可以解析出此ASM中存储的所有数据库文件。

图四：

4.jpg

（2）数据库文件解析导出

对解析出的数据库文件，分别按文件类型分组导出。

对导出的文件进行初步检测。

图五：

5.jpg

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

六、验证数据

　　根据甲方工程师描述所有LUN的数据可以分成两大部份，一部份是Vmware的虚拟机，一部分是ORACLE上的ASM磁盘组数据，ASM磁盘组中存放的是Oracle的dbf数据库文件。

由于我们恢复的是LUN，无法看到里面的文件，因此需要将这些LUN同过人工的核对哪些LUN是存放Vmware的数据，哪些是ASM设备，然后将LUN挂载到不同的验证环境中验证恢复的数据是否完整。

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

在一台dell的服务器上安装了ESX5.5虚拟主机环境，然后通过iSCSI的方式将恢复的LUN挂载到虚拟主机上。

在VMwarevSphereClient上扫描vmfs卷，但是发现客户的虚拟主机是ESX4.0的版本，可能因为版本的原因无法直接扫描到vmfs卷，于是换一种验证方式。

将所有符合vmware虚拟机的LUN里面的虚拟机文件都生成出来，然后通过NFS共享的方式挂载到虚拟主机上，再将虚拟机一个一个的添加到清单。

恢复的部分虚拟机文件如下：

图六：

6.jpg

2、验证vmfs虚拟机

通过NFS将所有虚拟机都添加到虚拟主机以后，将所有虚拟机都加电开机，发现都能启动系统。

将所有虚拟机都开机进入系统，验证虚拟机里面的数据都没问题。

虚拟机的所有数据都恢复成功。

部分虚拟机开机如下：

图七：

7.jpg

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

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

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

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

　　1.环境检测

　　#uname-all

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

　　2.检测安装依赖包

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

　　检测：

　　#swlist-lbundle|grep"GOLD"

　　#swlist-lpatch|grepPHNE_31097

　　如果没有检测到的，需要到官方网站下载并安装。

安装补丁包：

　　swinstall-s/patchCD/GOLDQPK11i-xautoreboot=true-xpatch_match_target=true

　　3.创建用户及组

　　#groupadddba

　　#useradd-gdba-d/home/oracleoracle/frombyte

　　#passwdoracle

　　4.创建目录并修改权限

　　创建目录：

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

　　#chown-Roracle:

dba/opt/oracle

　　修改权限：

　　#chownoracle:

dba/usr/oracle_inst/database/

　　#chmod755/usr/oracle_inst/database/

　　5.设置环境变量

　　vi/home/oracle/.profile

　　6.安装oracle

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

　　#exoprtDISPLAY=192.168.0.1.0:

0

　　$./runInstaller

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

　　7.测试数据库连接

　　#su-oracle

　　$sqlplus/assyssdba

4、验证Oracle数据库

（1）验证数据库文件结构

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

图八：

8.jpg

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

（2）挂载启动数据库

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

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

　　因为原来数据库实例是有2个，并且是使用的ASM存储。

所以在创建数据库实例时，要按照原来配置和命名。

　　在此环境下直接启动由于参数配置和数据文件路径变动，造成启动报错。

需要对其进行修复。

5、修复Oracle数据库

　　故障修复

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

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

图九：

9.jpg

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

图十：

10.jpg

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

七、移交数据以及运行情况

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

　　验证所有数据没有问题后，将vmware虚拟机文件和Oracle数据库文件拷贝至两块3TB的希捷硬盘中。

然后再将拷贝好的数据移交给客户。

2、运行情况

客户接受数据后，将数据上传至后台，经检测观察，程序可正常运行，无问题。

运行情况如下面所示。

图十一：

11.jpg

图十二：

12.jpg

图十三：

13.jpg

运行规定

图十四：

14.jpg

图十五：

15.jpg

运行变更摘要

图十六：

16.jpg

八、数据恢复结论

　　由于故障发生后保存现场环境良好，没用做相关危险的操作，对后期的数据恢复有很大的帮助。

整个数据恢复过程中虽然遇到好多技术瓶颈，但也都一一解决。

最终在预期的时间内完成整个数据恢复，恢复的数据甲方也相当满意。