服务器数据恢复—SAN环境下LUN映射出错导致文件系统共享冲突的数据恢复案例

服务器存储数据恢复环境：
一台存储中有一组由6块硬盘组成的RAID6，划分为若干LUN，MAP到不同业务的SOLARIS操作系统服务器上。

服务器存储故障：
由于业务变化需要增加一台服务器，在存储在线的状态下将该存储中的某个LUN映射到这台新增加的服务器上并开始初始化，不料映射的这个LUN已经MAP到其他SOLARIS服务器上了。由于该LUN已经进行了部分的初始化，磁盘报错，重启后发现卷无法挂载。
SUN工程师检测后执行了fsck操作，执行fsck操作后文件系统虽然可以挂上，但是发现很大量数据丢失或文件大小变为0，特别是最新的数据损坏严重。
此类故障在SAN环境下较为常见，多数是人为导致，本案例情况就是如此。SAN分配出来的LUN是采用独占模式的，如果同时被几个操作系统控制，就会导致写操作不互斥，继而出现文件系统一致性出错的问题。
针对这类问题的数据恢复，需要深入文件系统，观察并分析具体的结构破坏情况。本案例中的文件系统是UFS，所以对任何一个需要恢复的文件而言，我们需要优先考虑目录信息、节点、数据区是否正常。如果这3个结构均正常，数据可完整恢复。多数情况下，执行fsck操作后INODE会被清除，即使留下目录信息，也无法与数据一一对应。这种情况下只能参考文件内部格式进行类型式的恢复了。

服务器存储数据恢复过程：
1、完整备份故障卷。因为RAID无故障，所以可以直接在SOLARIS环境中对原LUN做dd备份。后续的数据分析和数据恢复操作都在备份文件中进行，避免对原始数据造成二次破坏。
2、基于备份文件分析文件系统。经过分析确认需要恢复文件的inode已经被全部清除，无法恢复，只能按照文件类型进行处理。
3、分析需要恢复的特定文件，发现采用vfs文件系统的索引文件具有强的类型特征，同时文件中包含目录信息。
4、按照vfs文件系统的索引结构特征，北亚企安数据恢复工程师编写程序提取数据文件，提取完成后根据特征重新命名。
5、按类型恢复数据文件后，根据索引文件重新整理数据文件。
6、上述数据恢复操作完成后交由用户方检测。经过用户方仔细检测，发现目录索引文件基本上完整恢复，大部分数据文件恢复成功。针对无法恢复的文件，只能根据目录索引文件重新采集。用户方认可数据恢复结果。

审核编辑 黄宇