SAN LUN Mapping出错导致文件系统共享冲突的数据恢复案例
最新动态来源：本站原创点击数：21更新时间：2024/10/29
服务器数据恢复环境：
SAN光纤网络环境，存储由一组6块硬盘组建的RAID6阵列构成，划分为若干LUN，MAP到跑不同业务的SUN SOLARIS操作系统服务器上。
服务器故障&分析：
因为业务需要，用户在该光纤存储环境中新增一台SUN SOLARIS操作系统服务器。将存储中的某个LUN映射到新增的服务器上，但是映射的这个卷之前已经MAP到SOLARIS生产系统上的某个LUN上了。因为未及时察觉这个问题，新增服务器已经对该LUN进行部分初始化操作。
在SOLARIS操作系统层面磁盘报错，重启后卷无法挂载。联系SUN工程师检测后，执行了fsck操作。操作完成后虽然文件系统可以挂上，但是发现大量文件丢失或文件大小变为0，尤其是最新数据破坏严重。
此类故障在SAN光纤网络环境下较为常见，大多数情况下是人为设置不当造成的，此故障也是如此。正常情况下，SAN分配出来的LUN是独占的。LUN如果同时被几个操作系统控制就会导致写操作不互斥，文件系统一致性出错。
如果要恢复这类故障中的丢失/破坏的数据，需要深入文件系统观察各结构的破坏情况。本案例的文件系统是UFS，所以对任何一个需要恢复的文件来说，需要优先考虑目录信息、节点、数据区这几个结构是否正常。如果这3个结构均正常，数据可完整恢复。但多数情况下，执行fsck操作后INODE会被清除，即使留下目录信息，也无法与数据一一对应。这种情况下只能参考文件内部格式进行类型式的恢复。
服务器数据恢复过程：
1、以只读方式将故障卷完整镜像。后续的数据分析和数据恢复操作都基于镜像文件进行，避免对原始数据造成二次破坏。
2、基于镜像文件分析文件系统，分析发现需要恢复的文件的inode已经被全部清除，无法恢复，只能按照文件类型进行处理。
3、分析需要恢复的特定文件，发现采用vfs公文系统的索引文件具有很强的类型特征，且文件中包含目录信息。
4、按照vfs公文系统的索引结构特征，北亚企安数据恢复工程师编写程序提取数据，提取后根据特征重新命名。
5、按照类型恢复数据文件。恢复完成后由用户方根据索引文件对数据文件进行重新整理。
6、经过数据恢复工程师的努力，目录索引文件基本上全部恢复出来，大部分数据文件恢复成功。对于极小部分无法恢复的文件，用户根据目录索引文件重新向其他部门采集。用户认可数据恢复结果。