SAN LUN Mapping出错,文件系统共享冲突;服务器数据恢复成功

【服务器数据恢复故障描述】

本次数据恢复服务器为SUN 光纤存储系统，中心存储为6枚300G硬盘组成的RAID6，划分为若干LUN，MAP到不同业务的服务器上，服务器上运行SUN SOLARIS操作系统。

本来服务器并没有物理故障，出于用户业务需求需要再增加一台服务器用于新增应用。于是服务器管理员在原服务器在线的状态下将其中一个lun映射到一台心服务器上。管理员没有注意到的是，这个刚刚映射过去的卷已经map到了solaris生产系统上的某个lun上了，如此一来，映射到ibm服务器后，服务器对这个卷开始进行了初始化的操作，原本的solaris上的磁盘出现报错，重启服务器后这个卷已经无法挂载了。

这时候sun工程师经过检测执行了fsck操作，完成后挂载文件系统成功，查看数据时发现多数数据丢失或者文件大小为0，最新数据全部丢失。只能通过服务器数据恢复手段进行数据恢复操作。

创意配图来源于网络

【服务器数据恢复故障分析】

本次案例中的故障情况再san环境下比较多见，多数是管理员在操作时不注意导致的数据丢失。这里简单解释一下：

在正常的工作模式下，san分配的卷为独立占用模式，如果管理员将其映射给两个或多个操作系统将会导致文件系统一致性出错。

这种故障情况下如果想要进行数据恢复首先需要分析文件系统各个结构的损坏状态。在本次数据恢复案例中，因文件系统采用UFS，所以对任何一个需要恢复的文件而言，优先考虑目录信息、节点、数据区是否正常，如上述3个结构均正常，数据可完整恢复。但多数情况下，fsck后INODE会清除，即使留下目录信息，也无法与数据一一对应，这样一来就只能参考文件内部格式进行类型式的恢复了。

【服务器数据恢复过程】

1. 对出现故障的lun进行完整备份，在本次数据恢复案例中不涉及raid阵列硬件故障，所以只要直接dd就可以了。

2. 在备份文件中对文件系统进行解析，经过分析发现元文件中的iNode确实已经被清除了，无法通过还原iNode恢复数据，只能通过文件类型进行处理。

3. 服务器数据恢复工程师对用户需要恢复的特定文件进行分析，发现采用vfs公文系统的索引文件具有强的类型特征，同时文件中包含目录信息。

4. 按照公文系统的索引结构特征，写程序提取，提取后根据特征重新命名。

5. 按类型恢复数据文件，之后用户人工根据索引文件，对数据文件进行重新整理。

【数据恢复结论】

经过2个工作日的数据分析和恢复操作，服务器数据恢复工程师最终提取了客户服务器内99%的数据和目录索引文件，经过客户对恢复成功的数据验证，最终确认客户所需要的重要数据已经全部恢复，本次数据恢复成功。