服务器数据恢复环境:
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、经过数据恢复工程师的努力,目录索引文件基本上全部恢复出来,大部分数据文件恢复成功。对于极小部分无法恢复的文件,用户根据目录索引文件重新向其他部门采集。用户认可数据恢复结果。