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 单实例软件。

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/frombyte.com

检测iSCSI是否安装成功

#iscsiutil -l

配置iSCSI的启动器名称

#iscsituil /dev/iscsi -i -N iqn.2014-10-15:LUN

配置挂载目标iSCSI设备

#iscsiutil -a -I 10.10.1.9

删除目标iscsi设备

#iscsiutil -d -I 10.10.1.9

验证目标iSCSI是否挂载成功

#iscsiutil -pD

发现目标target设备

#/usr/sbin/ioscan -H 255

为目标创建设备文件

#/usr/sbin/insf -H 255

（2）导入外部VG信息

创建VG节点

#mkdir /dev/vgscope/frombyte.com

创建VG设备文件名

#mknod /dev/vgscope/group c 64 0x030000

查看PV是否正常

#pvdisplay -l /dev/dsk/c2t0d0/frombyte.com

将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协助下，安装并识别到所有裸设备文件。

然后调整配置参数，检测数据库存储状态，为启动数据库做准备。