服务器数据恢复环境：

某公司的光纤SAN存储系统，6块硬盘组建一组RAID6，划分若干LUN，MAP到不同的SOLARIS操作系统服务器上。

服务器故障&分析：

由于业务增长需要新增应用，工作人员增加了一台IBM服务器，在SAN还在线的状态下将存储中的某个LUN映射到新增加的那

台IBM服务器上。工作人员在进行操作之前不知道这个映射的卷之前已经MAP到SOLARIS操作系统上的某个LUN上了。当工作

人员发现到这个问题后，LUN已经进行了部分的初始化，SOLARIS操作系统中的磁盘报错，重启存储后发现卷无法挂载。

联系原厂工程师进行检测后，执行fsck，完成操作后文件系统可成功挂载，但发现大量数据丢失或大小变为0，尤其是新数据破

坏严重。

此类SAN故障较为常见。正常情况下，SAN分配出来的LUN是采用独占模式的，如果同时被数个操作系统所控制，极易导致写

操作不互斥，文件系统一致性出错。

本例中的存储采用的UFS文件系统，所以对每一个需要恢复的文件而言，优先考虑目录信息、节点、数据区是否正常，如果这

3者均正常，数据可完整恢复。但在多数情况下，执行fsck后INODE会被清除，即使留下目录信息，也无法与数据一一对应。

这种情况下只能参考文件内部格式进行类型式的恢复了。

服务器数据恢复过程：

1、将故障存储中所有磁盘以只读方式做完整镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，避免对原始磁

盘数据造成二次破坏。

2、基于镜像文件分析文件系统，经过分析北亚企安数据恢复工程师确定了需要恢复的文件的inode已经全部被清除，无法恢

复，只能按照文件类型进行处理。

3、经过分析用户需要恢复的特定文件，发现采用vfs公文系统的索引文件具有强的类型特征，同时文件中包含目录信息。

4、按照vfs公文系统的索引结构特征，北亚企安数据恢复工程师编写程序进行数据提取，提取数据后根据特征重新命名。

5、按照类型恢复数据文件，由用户人工根据索引文件重新整理数据文件。

服务器数据恢复总结：

经过北亚企安数据恢复工程师团队的努力，绝大部分的目录索引文件和大部分的数据文件被恢复出来。对于已经完全破坏、

无法恢复的文件，用户可以根据目录索引文件重新从其他部门采集。用户认可数据恢复结果。

ITPub博客

LUN映射出错后执行fsck导致文数据破坏的服务器数据恢复案例