服务器数据恢复环境：

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%复原胜利，数据文件大部分复原胜利，其余已毁坏无奈复原的文件由用户依据目录索引文件从新向其余部门采集。用户认可本次数据恢复后果。