【服务器数据恢复】服务器光纤共享存储互斥失败的数据恢复案例

服务器数据恢复环境:
两台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操作之前最好做好备份。光纤存储的不互斥是很多数据灾难发生的原因,应谨慎部署与实施。

你可能感兴趣的:(数据恢复)