服务器数据恢复故障描述

服务器内有两块硬盘掉线，现在服务器内的lun丢失了，数据恢复工程师开始对故障服务器进行检测发现掉线的硬盘并没有存在物理故障、也没有坏道等其他故障。于是开始对客户的故障服务器进行镜像备份。

服务器故障原因分析：

本次需要进行数据恢复的服务器没有硬盘故障，所以硬盘掉线的原因可能是因为硬盘读写不稳定导致的，硬盘读写不稳定将被控制器默认为是坏盘踢出，掉线的硬盘超过了2块后就会导致服务器不可用，此时不能通过常规方式进行修复，只能通过服务器数据恢复手段进行数据恢复。通过分析该服务器内的raid条目存储形式，每个硬盘的不同块组成一个raid条目，服务器数据恢复工程师通过分析解析出来raid条目信息，每个LUN都有一份LUN_MAP。EVA将LUN_MAP分别存放在不同的磁盘中，使用一个索引来指定其位置。因此去每个磁盘中找这个指向LUN_MAP的索引就可以找到现存LUN的信息了。

服务器数据恢复过程

通过故障分析硬盘是因为性能原因掉线，这些掉线的硬盘中有一部分数据是老旧数据，由于LUN的RAID结构大多都是RAID5，只需要将一个LUN的RAID条目通过RAID5的校验算法算出校验值，再和原有的校验值做比较就可以判断这个条目中是否有掉线盘。而将一个LUN的所有LUN_MAP都校验一遍就可以知道这个LUN中哪些RAID条目中有掉线盘。而这些RAID条目中都存在的那个盘就一定是掉线盘。排除掉线盘，然后根据LUN_MAP恢复所有LUN的数据即可。上述的故障分析以及解决思路最终都需要使用编程来实现。编写扫描LUN_MAP的程序Scan_Map.exe，扫描全部LUN_MAP，结合人工分析得出最精确的LUN_MAP。编写检测RAID条目的程序Chk_Raid.exe，检测所有LUN中掉线的磁盘，结合人工分析排除掉线的磁盘。编写LUN数据恢复程序Lun_Recovery.exe，结合LUN_MAP恢复所有LUN数据。

根据编写好的程序去实现不同的功能，最后使用Lun_Recovery.exe结合LUN_MAP恢复所有LUN的数据。然后人工核对每个LUN，确认是否和甲方工程师描述的一致。服务器数据恢复数据验证根据甲方工程师描述所有LUN的数据可以分成两大部份，一部分是Vmware的虚拟机，一部分是HP-UX上的裸设备，裸设备里存放的是Oracle的dbf数据库。由于我们恢复的是LUN，无法看到里面的文件，因此需要将这些LUN同过人工的核对哪些LUN是存放Vmware的数据，哪些是HP-UX的裸设备。然后将LUN挂载到不同的验证环境中验证恢复的数据是否完整。

在一台dell的服务器上安装了ESXI5.5虚拟主机环境，然后通过iSCSI的方式将恢复的LUN挂载到虚拟主机上。但是在VMwarevSphereClient?上扫描vmfs卷，没有发现。后来发现客户的虚拟主机是EXSI3.5的版本。可能因为版本的原因无法直接扫描到vmfs卷，于是换一种验证方式。将所有符合vmware虚拟机的LUN里面的虚拟机文件都生成出来，然后通过NFS共享的方式挂载到虚拟主机上，然后将虚拟机一个一个的添加到清单。

验证vmfs虚拟机

通过NFS将所有虚拟机都添加到虚拟主机以后，将所有虚拟机都加电开机，发现都能启动系统。由于没有开机密码无法确认虚拟机里面的文件是否完整。后来甲方安排工程师通过远程到我们的服务器，将所有虚拟机都开机进入系统，验证虚拟机里面的数据都没问题。虚拟机的所有数据都恢复成功。

日后数据安全建议

1、安排员工经常巡视机房，发现有报警信息及时处理。2、管理人员操作存储要谨慎，避免误操作导致数据丢失。3、现场发现EVA控制器部分模块不太稳定，应当及时更换。4、由于EVA存储故障是由磁盘不稳定引起的，而这部分磁盘应该是同一批次的磁盘。因此，这些磁盘的性能也快到极限，如果有条件建议换掉这批磁盘。