服务器数据恢复环境：

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天的数据分析和恢复操作，北亚企安数据恢复工程师提取了故障服务器内的绝大部分的数据和目录索引文件，经过用户的反复验证，确认所需要的重要数据已经全部恢复。