【北亚服务器数据恢复】san环境下LUN Mapping出错导致文件系统一致性出错的数据恢复案例

本文主要是介绍【北亚服务器数据恢复】san环境下LUN Mapping出错导致文件系统一致性出错的数据恢复案例，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

服务器数据恢复环境：
san环境下的存储上一组由6块硬盘组建的RAID6，划分为若干LUN，MAP到跑不同业务的服务器上，服务器上层是SOLARIS操作系统+UFS文件系统。

服务器故障：
业务需求需要增加一台服务器跑新增的应用，工作人员在原服务器在线的状态下将其中一个lun映射到一台新服务器上。实际上这个刚映射过去的卷已经map到了solaris生产系统上的某个lun上了。新服务器对这个映射过来的卷进行初始化，原来的solaris系统上的磁盘报错，重启服务器后这个卷已经无法挂载了。
联系原厂工程师寻求帮助，原厂工程师检测后执行了fsck操作，完成fsck操作后文件系统挂载成功，查看数据时发现大量数据丢失或者文件大小变为0，最新的数据全部丢失。
本案例故障情况在san环境下比较常见，多数情况下是工作人员在没有考虑充分的情况下进行操作导致数据丢失。

在正常的工作模式下，san分配的卷为独立占用模式，如果将卷映射给两个或多个操作系统，就会导致文件系统一致性出错。
在这种故障情况下恢复数据，首先需要分析文件系统各个结构的损坏状态。本案例的文件系统是UFS，所以对任何一个需要恢复的文件，我们需要考虑目录信息、节点、数据区是否正常。如果上述三者均正常，数据可完整恢复。但多数情况下，执行fsck后INODE会被清除，即使留下目录信息，也无法与数据一一对应，这种情况下就只能参考文件内部格式进行类型式的恢复了。

服务器数据恢复过程：
1、将出现问题的lun完整备份，后续的数据分析和数据恢复操作都在备份文件进行，避免对原始数据造成二次破坏。
2、基于备份文件解析文件系统，经过分析发现文件中的iNode已经被清除，无法通过还原iNode的方式来恢复数据，只能通过文件类型进行处理。
3、对用户需要恢复的特定文件进行分析，发现采用vfs公文系统的索引文件具有强的类型特征，而且文件中包含目录信息。
4、按照vfs公文系统的索引结构特征，北亚企安数据恢复工程师编写程序提取数据，提取数据完成后根据特征重新命名。
5、按类型恢复数据文件，然后由用户方根据索引文件重新整理数据文件。
6、整理完成后对恢复出来的数据进行检测，检测完成后用户方确认恢复数据完整有效。本次服务器数据恢复工作完成。