SAN LUN Mapping出错导致文件系统共享冲突,数据恢复成功
2017-09-07 17:32
841 查看
【用户单位】
中国联通某分公司
【数据恢复故障描述】
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%恢复成功,数据文件大部分恢复成功,其余已破坏无法恢复的文件,用户根据目录索引文件重新向其他部门采集。
结论上,用户认可数据恢复成功。
中国联通某分公司
【数据恢复故障描述】
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%恢复成功,数据文件大部分恢复成功,其余已破坏无法恢复的文件,用户根据目录索引文件重新向其他部门采集。
结论上,用户认可数据恢复成功。
相关文章推荐
- SAN LUN Mapping出错导致文件系统共享冲突的数据恢复成功案例
- SAN LUN Mapping出错导致文件系统共享冲突的数据恢复全过程
- SAN LUN Mapping出错导致文件系统共享冲突的恢复案例
- SAN,LINUX EXT3 LUN,存储ORACLE数据库,FSCK后出错,数据恢复手记
- 必须使用记录或另一备份以恢复包含系统注册数据的文件.恢复成功(已解决)
- IP SAN/NAS 14*73GB RAID5 REISERFS 文件系统数据恢复手记
- IP SAN/NAS 14*73GB RAID5 REISERFS 文件系统数据恢复手记
- SCO UNIXWARE 文件系统损坏,后恢复数据成功
- 注册表故障恢复 必须使用记录或另一备份以恢复包含系统注册表数据的文件。恢复成功
- 分析案例:哪些操作导致IBM X225上无法成功恢复数据
- 实例:Linux EXT3文件系统下成功恢复误删的文件
- 系统崩溃后 oracle 9i数据文件恢复过程
- 文件系统管理 之 有关ext2文件系统下反删除(Undelete)操作恢复数据的文档
- 系统损坏,移植Oracle(9.2.0.1)数据库(无备份数据文件进行恢复)
- 分析案例:哪些操作导致IBM X225上无法成功恢复数据
- linux reiserfs文件系统损坏后的数据恢复过程记录
- FAT文件系统数据恢复实例
- reiserfs文件系统反删除(Undelete)数据恢复操作的实践
- FAT16文件系统手工数据恢复分析
- 误删文件恢复,系统启动原理,数据的存取原理(文件存储原理),文件恢复原理