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

SAN环境下LUN映射出错导致文件系统共享冲突的数据恢复案例

最新动态来源:本站原创点击数:121更新时间:2024/9/26

服务器数据恢复环境:
SAN环境下一台存储设备中有一组由6块硬盘组建的RAID6磁盘阵列,划分若干LUN,MAP到不同业务的SOLARIS操作系统服务器上。
 
服务器故障:
用户新增了一台服务器,将存储中的某个LUN映射到新增加的这台服务器上。这个映射的LUN其实之前已经MAP到其他SOLARIS操作系统的服务器上了。由于没有及时发现问题,新增加的这台服务器已经对此LUN做了初始化操作,磁盘报错,重启后发现卷无法挂载。
联系SUN工程师进行检测后,执行fsck操作。虽然完成操作后可以挂载上文件系统,但是发现有大量文件丢失或文件大小变为0,尤其新数据破坏比较严重。
SAN环境下此类故障较为常见,但多数是设置问题所导致。SAN分配出来的LUN是采用独占模式的,如果该LUN同时被几个操作系统控制,就会出现写操作不互斥的问题,最终导致文件系统一致性出错。
如果要恢复数据,需要分析文件系统各结构的破坏情况。本案例中文件系统采用UFS,对任何一个需要恢复的文件而言,优先考虑目录信息、节点、数据区是否正常。如果目录信息、节点、数据区均正常,数据可完整恢复。多数情况下,执行fsck操作后会清除INODE,即使留下目录信息,也无法与数据一一对应。这种情况下,只能参考文件内部格式进行类型式的恢复。
 
服务器数据恢复过程:
1、完整备份故障卷,因为RAID6阵列无故障,所以可以直接在SOLARIS环境中对原LUN做dd备份。后续的数据分析和数据恢复操作都基于备份文件进行,避免对原始数据造成二次破坏。
2、基于备份文件分析文件系统,发现需要恢复的文件的inode已经全部被清除,无法还原。只能按照文件类型进行处理。
3、分析需要恢复的特定文件,发现采用vfs公文系统的索引文件具有强的类型特征,而且文件中包含目录信息。
4、按照公文系统的索引结构特征,北亚企安数据恢复工程师编写程序提取数据文件,提取完成后根据特征重新命名。
5、按照类型恢复数据文件。之后由用户方根据索引文件对数据文件进行重新整理。
6、经过用户仔细检测,确认分析所需要的数据文件恢复成功,认可数据恢复结果。针对少部分已破坏且无法恢复的文件,由用户方根据目录索引文件重新向其他部门采集。