ITPub博客

首页 > 数据治理 > 数据治理 > 分析SAN LUN Mapping出错导致文件系统共享冲突的情况

分析SAN LUN Mapping出错导致文件系统共享冲突的情况

原创 数据治理 作者:北亚数据恢复 时间:2019-11-05 10:26:15 0 删除 编辑


【数据恢复故障描述】
SUN 光纤存储系统,中心存储为 6 300G 硬盘组成的 RAID6 ,划分为若干 LUN MAP 到不同业务的服务器上,服务器上运行 SUN SOLARIS 操作系统。
正常工作状态下,用户需要新增应用,所以增加了一台IBM 服务器,之后在线状态下将存储中的某个 LUN 映射到新增的 IBM 服务器,不料,映射的卷是原先已经 MAP SOLARIS 生产系统上的某个 LUN 上了,由于并未及时发现, IBM 服务器上已经对此 LUN 进行了部分初始化操作 ( 操作不详 ) ,之后 SOLARIS 上磁盘报错,重启后发现问题,卷无法挂载。
SUN 工程师检测后,执行 fsck ,完成后文件系统可挂上,但很多数据丢失或大小变为 0 ,尤其最新数据破坏严重。

【数据恢复故障分析】
SAN 环境下此类故障较为常见,但多数是人为不小心导致,此故障也是如此。正常情况下, SAN 分配出来的 LUN 是独占模式的,如果同时为几个操作系统所控制,极易导致写操作不互斥,导致文件系统一致性出错。
如果要恢复此部分数据,需要深入文件系统,考察其各结构的破坏情况。本例中,因文件系统采用UFS ,所以对任何一个需要恢复的文件而言,优先考虑目录信息、节点、数据区是否正常,如上述 3 个结构均正常,数据可完整恢复。但多数情况下, fsck INODE 会清除,即使留下目录信息,也无法与数据一一对应,这时候,就只能参考文件内部格式进行类型式的恢复了。

【数据恢复过程】
1 、完整备份故障卷,因 RAID 无故障,所以直接在 SOLARIS 环境中对原 LUN dd 备份。
2 、在备份中分析文件系统,确定需恢复文件的 inode 已经全部清除,无法还原。只好按文件类型进行处理。
3 、对用户需要恢复的特定文件进行分析,发现采用 vfs 公文系统的索引文件具有强的类型特征,同时文件中包含目录信息。
4 、按照公文系统的索引结构特征,写程序提取,提取后根据特征重新命名。
5 、按类型恢复数据文件,之后用户人工根据索引文件,对数据文件进行重新整理。

【数据恢复结论】
历时24 小时,目录索引文件 99% 恢复成功,数据文件 大部分 恢复成功,其余已破坏无法恢复的文件,用户根据目录索引文件重新向其他部门采集。
结论上,用户认可数据恢复成功。

 


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31380569/viewspace-2662651/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
从事数据恢复工作,擅长服务器/虚拟机/数据库等方面的数据恢复

注册时间:2016-08-02

  • 博文量
    207
  • 访问量
    116649