服务器数据恢复环境&故障：

两台SOLARIS系统（SPARC平台）的服务器通过光纤交换机共享同一个存储作为CLUSTER使用。正常情况下只有A服务器工作。如果A服务器发生故障宕机，可将A服务器关机，开启B服务器接管。但由于配置不当导致共享存储互斥出现问题。

管理员进行运维检查时发现B服务器连接了一块未知磁盘。由于B服务器并未启用，处于闲置状态，所以管理员也将这块磁盘当作闲置的，于是在B服务器上将磁盘的某个分区做了newfs。没想到这块磁盘就是那个共享存储，执行操作没有多长时间A服务器就开始报警并宕机。

发生问题后，管理员又做了如下操作：1、重启A服务器但发现所有的文件系统均无法挂载。2、执行fsck。多数分区数据修复成功，只有在B服务器做过newfs的文件系统修复结果不理想，根目录下只有一个lost+found文件夹，里面有大量数字标号的文件。

故障文件系统存放了两组ORACLE实例，文件系统为UFS，约有数百个数据文件需要恢复。

服务器数据恢复—光纤环境下共享存储互斥不当导致共享存储上数据丢失的数据恢复案例_存储数据恢复

故障分析&数据恢复方案：

光纤环境下的共享冲突案例很多。本案例中，A服务器与B服务器同时对UFS这个单机文件系统进行访问，两台服务器都以独享方式对共享存储进行管理。A服务器正常管理的文件系统其实底层上已经被B服务器做了文件系统初始化，A服务器从缓冲区写入文件系统的数据也会破坏B服务器初始化的结果。

B服务器上做newfs实际上直接会作用于原先的文件系统之上，但本案例与单纯的newfs有些不同，在A服务器宕机之前，会有一小部分数据(包括元数据)回写回文件系统。newfs的结构如果与之前的相同，数据区是不会被破坏的。如果有一小部分元数据存在，部分数据还是可以恢复的。

UFS文件系统以块组切割，每块组分配若干固定的inode区。文件系统newfs时，如果结构与之前的相同，文件系统最重要的inode区会全部初始化，之前的无法保留。inode管理着所有文件的重要属性，所以单纯从文件系统角度考虑，数据恢复的难度很大。幸亏oracle数据文件的强结构性和UFS文件系统的规律性，可以通过对oracle数据文件的结构重组，将数据文件、控制文件、日志等恢复出来。oracle数据文件本身会有表名称描述，也可以反向推断原来的磁盘文件名。


服务器数据恢复过程：

1、将所有文件系统做只读镜像。

2、基于镜像文件分析&重组oracle数据结构。

3、针对部分结构乱，无法重组的文件，北亚企安数据恢复工程师参考ufs文件系统结构特征进行辅助分析。

4、利用恢复出来的数据文件、控制文件在oracle平台恢复数据库。

5、恢复完所有数据库文件后，交由用户方检测。经过仔细检测，确认恢复出来的数据完整。


Tips：

fsck是很致命的操作，在fsck之前最好做好备份。光纤环境中存储互斥不当是非常多的数据灾难的原因，应谨慎部署与实施。