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

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

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