数据恢复机制（服务器数据恢复）
数据恢复机制（服务器数据恢复）北亚数据恢复——SAN数据恢复如果要恢复此部分数据，需要深入文件系统检查各结构的破坏情况。本案例中，文件系统采用UFS，所以对任何一个需要恢复的文件而言，优先考虑目录信息、节点、数据区是否正常，如上述3个结构均正常，数据可完整恢复。但多数情况下，fsck后INODE会清除，即使留下目录信息，也无法与数据一一对应，这时候就只能参考文件内部格式进行类型式的数据恢复了。服务器故障&分析：由于业务扩展的需要，用户新增了一台IBM服务器用于新增应用，在光纤存储在线的状态下将存储中的某个LUN映射到新增的IBM服务器中。不料映射的卷原先已经MAP到SOLARIS生产系统上的某个LUN上了，IBM服务器对此LUN进行了部分初始化，之后SOLARIS上的磁盘报错，重启后发现卷无法挂载。用户联系SUN工程师进行检测后，进行了fsck的操作，完成操作后文件系统可挂上，但很多数据丢失或大小变为0，尤其最新数据破
服务器数据恢复环境：
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会清除，即使留下目录信息，也无法与数据一一对应，这时候就只能参考文件内部格式进行类型式的数据恢复了。
北亚数据恢复——SAN数据恢复
服务器数据恢复过程：
1、服务器数据恢复工程师对故障卷做完整备份，因RAID无故障，所以可以直接在SOLARIS环境中对原LUN进行备份。
2、在备份中分析文件系统，确定了需恢复文件的inode已经全部清除，无法还原，所以只好按文件类型进行处理。
3、对用户需要恢复的特定文件进行分析，发现采用vfs公文系统的索引文件具有强的类型特征，同时文件中包含目录信息。
4、按照公文系统的索引结构特征，北亚服务器数据恢复工程师写程序提取数据，提取后根据特征重新命名。
5、按类型恢复数据文件，然后由用户根据索引文件对数据文件进行重新整理。
6、历时24小时，目录索引文件99%恢复成功，数据文件大部分恢复成功，其余已破坏无法恢复的文件由用户根据目录索引文件重新向其他部门采集。用户认可本次数据恢复结果。
北亚数据恢复——SAN数据恢复
