SANLUNMapping出错导致文件系统共享冲突的完美解决方案

【用户单位】
中国联通某分公司
【数据恢复故障描述】

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

【数据恢复故障分析】

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

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

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