服务器数据恢复环境：

SUN光纤存储系统；

6块硬盘组成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进行备份。

2、在备份中分析文件系统，确定了需恢复文件的inode已经全部清除，无法还原，所以只好按文件类型进行处理。

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

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

5、按类型恢复数据文件，然后由用户根据索引文件对数据文件进行重新整理。

6、历时24小时，目录索引文件99%恢复成功，数据文件大部分恢复成功，其余已破坏无法恢复的文件由用户根据目录索引文

件重新向其他部门采集。用户认可本次数据恢复结果。

ITPub博客

【服务器数据恢复】SAN LUN映射出错导致文件系统数据丢失的数据恢复案例