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

公司 HP-EVA4400 存储硬盘离线数据恢复方法 一、故障描述 整个 EVA存储结构是由一台 EVA4400控制器，三台 EVA4400扩展柜和 28块 FC 300G硬盘构成的。由于两块磁盘掉线导致存储某些 LUN不可用， 某些 LUN丢失。由于 EVA4400是因为某些磁盘掉线，从而导致整个存储不可 用。因此接收到磁盘以后北亚工程师先对所有磁盘做物理检测，检测完后 发现没有物理故障。接着使用坏道检测工具检测磁盘坏道，发现也没有坏 道。磁盘坏道检测日志如下图： 二、备份数据 考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数 据做备份，以防万一操作不当导致数据无法再次恢复。使用 winhex将所有 磁盘都镜像成文件，源磁盘的内容数量多，在做数据备份的时候要花费很 长时间。备份完部分数据如下图： 三、故障分析及恢复过程 1、分析故障原因 由于前两个步骤并没有检测到磁盘有物理故障或者是坏道，由此推断可 能是由于某些磁盘读写不稳定导致故障发生。因为 EVA控制器检查磁盘的策 略很严格，一旦某些磁盘性能不稳定，EVA 控制器就认为是坏盘，就将认为 是坏盘的磁盘踢出磁盘组。而一旦某个 LUN的同一个条带中掉线的盘到达极 限，那么这个 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_MAP中，每个 LUN都有一份 LUN_MAP。EVA 将 LUN_MAP分 别存放在不同的磁盘中，使用一个索引来指定其位置。因此去每个磁盘中 找这个指向 LUN_MAP的索引就可以找到现存 LUN的信息了。 3、分析丢失的 LUN 虽然磁盘中记录了指向 LUN_MAP的索引，但是它只记录现存的 LUN，丢失 的 LUN是不会记录索引的。由于 EVA中删除一个 LUN只会清除这个 LUN的索 引，而不会清除这个 LUN的 LUN_MAP。这时需要扫描所有磁盘找到所有符合 LUN_MAP的数据块，然后排除掉现有的 LUN_MAP，剩下的 LUN_MAP也不一定全 是删除的，也有一些是以前旧的，但此时是无法在 LUN_MAP中筛选了，只能 通过程序将所有 LUN_MAP的数据都恢复出来，人工的去核对哪些 LUN是删除 的。 4、分析掉线磁盘 在前面的故障分析中说了，虽然磁盘没有明显的物理故障，也没有磁盘 坏道。但还是会因为性能的原因从 EVA磁盘组中脱离。而这些脱离的磁盘中 都存放的是一些旧的数据，因此在生成数据的时候需要将这些磁盘都排除 掉。但是如何判断哪些磁盘是掉线的呢？由于 LUN的 RAID结构大多都是 RAID5，只需要将一个 LUN的 RAID条目通过 RAID5的校验算法算出校验值，再 和原有的校验值做比较就可以判断这个条目中是否有掉线盘。而将一个 LUN 的所有 LUN_MAP都校验一遍就可以知道这个 LUN中哪些 RAID条目中有掉线盘。 而这些 RAID条目中都存在的那个盘就一定是掉线盘。排除掉线盘，然后根 据 LUN_MAP恢复所有 LUN的数据即可。 5、编写数据恢复程序 上述的故障分析以及解决思路最终都需要使用编程来实现。编写扫描 LUN_MAP的程序 Scan_Map.exe，扫描全部 LUN_MAP，结合人工分析得出最精确 的 LUN_MAP。编写检测 RAID条目的程序 Chk_Raid.exe，检测所有 LUN中掉线的 磁盘，结合人工分析排除掉线的磁盘。编写 LUN数据恢复程序 Lun_Recovery.exe，结合 LUN_MAP恢复所有 LUN数据。 6、恢复所有 LUN 数据 根据编写好的程序去实现不同的功能，最后使用 Lun_Recovery.exe结合 LUN_MAP恢复所有 LUN的数据。然后人工核对每个 LUN，确认是否和甲方工程 师描述的一致。部分 LUN的数据恢复如下图： 四、数据验证 根据甲方工程师描述所有 LUN的数据可以分成两大部份，一部份是 Vmware的虚拟机，一部分是 HP-UX上的裸设备，裸设备里存放的是 Oracle的 dbf数据库。由于我们恢复的是 LUN，无法看到里面的文件，因此需要将这 些 LUN同过人工的核对哪些 LUN是存放 Vmware的数据，哪些是 HP-UX的裸设 备。然后将 LUN挂载到不同的验证环境中验证恢复的数据是否完整。 1、部署 Vmware 虚拟机的验证环境 在一台 dell的服务器上安装了 ESXI5.5虚拟主机环境，然后通过 iSCSI的方 式将恢复的 LUN挂载到虚拟主机上。但是在 VMware vSphere Client 上扫描 vmfs 卷，没有发现。后来发现客户的虚拟主机是 EXSI3.5的版本。可能因为版本的原 因无法直接扫描到 vmfs卷，于是换一种验证方式。将所有符合 vmware虚拟机的 LUN里面的虚拟机文件都生成出来，然后通过 NFS共享的方式挂载到虚拟主机上， 然后将虚拟机一个一个的添加到清单。恢复的部分虚拟机文件如下图： 2、验证 vmfs 虚拟机 通过 NFS将所有虚拟机都添加到虚拟主机以后，将所有虚拟机都加电开 机，发现都能启动系统。由于没有开机密码无法确认虚拟机里面的文件是 否完整。后来甲方安排工程师通过远程到我们的服务器，将所有虚拟机都 开机进入系统，验证虚拟机里面的数据都没问题。虚拟机的所有数据都恢 复成功。部分虚拟机开机如下： 3、部署 Oracle 数据库的验证环境 为了裸设备恢复测试和后期的数据验证工作，需要先搭建好 oracle 环境。 根据甲方工程师提供的环境信息为 HP小机 Itanium架构，我公司 HP小机为 RX2660(Itanium 2), 是同架构的兼容版本。于是计划在此机器上安装 oracle 单实例软件。 软件平台： 项目 信息 操作系统 HP-UX B.11.31 数据库 Oracle .0 Enterprise Edition - 64bit for HPUX 以下是安装环境的简单步骤介绍： 1. 环境检测 # uname -all HP-UX byhpux1 B.11.31 U ia64 1447541358 unlimited-user license 本机为 IA64架构，操作系统为 HP-UX ，版本为 B.11.31。 然后检查各部分存储空间信息，保证空间足够。 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=.0:0 $./runInstaller 图像界面起来之后的安装就比较简单了，这里只安装软件，不安装实例。 7.测试数据库连接 #su - oracle $sqlplus / as syssdba 4、验证 Oracle 数据库 1、 挂载裸设备 由于有部分 LUN是裸设备，而我们恢复的 LUN都是以文件的形式存在。因此 需要将文件形式的 LUN挂载到 HP-UX上。在 HP-UX服务器上安装 iSCSI Initiator， 安装步骤如下： 检测软件包是否完整 #swlist -d /tmp/B.11.31.03d_iSCSI-00_B.11.31.03d_HP- UX_B.11.31_IA_PA.depot 安装软件包 #swinstall -x autoreboot=true -s /tmp/B.11.31.03d_iSCSI- 00_B.11.31.03d_HP-UX_B.11.31_IA_PA.depot iSCSI-00 将 iSCSI的可执行文件添加到 PATH #PATH=$PATH:/opt/iscsi/bin/ 检测 iSCSI是否安装成功 #iscsiutil -l 配置 iSCSI的启动器名称 #iscsituil /dev/iscsi -i -N iqn.2014-10-15:LUN 配置挂载目标 iSCSI设备 #iscsiutil -a -I 删除目标 iscsi设备 #iscsiutil -d -I 验证目标 iSCSI是否挂载成功 #iscsiutil -pD 发现目标 target设备 #/usr/sbin/ioscan -H 255 为目标创建设备文件 #/usr/sbin/insf -H 255 2、 导入外部 VG信息 创建 VG节点 #mkdir /dev/vgscope/ 创建 VG设备文件名 #mknod /dev/vgscope/group c 64 0x030000 查看 PV是否正常 #pvdisplay -l /dev/dsk/c2t0d0/ 将 PV导入 VG中 #vgimport -v /dev/vgscope /dev/dsk/c2t0d0 激活 VG信息 #vgchange -a y vgscope 查看 VG信息 #vgdisplay -v vgscope 3、 修改 LV名称 由于是在新的环境上重建的 VG，然后再将 PV导入到新建的 VG中。因此 LV 的名称全部都改变了，需要手动的去将 LV的名称都改成和以前一下的。 因为原来数据库实例是有 2个，并且是使用的裸设备存储。所以在创建数 据库实例时，要按按照原来配置和命名。 文件系统层面，在同时协助下，挂载了所有 LV,并修改权限。 安装数据库实例，根据原始配置，在客户 DBA协助下，安装并识别到所有 裸设备文件。 然后调整配置参数，检测数据库存储状态，为启动数据库做准备。 1.首先切换到实例 scope（最重要）。,启动数据库。 SQLstartup mount; SQLselect file#,error from v$recover_file; -查损坏的文件. 没有损坏的文件。 SQLALTER DATABASE OPEN; 启动没有报错，但是缓慢，之后查询了用户，随机查询了一个用户的两张 表，数据结果集返回正常。然后连接突然中断，重新连接，查看状态为数据库 关闭。再启动数据库，还是启动不了，会强制关闭。 经过初步检测和常规恢复库状态，不能修复此问题。 2. 验证 NJYY 数据库 将环境变量切换到另一个数据库 NJYY，open 数据库时报错内存不足错误, 不能开启数据库。经初步检测检测，数据文件没有损坏。 SQLstartup mount; SQLselect file#,error from v$recover_file; SQLALTER DATABASE OPEN; error 4030 detected in background process 5、修复 Oracle 数据库 1.故障修复 对于 scope数据库，根据上面的操作和故障现象，初步判断是 undo表空间 或者日志方面有问题。对数据文件做完整性和一致性检测，结果只有一个 undo01.dbf文件损坏。确定是 undo表空间损坏。通过命令删除掉损坏的 undo 表空间，又在原来位置重建。 检测其他部分文件，没有发现问题。重新启动数据库，正常启动，做查询数据， 正常，做了完整性检测，正常。 接着做 imp数据库全库导出，经过 3个多小时正常导出全库数据库。 对于 NJYY 数据库，检测到是内存空间设置不对，经过命令调整，数据库恢 复正常，能正常启动，正常使用。 最后做 imp数据库全库导出，经过 4个多小时正常导出全库数据库。 2. 具体验证 在完成初步验证之后，甲方要求其 DBA和业务人员通过远程做数据库进一 步具体验证。配合做了验证环境和各个数据库的验证。 最终验证数据库为完全恢复，没有问题。 在验证数据之后，做数据迁移。考虑到数据库的容量和恢复时间。选择用 expdp来做全库数据的导出。因为 expdp的效率比 exp的高些。 编写好导出脚本，并在测试环境下测试没有问题后，先对 scope数据库进 行导出。导出开始后 24分钟时，开始报错： ORA-39171: Job is experiencing a resumable wait. ORA-01654: unable to extend index SYSTEM.SYS_MTABLE_00003A964_IND_1 by 8 in tablespace SYSTEM 经过查找原因，得出是因为 system表空间已满造成的。用 expdp导出时会 向 system表空间里的 SYSTEM.SYS_MTABLE_00003A964_IND_1表里加入导出记录 数据.当导出大量数据时，此表的数据量就会增大，当达到 system表空间的总 容量时，就会报错。这里分析，表空间一般是会自动增加容量的，那样就不应 该报错。最后查询出，system 表空间是放在裸设备上的，容量为 1G，且不可以 增大。所以，就不能使用 expdp工具做导出。 只能使用 exp工具导出，虽然会 慢一点，但是不会有 system表空间不足的问题。 最后通过 exp对 scope做全库导出，经过 6个多小时成功备份完成。备份 文件达 172G。 对 NJYY数据库，做 imp导出，经过 7个多小时正常导出全库数据库，备份 文件达 140G.接着对数据库备份文件做了本地备份，作为安全冷备份。 五、移交数据 1、移交 vmware 虚拟机文件和 Oracle dump 文件 验证所有数据没有问题后，将 vmware虚拟机文件和 Oracle dump文件拷 贝至一块 2TB的希捷硬盘中。然后再将恢复出来的 LUN数据拷贝至两块 3TB 的单盘中。来到甲方现场后先将 vmware虚拟机文件和 Oracle dump文件交给 甲方后，甲方开始验证 dump文件和 vmware虚拟机文件。 2、将 LUN 数据