服务器数据恢复环境：

两台SPARC SOLARIS操作系统服务器通过光纤交换机共享一台存储作为集群使用。平时是一台服务器（以下称为主服务器）在运行，如果该服务器发生故障宕机，只需要将这台服务器关机后开启另外一台服务器（以下称备用服务器）进行接管即可。由于配置不当，两台服务器不能很好地对存储互斥。

服务器故障&分析：

管理员在对服务器进行巡检时开启备用的那台服务器，该服务器连接了一组未知的大容量磁盘。由于该服务器在主服务器正常工作的情况下不会启用，处于闲置的状态，所以管理员误以为该服务器连接的这块大容量磁盘也处于闲置状态，于是将该大容量磁盘的某个分区做了newfs。然而这个大容量磁盘就是那台共享存储，主服务器报警宕机。

为了挽救数据，管理员做了以下操作：1、重启主服务器，但所有文件系统均无法挂载。2、执行fsck，多数分区的数据修复成功，只有在备用服务器做过newfs的文件系统有问题，根目录下只有一个lost+found文件夹，里面有大量数字标号的文件。

故障文件系统存储了两组ORACLE实例，原文件系统为UFS，约有200~400个数据文件需要恢复。

这是一个典型的由于配置不当，服务器不能很好地对存储互斥导致共享冲突的案例。本案例中的2台服务器同时对UFS这个单机文件系统进行访问，以想当然的独享方式对存储进行管理，主服务器管理的文件系统其实在底层上已经被备用服务器做了文件系统初始化，主服务器从缓冲区写入文件系统的数据也会破坏备用服务器初始化的结果。

在备用服务器上执行newfs会作用于原先的文件系统之上，但本案例中的情况和单纯的newfs有些不同。在主服务器宕机之前，会有一小部分数据（包括元数据）会写回文件系统。文件系统newfs如果结构与之前的相同，数据区是不会被破坏的。

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

服务器数据恢复过程：

1、对故障文件系统做镜像备份。

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

3、对部分结构混乱，无法重组的文件，参考ufs结构特征进行辅助分析。

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

5、恢复完成后，由用户方工程师进行检测，经过反复检测，用户方确认恢复出来的数据完整有效。本次数据恢复工作完成。

服务器数据恢复总结：

fsck是很致命的操作，在执行fsck操作之前最好做备份。