SUN平台,光纤共享存储互斥失败导致的数据灾难恢复

作者：张宇，北亚数据恢复中心，转载请联系作者，如果实在不想联系作者，至少请保留版权，谢谢。

[数据恢复故障描述]
　　两台SPARC SOLARIS系统通过光纤交换机共享同一存储，本意是作为CLUSTER使用，但配置不当，两台SERVER并未很好地对存储互斥，设计意图为：平时A服务器正常工作，当A服务器宕掉后，关掉A，开启B接管服务。
　　偶然的机会，一位管理人员开启B服务器，查到B服务器连接了一组很大的磁盘(实际上就是那个共享存储)，因B服务器一直闲置未用，管理员以为磁盘也是闲置的，于是将整个磁盘的某个分区做了newfs。
　　A服务器很快报警并宕机，重启A服务器后，发现所有的文件系统均无法mount，执行fsck后，大多数分区的数据均修复成功，只有在B机做过newfs的文件系统结果不理想，根目录下只有一个lost+found文件夹，里面有大量数字标号的文件。
　　故障文件系统存储了两组ORACLE实例，原结构为UFS，约有200~400个数据文件需要恢复。

[数据恢复分析]
　　光纤设备的共享冲突案例很多，起缘于光纤交换的灵活性。此例中，A机与B机同时对UFS这个单机文件系统进行访问是很糟糕的，两台SERVER都以想当然的独享方式对存储进行管理，A机正常管理的文件系统其实底层上已经被B机做了文件系统初始化，A机从缓冲区写入文件系统的数据也会破坏B机初始化的结果。
　　B机newfs实际上直接会作用于原先的文件系统之上，但此例与单纯的newfs会有些不同，在A机宕机之前，会有一小部分数据(包括元数据)回写回文件系统。newfs如果结构与之前的相同，数据区是不会被破坏的，同时如果有一小部分元数据存在，部分数据恢复的可能性还是存在的。
　　UFS是传统的UNIX文件系统，以块组切割，每块组分配若干固定的inode区。文件系统newfs时，如果结构与之前的相同，文件系统最重要的inode区便会全部初始化，之前的无法保留，inode管理着所有文件的重要属性，所以单纯从文件系统角度考虑，数据恢复的难度很大。
　　好在oracle数据文件的结构性很强，同时UFS文件系统还是有一定的存储规律性，可以通过对oracle数据文件的结构重组，直接将数据文件、控制文件、日志等恢复出来。同时oracle数据文件本身会有表名称描述，也可以反向推断原来的磁盘文件名。

[数据恢复过程]
　　对故障的文件系统做dd备份。
　　针对整个镜像文件做完全的oracle数据结构分析、重组。
　　对部分结构太乱，无法重组的文件，参考ufs文件系统结构特征进行辅助分析。
　　利用恢复的数据文件、控制文件在oracle平台恢复数据库。

[数据恢复结论]
　　所有数据库完全恢复。

[后记]
　　fsck是很致命的操作，在fsck之前最好做好备份(dd即可)。
　　光纤存储的不互斥是非常多的数据灾难原因，方案应谨慎部署与实施。