EVA系列存储是一款以虚拟化存储为实现目的的中高端存储设备。EVA存储中的数据在EVA存储设备工作过程中会不断进行迁移，如果运行的任务比较复杂，EVA存储磁盘负载加重，很容易出现故障的。EVA存储通过大量磁盘的冗余空间和故障后rss冗余磁盘动态迁移来保护存储中的数据安全，但如果掉线磁盘越来越多，这种保护数据安全的能力会超过阈值，直至存储崩溃。下面分享一个EVA存储的数据恢复案例。

EVA存储故障&检测：
硬件架构：EVA某型号控制器+EVA扩展柜+若干FC磁盘。磁盘故障导致EVA存储中的LUN不可用，上层应用无法正常使用。
北亚企安数据恢复工程师拿到故障存储后，将所有磁盘编号后取出，对所有磁盘做物理故障检测，经过检测发现所有磁盘不存在物理故障，也没有在磁盘中发现大量的坏道。
将所有磁盘以只读方式做全盘镜像备份，镜像完成后按照编号将所有磁盘还原到原存储设备中，后续的数据分析和数据恢复操作在镜像文件上进行，避免对原始磁盘数据造成二次破坏。

EVA存储故障分析：
磁盘没有发现物理故障或者大量坏道，服务器数据恢复工程师初步判断故障的原因是某些磁盘读写不稳定。EVA控制器针对磁盘的检测策略非常严格，EVA控制器通常情况下会认定性能不稳定商务磁盘为坏盘并踢出磁盘组。一旦某个LUN的同一个条带中掉线的盘到达极限，这个LUN将不可用。也就是说如果EVA中所有的LUN都包含这些掉线的盘，这些LUN都会受影响。所以部分磁盘故障掉线也可能会导致存储无法正常使用。
EVA存储中的LUN是以RAID条目的形式来存储数据的。EVA存储将每个磁盘的不同块组成一个RAID条目，RAID条目有数种类型。如果要恢复数据就需要分析出组成LUN的RAID条目类型以及RAID条目是由哪些盘的哪些块组成的。这些信息都存放在LUN_MAP中，每个LUN都有一份LUN_MAP。EVA将LUN_MAP分别存放在不同的磁盘中并使用一个索引来指定其位置。因此在磁盘中找到这个指向LUN_MAP的索引就可以找到现存LUN的信息了。
因为EVA存储中掉线的磁盘存在陈旧的数据，在恢复数据的时候需要将这些磁盘都排除掉。由于LUN中的阵列是RAID5，将一个LUN的RAID条目通过RAID5的校验算法算出校验值，再和原有的校验值作比较就可以判断这个条目中是否有掉线盘。而将一个LUN的所有LUN_MAP都校验一遍就可以知道这个LUN中哪些RAID条目中有掉线硬盘。这些RAID条目中都存在的那个盘就一定是掉线盘。排除掉线盘后通过LUN_MAP恢复出所有LUN数据即可。

EVA存储数据恢复过程：
1、北亚企安数据恢复工程师编写扫描LUN_MAP的程序扫描全部LUN_MAP，然后通过人工分析确定LUN_MAP。
2、编写检测RAID条目的程序检测所有LUN中掉线的磁盘，然后通过人工分析排除掉线的磁盘。
3、编写LUN数据恢复程序，结合LUN_MAP恢复所有LUN数据。人工核对每个LUN，确认是否和用户方描述的一致。
部分LUN的数据：

4、分析恢复出来的LUN，重组&解析ASM磁盘组。
分析每个LUN前端的结构数据，根据ASM磁盘头结构来区分哪些LUN是属于ASM磁盘组的。通过分析共发现有2套ASM磁盘组。每个ASM磁盘组包含的LUN中的分区情况如下：

使用ASM结构解析工具解析和修复ASM磁盘组，解析出此ASM中存储的所有数据库文件。

将解析出来的数据库文件按照文件类型分组导出并对导出数据进行检测。

使用ASM解析工具恢复出所有的数据库文件。
5、根据用户方的描述，所有LUN的数据分成两大部分：Vmware的虚拟机和ORACLE上的ASM磁盘组数据。ASM磁盘组中存放的是Oracle的dbf数据库文件。由于通过恢复出来的LUN无法直接看到里面的文件，人工核对哪些LUN存放Vmware的数据，哪些LUN存放ASM设备，然后将LUN挂载到不同的验证环境中验证恢复的数据的完整性（验证过程就不赘述了）。
6、验证没有问题后，将vmware虚拟机文件和Oracle数据库文件移交给用户方。用户方将移交的数据上传至后台，程序可正常运行，没有发现问题，用户认可恢复结果。运行情况如下。

运行规定：

运行变更摘要：