Chinaunix首页 | 论坛 | 博客
  • 博客访问: 356613
  • 博文数量: 609
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 6125
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-02 14:16
文章分类

全部博文(609)

文章存档

2024年(174)

2023年(218)

2022年(181)

2020年(12)

2019年(24)

我的朋友

分类: 服务器与存储

2024-09-26 16:18:20

服务器数据恢复环境:
SAN环境下一台存储设备中有一组由6块硬盘组建的RAID6磁盘阵列,划分若干LUN,MAP到不同业务的SOLARIS操作系统服务器上。

服务器故障:
用户新增了一台服务器,将存储中的某个LUN映射到新增加的这台服务器上。这个映射的LUN其实之前已经MAP到其他SOLARIS操作系统的服务器上了。由于没有及时发现问题,新增加的这台服务器已经对此LUN做了初始化操作,磁盘报错,重启后发现卷无法挂载。
联系SUN工程师进行检测后,执行fsck操作。虽然完成操作后可以挂载上文件系统,但是发现有大量文件丢失或文件大小变为0,尤其新数据破坏比较严重。
SAN环境下此类故障较为常见,但多数是设置问题所导致。SAN分配出来的LUN是采用独占模式的,如果该LUN同时被几个操作系统控制,就会出现写操作不互斥的问题,{BANNED}最佳终导致文件系统一致性出错。
如果要恢复数据,需要分析文件系统各结构的破坏情况。本案例中文件系统采用UFS,对任何一个需要恢复的文件而言,优先考虑目录信息、节点、数据区是否正常。如果目录信息、节点、数据区均正常,数据可完整恢复。多数情况下,执行fsck操作后会清除INODE,即使留下目录信息,也无法与数据一一对应。这种情况下,只能参考文件内部格式进行类型式的恢复。

服务器数据恢复过程:
1、完整备份故障卷,因为RAID6阵列无故障,所以可以直接在SOLARIS环境中对原LUN做dd备份。后续的数据分析和数据恢复操作都基于备份文件进行,避免对原始数据造成二次破坏。
2、基于备份文件分析文件系统,发现需要恢复的文件的inode已经全部被清除,无法还原。只能按照文件类型进行处理。
3、分析需要恢复的特定文件,发现采用vfs公文系统的索引文件具有强的类型特征,而且文件中包含目录信息。
4、按照公文系统的索引结构特征,北亚企安数据恢复工程师编写程序提取数据文件,提取完成后根据特征重新命名。
5、按照类型恢复数据文件。之后由用户方根据索引文件对数据文件进行重新整理。
6、经过用户仔细检测,确认分析所需要的数据文件恢复成功,认可数据恢复结果。针对少部分已破坏且无法恢复的文件,由用户方根据目录索引文件重新向其他部门采集。
阅读(107) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~