公司HPEVA4400存储硬盘离线数据恢复方法

1、公司HP-EVA4400HP-EVA4400存储硬盘离线数据恢复方法工故障描述整个EVAff储结构是由一台EVA4400空制器，三台EVA440CT展柜和28块FC300G硬盘构成的。由于两块磁盘掉线导致存储某些LUN不可用，某些LUNg失。由于EVA4400是因为某些磁盘掉线，从而导致整个存储不可用。因此接收到磁盘以后北亚工程师先对所有磁盘做物理检测，检测完后发现没有物理故障。接着使用坏道检测工具检测磁盘坏道，发现也没有坏道。磁盘坏道检测日志如下图：三口00Ug2Q14-10-1QUg2Q14-10-1QW乒mt中14,14,MlMl一门Ltg30-10,12011/I0JK,.O.ooit

2、LtLegSO14-10-10,D7_5：_ie.匕七SCiVlO/lt.O.onincLogsoil-：0-io,07_5_155txtSoWWK.ClQIUnrLosSOK-iOlO,DT_53_Z3,txtzoH.aoHt_tloftinrLeg：2014-.0-LU,UT_5。.StnmfLag201i-LD-lD口7_%_壬.tzt2DU/t(/JC.口20IQ7QTQ,QT.55.50,Ut201VI0/7(O.?iiiLL.Jg03!4；01CJD7_50_.UItU/LO/j(jdoaicktUM14-10-10,DS_0O_27,Utaowao/Jt一口。niy20U-JO-

3、10.1LQ31,EjaoninrLacZOU-iD,10JQ3J51.titSD14/L0/K门L*L*g ggOMTO-lgOMTO-l必QT_4T_F3QT_4T_F3*-*-记单不文件日)例格式O,当若犁劲面boi4/10/10,15:47:53,5即为 5 网的-:CEO8,1 眠M?dr0-Bnginniroffi1c585f537,5 口。fr?mbyte2014/10/10,17:44:27,75SEJ37J500teeterCs)f?llyfrornby15JleadsourseItointteEiicarjnterE(;.:、备份数据考虑到数据的安全性以及可还原性，在做数据

4、恢复之前需要对所有源数据做备份，以防万一操作不当导致数据无法再次恢复。使用winhex将所有磁盘都镜像成文件，源磁盘的内容数量多，在做数据备份的时候要花费很长时问。备份完部分数据如下图：,OKGB.img2014/10/1019124IMG文件292,968,.OKGDimg400650364616:54工MG文件292,963,.,OJCOE.img2014/10/1019:24IMG文件292,968,.|OKIAimg400650564617:56工MG文件292,96.0s04.imimE014/10/101913工帕文件29968,.,1OJCGT.img2014/10/1017:5

5、6IMG文件292,968,.,0KQ940055056461743IMG文件292,963,.-M14.inig2014/10/1021:50IMG文件292,363,.OJC10.img2014/10/1021:59IMG文件徵9 9昵一11GKIS.img201V10/10工MG文件盟邨也.三、故障分析及恢复过程1、分析故障原因由于前两个步骤并没有检测到磁盘有物理故障或者是坏道，由此推断可能是由于某些磁盘读写不稳定导致故障发生。因为EVA空制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定，EVA控制器就认为是坏盘，就将认为是坏盘的磁盘踢出磁盘组。而一旦某个LUN的同一个条带中掉线的盘到达

6、极限，那么这个LUN将不可用。即如果EVA中所有的LUN都包含这些掉线的盘，所有LUN都会受影响。掉线两块盘导致整个存储的LUN都不可用的情况就很正常了。 而目前的情况是现存8个LUN,损坏7个LUN,丢失6个LUN需要恢复所有LUN的数据。2、分析LUN的结构HP-EVA的LUN都是以RAID条目的形式存储数据的，EVA将每个磁盘的不同块组成一个RAID条目，RAID条目的类型可以有很多种。我们需要分析出组成LUN的RAID条目类型，以及这个RAID条目是由哪些盘的哪些块组成。 这些信息都存放在LUN_MA叩,每个LUN都有一份LUN_MAPEVA将LUN_MA分别存放在不同的磁盘中，使用一

7、个索引来指定其位置。因此去每个磁盘中找这个指向LUN_MAp勺索弓|就可以找到现存LUN的信息了。3、分析丢失的LUN虽然磁盘中记录了指向LUN_MAP勺索引，但是它只记录现存的LUN,丢失的LU睚不会记录索引的。由于EVA中删除一个LUN只会消除这个LUN勺索弓而不会清除这个LUN的LUN_MA璘时需要扫描所有磁盘找到所有符合LUN_MAP的数据块，然后排除掉现有的LUN_MA网下的LUN_MA也不一定全是删除的，也有一些是以前旧的，但此时是无法在LUN_MA叩筛选了,只能通过程序将所有LUN_MAp勺数据都恢复出来，人工的去核对哪些LUN是删除的。4、分析掉线磁盘在前面的故障分析中说了，虽

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

9、故障分析以及解决思路最终都需要使用编程来实现。编写扫描LUN_MAP勺程序Scan_Map.exe,扫描全部LUN_MAP结合人工分析得出最精确的LUN_MAP编写检测RAID条目的程序Chk_Raid.exe,检测所有LUN中掉线的磁盘，结合人工分析排除掉线的磁盘。编写LUN8：据恢复程序Lun_Recovery.exe,结合LUN_MA恢复所有LUN数据。6、恢复所有LUN数据根据编写好的程序去实现不同的功能，最后使用Lun_Recovery.exe结合LUN_MA恢复所有LUN的数据。然后人工核对每个LUN确认是否和甲方工程师描述的一致。部分LUN的数据恢复如下图：1Linc2Q1VJU

10、/L223:3B二股交件LiWyJlb.ELUIwS-inf4H利田希0出亚文件715,2C0电2&14/10/13141I格又坏209,715.SCOnlijztT.ing4融5(1934&2161%文件5M,型%OCO灯i个耳OM/1Q/L323&二呻文件15Vli我民4EXB|_jl?ny.inc4UU55Ubt5462S5MS文件15L-400HI,l?nlO.ing2014/J0/L33.皿文件524,士白&OCOZBing2014/10/134SB丽文件1ST,邛64n灯l?iilT.ing2014/10/LO0M:蝌文件3】、FT晶MDD四、数据验

11、证根据甲方工程师描述所有LUN的数据可以分成两大部份， 一部份是Vmware的虚拟机，一部分是HP-UX上的裸设备， 裸设备里存放的是Oracle的dbf数据库。 由于我们恢复的是LUN,无法看到里面的文件，因此需要将这些LUN同过人工的核对哪些LUN是存放Vmware的数据，哪些是HP-UX的裸设备。然后将LUN挂载到不同的验证环境中验证恢复的数据是否完整。1、部署Vmware虚拟机的验证环境在一台dell的服务器上安装了ESXI5.5虚拟主机环境，然后通过iSCSI的方式将恢复的LUN挂载到虚拟主机上。但是在VMwarevSphereClient上扫描vmfs卷，没有发现。后来发现客户的虚

12、拟主机是EXSI3.5的版本。可能因为版本的原因无法直接扫描到vmfs卷,于是换一种验证方式。 将所有符合vmware虚拟机的LUN里面的虚拟机文件都生成出来，然后通过NFS共享的方式挂载到虚拟主机上，然后将虚拟机一个一个的添加到清单。恢复的部分虚拟机文件如下图：12c电觊I文件关20L%写iEl1003EgTiEgJg12 三23.242文洋史2014/521439文#走BOL4/10/1EL3ZT21空#定SDL4/WJ/1EL329文件夹SQL4/1QZ1.L4的.-QUHUHUslMniKu-LLO.J2X不江件夷SQM/W13L3力汨0曰工i5rqMUCi0寸

13、主011加，18力Mtx匚皿srY k!D.IS2整交忤奇珈5倒10*口4.华3？2-，加二口：23.软4交件吉SOM/WM1502心於 7Mmiss女停工SQtVWigL4幅.J0L215我共加14/WIE13ST4O【LLj啕皿也WCtft讨5MS产件工SQ1U】聊14玉“|电皿5副产口1292孤快就iU，3踹10史wff3_SI守中啦HEEmEr%文件在SQIVUIIKL3wQ2_ltv.lLkkJ0.f3235却噢SlVltVlKL3安於WEBID的wnViluM1JL：LJ.2J4119文4线道nV】明止L3JI2、验证vmfs虚拟机通过NFS将所有虚拟机都添加到虚拟主机以后，将所有

14、虚拟机都加电开机，发现都能启动系统。由于没有开机密码无法确认虚拟机里面的文件是否完整。后来甲方安排工程师通过远程到我们的服务器，将所有虚拟机都开机进入系统，验证虚拟机里面的数据都没问题。虚拟机的所有数据都恢复成功3、部署Oracle数据库的验证环境为了裸设备恢复测试和后期的数据验证工作，需要先搭建好oracle环境。根据甲方工程师提供的环境信息为HP小机Itanium架构， 我公司HP小机为RX2660(Itanium2),是同架构的兼容版本。于是计划在此机器上安装oracle单实例软件。部分虚拟机开机如下:软件平台：信息项目HP-UXB.11.31Oracle.0Enterp

15、riseEdition-64bitforHPUX以下是安装环境的简单步骤介绍：1 .环境检测#uname-allHP-UXbyhpux1B.11.31Uia641447541358unlimited-userlicense本机为IA64架构， 操作系统为HP-UX,版本为B.11.31。然后检查各部分存储空间信息，保证空间足够。2.检测安装依赖包根据安装说明“b19068.pdf，检查oracle10g所需的补丁包。检测：#swlist-lbundle|grepGOLD#swlist-lpatch|grepPHNE_31097如果没有检测到的，需要到官方网站下载并安装。安装补丁包：swinst

16、all-s/patchCD/GOLDQPK11i-xautoreboot=true-xpatch_match_target=true3 .创建用户及组#groupadddba#useradd-gdba-d/home/oracleoracle#passwdoracle4 .创建目录并修改权限创建目录：#mkdir-p/opt/oracle/product/10.2/oracledb#chown-Roracle:dba/opt/oracle/修改权限：#chownoracle:dba/usr/oracle_inst/database/#chmod755/usr/oracle_inst/databa

17、se/5 .设置环境变量vi/home/oracle/.profile操作系统数据库6 .安装oracleOracle的安装要求起图形界面,所以要先测试图像界面能够正常启动。#exoprtDISPLAY=.0:0$./runInstaller图像界面起来之后的安装就比较简单了，这里只安装软件，不安装实例。7 .测试数据库连接#su-oracle$sqlplus/assyssdba4、验证Oracle数据库1、挂载裸设备由于有部分LUN是裸设备，而我们恢复的LUN都是以文件的形式存在。因此需要将文件形式的LUN挂载到HP-UXLho在HP-UX务器上安装iSCSIIniti

18、ator,安装步骤如下：检测软件包是否完整#swlist-d/tmp/B.11.31.03d_iSCSI-00_B.11.31.03d_HP-UX_B.11.31_IA_PA.depot安装软件包#swinstall-xautoreboot=true-s/tmp/B.11.31.03d_iSCSI-00_B.11.31.03d_HP-UX_B.11.31_IA_PA.depotiSCSI-00将iSCSI的可执行文件添加到PATH#PATH=$PATH:/opt/iscsi/bin/检测iSCSI是否安装成功#iscsiutil-l配置iSCSI的启动器名称#iscsituil/dev/isc

19、si-i-Niqn.2014-10-15:LUN配置挂载目标iSCSI设备#iscsiutil-a-I删除目标iscsi设备#iscsiutil-d-I验证目标iSCSI是否挂载成功#iscsiutil-pD发现目标target设备#/usr/sbin/ioscan-H255为目标创建设备文件#/usr/sbin/insf-H2552、导入外部VG信息创建VG节点#mkdir/dev/vgscope/创建VG设备文件名#mknod/dev/vgscope/groupc640 x030000查看PV是否正常#pvdisplay-l/dev/dsk/c2t0d0

20、/将PV导入VG中#vgimport-v/dev/vgscope/dev/dsk/c2t0d0激活VG信息#vgchange-ayvgscope查看VG信息#vgdisplay-vvgscope#vqdisplay-vvqscopeVol?megro?psVGUame/dev/vgscopeWWriteAccessVSStat?savailableMaxPcombinze255C?rLV5656*5W56MaxFV16C?rFV4ACEPV4MaxPEper出25599VG谑EcczLbyte&FESize(Mbytes)4PE102396AllocPE82205FreeFrombyt

21、e201S7TotalPVG0TotalSpar-ePVsTotalSparePVsin?ae0VGVersion1,C.C1,C.C3、修改LV名称由于是在新的环境上重建的VG然后再将PV导入到新建的VG中。 因此LV的名称全部都改变了，需要手动的去将LV的名称都改成和以前一下的。因为原来数据库实例是有2个，并且是使用的裸设备存储。所以在创建数据库实例时，要按按照原来配置和命名。文件系统层面，在同时协助下，挂载了所有LV,并修改权限I$pwd/d&vcraidtaS11总数0brw-r-1o-raeledba4 OX050DQ310月16日1514SODS_NEW3hiw-r1o-r

22、acledba640 x0500021。月后日14:53ODS_NEW4hrw-r1o-racledba64QX0SU0091口月16日14:58ODS_NCT5br?-r1a-raeledtea640 x0500071。月15日17i33UNDOTBS021bT?-r*-1oraeledha64OK050D091。月工6日0；17 OTTD0TBS031sbxwr-1o-racledba石4OxCECDCia“月日0-6:17U1TDOTBEO51brw-r-1oracledba64oxosaoob1口月15日0-7:48mnxriBS43erw-r-r-1&racledbaE40

23、x05000010月15日07:48Ftombytehrw-r-一-一1t&otaya54OxCSCOOc10月工6日mIvback?p；bxwr1o-racledba64Qxcsaooi1。月15日0748Ivdataczw-r-1o-racledba4 0 x0500031。月15日0?:48rODS_NEW3cxw-z-1 Graciedha640 x(1500021口月工5日07:48ZODSZNEKIGZW-E1racledta64口M5Q口。9月邮0743zODS_E；EW5CJWI?1QNGR北口SqxOSQQOT1口月15日Q7：4S工UNPQIB5口ciw-r-1o-

24、racledba64oxosaaaa1U月15日07:45Frajnbyte31crw=1&racle640 xtl5000a1。月15日07:48rJNDOTBS05LGiw-r1oracledba64OxO5CO0b1心月工S日07；48rUNDOIBS021civr1roorays640 x05000c10月15日(n；4sr7HiXOT3021ciw-r一1o-racledba64oxosaooi10月15日Q7：48rJITEOTESOJlcrwgi1oracledba640 x05000510月18日07:48fYojftbyre51LN一 K 一一一 1r?w?e.Ari

25、Trn;nfin; 1n日T5口n咛，M口r-1-aFFE力安装数据库实例，根据原始配置，在客户DBAft、助下，安装并识别到所有裸设备文件。然后调整配置参数，检测数据库存储状态，为启动数据库做准备。*la/4七J，vise:口1七cantroIOlecmtzfiLOZFT01WCEgro?plj；0q_Lh二二。9一13工*二QU*Iv_10Z3IT*01j?serlv_i55_DL工_5gJ3l1匚5叮_口2lv_5ig_a3lv_Sg_D4lvindei_LDij_0i2rcDatfoLJLFitiab/Le2tCHfiTTfll.33T40QL工久白02H1003rlv_LD5_0L工

26、1二心口1rlv_l口gJJ?rlLDfJ3rlv_L3g_04rlv_LDg_05rlvLDg7o6rimog_L3:=Dg_lPxlv_LDg_2更工二Dg_2O3g_3rly_LDg_Ciali*rlL3g_caiwL；Cljlr_L3g_?j=rivl?gijierjr*v_Lbg_LH工二二5口工iEJcl3rLv2l5gj32rLLSgcliEkllrlL5g33rlv_lg_03ELTQJ31rLv_2Dg_14rlv_3D3M_01E 甘二肌口；口rlV_3DDM_03IT=y_5q02iLv5g34rLv_5startupmount;SQLselectfile#,errorf

27、romv$recover_file;-查损坏的文件.没有损坏的文件。SQLALTERDATABASEOPEN;启动没有报错，但是缓慢，之后查询了用户，随机查询了一个用户的两张表，数据结果集返回正常。然后连接突然中断，重新连接，查看状态为数据库关闭。再启动数据库，还是启动不了，会强制关闭。经过初步检测和常规恢复库状态，不能修复此问题。2.验证NJYY数据库将环境变量切换到另一个数据库NJYYopen数据库时报错内存不足错误， 不能开启数据库。经初步检测检测，数据文件没有损坏。SQLstartupmount;SQLselectfile#,errorfromv$recover_file;SQLALT

28、ERDATABASEOPEN;error4030detectedinbackgroundprocess5、修复Oracle数据库1.故障修复对于scope数据库，根据上面的操作和故障现象，初步判断是undo表空间或者日志方面有问题。对数据文件做完整性和一致性检测，结果只有一个undo01.dbf文件损坏。确定是undo表空间损坏。通过命令删除掉损坏的undo表空间，又在原来位置重建。检测其他部分文件，没有发现问题。重新启动数据库，正常启动，做查询数据，正常，做了完整性检测，正常。接着做imp数据库全库导出，经过3个多小时正常导出全库数据库。对于NJYY数据库，检测到是内存空间设置不对，经过命令

29、调整，数据库恢复正常，能正常启动，正常使用。最后做imp数据库全库导出，经过4个多小时正常导出全库数据库。2 .具体验证在完成初步验证之后，甲方要求其DB所口业务人员通过远程做数据库进一步具体验证。1.首先切换到实例scope（最重要）,启动数据库配合做了验证环境和各个数据库的验证。最终验证数据库为完全恢复，没有问题。在验证数据之后，做数据迁移。考虑到数据库的容量和恢复时间。选择用expdp来做全库数据的导出。因为expdp的效率比exp的高些。编写好导出脚本，并在测试环境下测试没有问题后，先对scope数据库进行导出。导出开始后24分钟时，开始报错：ORA-39171:Jobisexperi

30、encingaresumablewait.ORA-01654:unabletoextendindexSYSTEM.SYS_MTABLE_00003A964_IND_1by8intablespaceSYSTEM经过查找原因，得出是因为system表空间已满造成的。用expdp导出时会向system表空间里的SYSTEM.SYS_MTABLE_00003A964帖0力口入导出记录数据.当导出大量数据时，此表的数据量就会增大，当达到system表空间的总容量时，就会报错。这里分析，表空间一般是会自动增加容量的，那样就不应该报错。最后查询出，system表空间是放在裸设备上的，容量为1G且不可以增大。所以，就不能使用expdp工具做导出。只能使用exp