共计 1182 个字符，预计需要花费 3 分钟才能阅读完成。
服务器数据恢复环境：
两台 SPARC SOLARIS 零碎通过光纤交换机共享同一存储作为 CLUSTER 应用，失常状况下 A 服务器工作，当 A 服务器产生故障宕机后即可将其关机而后开启 B 服务器接管。
服务器故障：
因为服务器配置不当导致两台服务器没有做好对存储的互斥。
管理员进行巡逻时开启 B 服务器，查看到 B 服务器连贯了一组未知的大容量磁盘。因为 B 服务器并未启用处于闲置的状态，所以管理员本能的认为 B 服务器连贯的那一组大容量磁盘也处于闲置状态，于是将整个磁盘的某个分区做了 newfs。没有想到这个磁盘就是那个共享存储，没多久 A 服务器报警并宕机。
管理员重启了 A 服务器，发现所有的文件系统均无奈 mount。管理员执行了 fsck，除了在 B 机做过 newfs 的文件系统其余分区的数据都修复胜利，在 B 机做过 newfs 的文件系统的根目录下只有一个 lost+found 文件夹，外面有大量数字标号的文件。故障文件系统存储了两组 ORACLE 实例，原构造为 UFS，约有 200~400 个数据文件须要复原。
服务器故障剖析：
光纤设施的共享抵触案例很多。本案例中 A 服务器与 B 服务器同时对 UFS 这个单机文件系统进行拜访，两台服务器都以想当然的独享形式对存储进行治理。A 服务器失常治理的文件系统底层上其实曾经被 B 服务器做了文件系统的初始化，A 服务器从缓冲区写入文件系统的数据也会毁坏 B 服务器初始化的后果。
B 服务器 newfs 实际上会间接作用于原先的文件系统之上，但本案例与单纯的 newfs 有些不同：在 A 服务器宕机之前会有一小部分数据 (包含元数据) 回写到文件系统。如果 newfs 的构造与之前的雷同，数据区是不会被毁坏的，如果有一小部分元数据存在，还是有可能复原局部数据的。
UFS 是传统的 UNIX 文件系统，以块组切割，每块组调配若干固定的 inode 区。如果文件系统 newfs 的构造与之前的雷同，文件系统最重要的 inode 区便会全副初始化，之前的无奈保留。因为 inode 治理着所有文件的重要属性，所以单纯从文件系统角度复原数据的难度很大。好在 oracle 数据文件的结构性很强，同时 UFS 文件系统有肯定的存储法则，能够通过对 oracle 数据文件的构造重组，间接将数据文件、管制文件、日志等复原进去。同时 oracle 数据文件自身有表名称形容，能够反向推断原来的磁盘文件名。
服务器数据恢复过程：
1、对故障的文件系统做镜像备份。
2、北亚服务器数据恢复工程师针对整个镜像文件做齐全的 oracle 数据结构剖析、重组。
3、参考 ufs 文件系统结构特征，北亚工程师对局部构造太乱，无奈重组的文件进行辅助剖析。
4、利用复原进去的数据文件、管制文件在 oracle 平台复原数据库。最终复原出所有数据库数据。
服务器数据恢复 Tips：
fsck 是很致命的操作，在执行 fsck 操作之前最好做好备份。光纤存储的不互斥是很多数据劫难产生的起因，应审慎部署与施行。
