开发者社区> 北亚企安> 正文

IBM服务器raid5崩溃数据恢复方案及过程

简介:
+关注继续查看

概述:
    IBM X3850服务器,5块73G SAS硬盘,其中4块组成一个RAID5,另一块做为热备盘(Hot-Spare),3号盘早已经离线,但热备盘未自动激活rebuild(原因不明),之后2号盘离线,RAID崩溃。
    操作系统为linux redhat 5.3,应用系统为构架于oracle的一个oa,数据重要,时间很急。因oracle已经不再对本oa系统提供后续支持,用户要求尽可能数据恢复+操作系统复原。热备盘完全无启用,硬盘无明显物理故障,无明显同步表现。数据通常可恢复
【恢复方案】
    1、保护原环境,关闭服务器,确保在恢复过程中不再开启服务器。
    2、将故障硬盘标好序号,确保在拿出槽位后可以完全复原。
    3、将故障硬盘挂载至北亚数据恢复备份服务器环境下,对所有故障硬盘做完全镜像。备份完成后交回原故障盘,之后的恢复操作直到数据确认无误前不再涉及原故障盘。
    4、对备份盘进行RAID结构分析,得到其原来的RAID级别,条带规则,条带大小,校验方向,META区域等。
    5、根据得到的RAID信息搭建一组虚拟的RAID5环境。
    6、进行虚拟磁盘及文件系统解释。
    7、检测虚拟结构是否正确,如不正确,重复4-7过程。
    8、确定数据无误后,按用户要求回迁数据。如果仍然使用原盘,需确定已经完全对原盘做过备份后,重建RAID,再做回迁。回迁操作系统时,可以使用linux livecd或win pe(通常不支持)等进行,也可以在故障服务器上用另外硬盘安装一个回迁用的操作系统,再进行扇区级别的回迁。
9、数据移交后,由北亚数据恢复中心延长保管数据3天,以避免可能忽略的纰漏。

数据恢复及系统复原过程
    1、对原硬盘进行完整镜像,镜像后发现2号盘有10-20个坏扇区,其余磁盘,均无坏道。
    2、分析结构:得到的最佳结构为0,1,2,3盘序,缺3号盘,块大小512扇区,backward parity(Adaptec),结构如下图:
 608e6b422a5cb5a44611bfb970d72cf8f196fa54图一
    3、组好后数据验证,200M以上的最新压缩包解压无报错,确定结构正确。
    4、直接按此结构生成虚拟RAID到一块单硬盘上,打开文件系统无明显报错。
    5、确定备份包安全的情况下,经客户同意后,对原盘重建RAID,重建时已经用全新硬盘更换损坏的2号盘。将恢复好的单盘用USB方式接入故障服务器,再用linux SystemRescueCd启动故障服务器,之后通过dd命令进行全盘回写。
    6、回写后,启动操作系统。正常情况下,这时候所有工作应该完成了。不巧的是,因帮颇费周折才解决,特意另起一段叙述。
 
系统复原过程:
    dd所有数据后,启动操作系统,无法进入,报错信息为:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied  
    怀疑此文件权限有问题,用SystemRescueCd重启后检查,此文件时间,权限,大小均有明显错误,显然节点损坏。
    重新分析重组数据中的根分区,定位出错的/sbin/pidof/datahf.net,发现问题因2号盘坏道引起。
    使用0,1,3这3块盘,针对2号盘的损坏区域进行xor补齐。补齐后重新校验文件系统,依然有错误,再次检查inode表,发现2号盘损坏区域有部分节点表现为(图中的55 55 55部分):
 4f9b60c05fa11050a8d3eb9258b6fd5713c94091图二 
    很明显,虽然节点中描述的uid还正常存在,但属性,大小,以最初的分配块全部是错误的。按照所有可能进行分析,确定无任何办法找回此损坏节点。只能希望修复此节点,或复制一个相同的文件过来。
    对所有可能有错的文件,均通过日志确定原节点块的节点信息,再做修正。
    修正后重新dd根分区,执行fsck -fn /dev/sda5/datahf.net,进行检测,依然有报错,如下图:
 14c82183b628c496e20526e6f101f3455e711e01图三
    根据提示,在系统中发现有多个节点共用同样的数据块。按此提示进行底层分析,发现,因3号盘早掉线,帮存在节点信息的新旧交集。
    按节点所属的文件进行区别,清除错误节点后,再次执行fsck -fn /dev/sda5,依然有报错信息,但已经很少。根据提示,发现这些节点多位于doc目录下,不影响系统启动,于是直接fsck -fy /dev/sda5/datahf.net强行修复。
    修复后,重启系统,成功进入桌面。
    启动数据库服务,启动应用软件,一切正常,无报错。
    到此,数据恢复及系统回迁工作完成。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 27 章 恢复配置_27.3. 后备服务器设置
27.3. 后备服务器设置 standby_mode (boolean) 指定是否将PostgreSQL服务器作为一个后备服务器启动。如果这个参数为on,当到达已归档 WAL 末尾时该服务器将不会停止恢复,但是将通过使用restore_command获得新的 WAL 段以及/或者通过使用primary_conninfo设置连接到主服务器来尝试继续恢复。
1491 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 27 章 恢复配置_27.2. 恢复目标设置
27.2. 恢复目标设置 默认情况下,恢复将会一直恢复到 WAL 日志的末尾。下面的参数可以被用来指定一个更早的停止点。在recovery_target、recovery_target_lsn、recovery_target_name、recovery_target_time和recovery_target_xid中,最多只能使用一个,如果在配置文件中使用了多个,将使用最后一个。
1223 0
+关注
55
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载