共计 919 个字符，预计需要花费 3 分钟才能阅读完成。
服务器数据恢复环境：
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% 复原胜利，数据文件大部分复原胜利，其余已毁坏无奈复原的文件由用户依据目录索引文件从新向其余部门采集。用户认可本次数据恢复后果。
