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

【数据恢复故障描述】
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会清除，即便留下目录信息，也没法与数据一一对应，这时候，就只能参考文件内部格式进行类型式的恢复了。
【数据恢复过程】
一、完整备份故障卷，因RAID无端障，因此直接在SOLARIS环境中对原LUN作dd备份。
二、在备份中分析文件系统，肯定需恢复文件的inode已经所有清除，没法还原。只好按文件类型进行处理。
三、对用户须要恢复的特定文件进行分析，发现采用vfs公文系统的索引文件具备强的类型特征，同时文件中包含目录信息。
四、按照公文系统的索引结构特征，写程序提取，提取后根据特征从新命名。
五、按类型恢复数据文件，以后用户人工根据索引文件，对数据文件进行从新整理。
【数据恢复结论】
历时24小时，目录索引文件99%恢复成功，数据文件大部分恢复成功，其他已破坏没法恢复的文件，用户根据目录索引文件从新向其余部门采集。
结论上，用户承认数据恢复成功。