服务器数据恢复—SUN RAID6存储LUN重复映射致数据损坏与恢复案例

服务器数据恢复环境：
SUN光纤存储系统中有一组由6个硬盘组建的RAID6，划分为若干LUN，MAP到跑不同业务的服务器上，这些服务器上运行的是SOLARIS操作系统。
服务器不存在物理故障。由于公司业务变化，需要增加一台服务器跑新的应用。服务器管理员在原服务器在线的状态下，将其中一个lun映射到一台新服务器上。实际上，这个刚映射过去的卷已经map到了solaris生产系统上的某个lun上了。映射到新服务器后，服务器对这个卷进行初始化的操作，原solaris系统上的磁盘报错，重启服务器后这个卷已经无法挂载。
服务器管理员寻求sun原厂工程师的帮助。sun工程师检测后执行了fsck操作。执行完成后文件系统挂载成功。查看数据时发现多数数据丢失或者文件大小变为0，最新数据全部丢失。

服务器故障分析：
本次案例故障情况在san环境下比较常见，这类故障大多是管理员不小心所致。
正常工作模式下，san分配的卷为独立占用模式。如果管理员不小心将其映射给两个或多个操作系统，将会导致文件系统一致性出错。
这种故障下要恢复数据，首先需要分析文件系统各个结构的损坏状态。因为该数据恢复案例中，文件系统采用UFS，所以对任何一个需要恢复的文件来说，优先考虑目录信息、节点、数据区是否正常。如上述3个信息均正常，数据可完整恢复。多数情况下，执行fsck后INODE会被清除，即使目录信息还在，也无法与数据一一对应，这样就只能参考文件内部格式进行类型式的恢复。

服务器数据恢复过程：
1、对出现故障的lun进行完整备份。
2、北亚企安数据恢复工程师基于备份文件解析文件系统。经过分析发现元文件中的iNode已经被清除，无法通过还原iNode来恢复数据，只能通过文件类型进行处理。
3、服务器数据恢复工程师分析用户需要恢复的特定文件，发现采用vfs的索引文件具有强的类型特征，同时文件中包含目录信息。
4、按照vfs的索引结构特征，北亚企安数据恢复工程师编写程序提取数据，提取后根据特征重新命名。
5、按照类型恢复数据文件，之后由用户方根据索引文件重新整理数据文件。
6、经过用户方验证，确认所需要的重要数据已经全部恢复，本次数据恢复工作完成。

审核编辑 黄宇