您所在的位置:首页 > 成功案例 > 存储数据恢复

raid5阵列中多块磁盘掉线导致EVA存储不可用的数据恢复案例

最新动态来源:本站原创点击数:56更新时间:2024/5/24

服务器数据恢复环境:
1台某品牌EVA4400控制器+3台EVA4400扩展柜+28块FC硬盘。
 
服务器故障:
由于两块磁盘掉线导致存储中某些LUN不可用,某些LUN丢失,导致存储崩溃。
 
服务器数据恢复过程:
1、由于EVA4400存储故障是某些磁盘掉线导致的,因此收到故障存储中的所有磁盘后,硬件工程师先对所有磁盘做物理故障检测,检测完成后发现所有磁盘均不存在明显物理故障。使用坏道检测工具检测也没有发现坏道。
将所有磁盘以只读方式进行扇区级全盘镜像,镜像完成后将所有磁盘还给用户方。后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。
由于没有检测到磁盘存在物理故障或者坏道,可以初步判断磁盘掉线是由于某些磁盘读写不稳定导致的。EVA控制器检查磁盘策略比较严格,EVA控制器通常将性能不稳定的磁盘识别为坏盘并踢出磁盘组。一旦某个LUN的同一个条带中掉线的盘到达极限,这个LUN将不可用。如果EVA存储中所有LUN都包含这些掉线的盘,所有LUN都会受影响。所以两块盘掉线导致整个EVA存储的LUN都不可用的情况是有可能发生的。故障EVA存储目前的情况就是8个LUN正常,7个LUN损坏,6个LUN丢失。需要恢复所有LUN的数据。
2、基于镜像文件分析所有硬盘的底层数据。EVA存储中的LUN都是以RAID条目的形式存储数据的,EVA存储将每个磁盘的不同块组成一个RAID条目。RAID条目的类型有很多种,首先需要分析出组成LUN的RAID条目类型以及这个RAID条目是由哪些盘的哪些块组成。这些信息都存放在LUN_MAP中,每个LUN都有一份LUN_MAP。EVA将LUN_MAP分别存放在不同的磁盘中,使用一个索引来指定其位置,因此在每个磁盘中找这个指向LUN_MAP的索引就可以找到现存LUN的信息了。
3、虽然磁盘中记录了指向LUN_MAP的索引,但是它只记录现存的LUN,丢失的LUN是不会记录索引的。EVA存储中删除一个LUN只会清除这个LUN的索引,而不会清除这个LUN的LUN_MAP。扫描所有磁盘找到所有符合LUN_MAP的数据块,然后排除掉现有的LUN_MAP,剩下的LUN_MAP也不一定全是删除的,也有一些是以前旧的。只能将所有LUN_MAP的数据都恢复出来,人工核对哪些LUN是删除的。
4、这些由于性能不稳定而掉线的磁盘中存放的是一些旧的数据,在生成数据的时候需要将这些磁盘都排除掉。如何判断哪些磁盘是掉线的呢?由于本案例中LUN基本上都是RAID5阵列,只需要将一个LUN的RAID条目通过RAID5的校验算法算出校验值,再和原有的校验值做比较就可以判断这个条目中是否有掉线盘。将一个LUN的所有LUN_MAP都校验一遍就可以知道这个LUN中的哪些RAID条目中有掉线盘。而这些RAID条目中都存在的那个盘就一定是掉线盘。排除掉线盘,然后根据LUN_MAP恢复所有LUN的数据。
5、北亚企安数据恢复工程师编写扫描LUN_MAP的程序扫描全部LUN_MAP,结合人工分析获取到准确的LUN_MAP。编写检测RAID条目的程序检测所有LUN中掉线的磁盘,结合人工分析排除掉线的磁盘。编写LUN数据恢复程序结合LUN_MAP恢复所有LUN数据。人工核对每个LUN,确认是否和用户方描述的一致。
6、根据用户方描述,所有LUN的数据可以分成两大部份:Vmware虚拟机和HP-UX上的裸设备,裸设备里存放的是Oracle的dbf数据库。由于恢复的是LUN,无法看到里面的文件,需要人工核对哪些LUN是存放Vmware的数据,哪些是HP-UX的裸设备。然后将LUN挂载到不同的验证环境中验证恢复的数据是否完整。
7、Vmware虚拟机和裸设备中oracle数据库的验证这里就不赘述了。
8、将所有恢复出来的数据移交到用户方准备好的环境中,经过验证,用户方确认恢复出来的数据完整有效,认可数据恢复结果。本次数据恢复工作完成。