共计 929 个字符，预计需要花费 3 分钟才能阅读完成。
服务器数据恢复环境：
SUN 光纤存储，组建 RAID6，划分若干 LUN，MAP 到不同业务服务器，操作系统是 SUN SOLARIS。
服务器故障 & 剖析：
因为须要减少一台新服务器用来运行新增的利用，在原服务器还在线状态下，用户将其中一个 lun 映射到新服务器上。在执行操作之前，用户没有搞清楚这个行将要映射过来卷实际上曾经 map 到了 solaris 生产零碎上的某个 lun 上了。操作实现之后，这个卷开始进行初始化，本来的 solaris 上的磁盘报错。用户重启服务器后发现这个卷曾经无奈挂载了。起初在数据恢复之前通过硬件工程师的检测，排除了服务器存在物理故障。用户方工程师检测后执行 fsck 操作，实现操作后胜利挂载文件系统，然而查看数据时发现大量的数据失落或者文件大小为 0，而最新数据全副失落。
故障剖析：在失常工作模式下，san 调配的卷为独立占用模式，如果用户将其映射给两个或多个操作系统将会导致文件系统一致性出错。
如果呈现这种故障，要想复原数据首先要剖析文件系统各个构造的损坏状态。本次数据恢复案例中故障服务器设施的文件系统采纳 UFS，所以对任何一个须要复原的文件来说，须要优先查看目录信息、节点、数据区是否失常。如果目录信息、节点、数据区均失常，就能够残缺复原数据。但少数状况下，执行 fsck 操作后 INODE 会被革除，即便留下目录信息，也无奈与数据一一对应，这种状况下就只能参考文件外部格局进行类型式的复原。
服务器数据恢复过程：
1、残缺备份呈现问题的 lun。
2、基于备份文件解析文件系统，服务器数据恢复工程师通过剖析发现元文件中的 iNode 曾经被革除，所以无奈通过还原 iNode 来复原数据，只能通过文件类型进行数据恢复。
3、服务器数据恢复工程师剖析须要复原的特定文件，发现采纳 vfs 公文零碎的索引文件具备强的类型特色，同时文件中蕴含目录信息。于是，北亚企安数据数据恢复工程师依照公文零碎的索引结构特征编写程序提取数据，实现提取后依据特色重新命名。
4、按类型复原数据文件，之后由用户依据索引文件对数据文件进行重新整理。
5、通过 2 天的数据分析和复原操作，北亚企安数据恢复工程师提取了故障服务器内的绝大部分的数据和目录索引文件，通过用户的重复验证，确认所须要的重要数据曾经全副复原。
