博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
IBM x3850X5服务器硬盘离线数据恢复的过程
阅读量:7096 次
发布时间:2019-06-28

本文共 1208 字,大约阅读时间需要 4 分钟。

服务器数据恢复背景介绍:

客户的一台ibm x3850X5服务器上有两块硬盘由于未知故障离线,导致服务器数据丢失,需要进行数据恢复。数据恢复中心安排服务器数据恢复工程师对客户的故障服务器进行初检,客户服务器由5块硬盘组成raid5磁盘阵列、linux redhat 5.3操作系统、存储一个oracle数据库。阵列中有两块硬盘处于离线状态,热备盘未激活。硬盘无物理故障,无明显同步表现。

数据恢复中心数据恢复方案:

将故障服务器关机并保证在数据恢复过程中保持服务器关机状态,将故障盘进行标记后取出槽位挂载至数据恢复的备份服务器环境进行镜像备份。完成后恢复原故障服务器。

分析备份盘中的raid结构,得到原阵列中的raid界别、条带大小、校验方向、条带规则以及meta区域等信息。
根据分析出来的raid信息虚拟搭建一组raid5环境对磁盘文件系统进行解释,对虚拟结构的正确性检测,数据无误即可回迁数据。

服务器数据恢复及系统复原过程:

  1. 对原硬盘镜像后发现除了2号盘有10-20个坏扇区外其他硬盘均正常。
  2. 对raid结构进行分析,最佳盘序结构是0-1-2-3,缺失3号盘,结构如下图:
    IBM x3850X5服务器硬盘离线数据恢复的过程
    组好后数据验证,200M以上的最新压缩包解压无报错,按照这一结构将虚拟raid生成到一块硬盘上,通过USB的方式把恢复后的单盘接入原服务器,通过linux SystemRescueCd启动故障服务器后使用dd命令进行全盘回写。
  3. 数据回写完成后无法进入操作系统,报错信息为:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。工程师使用SystemRescueCd重启后检查发现文件的权限、时间、大小都有明显错误,对根分区再次分析定位出错的/sbin/pidof/datahf.net,得出问题原因是2号盘坏道。
  4. 通过其他盘针对2号盘的损坏区域进行xor补齐并重新校验文件系统,依然有错误,工程师只好再次对inode表进行检查,发现2号盘损坏区域有部分节点表现为(图中的55 55 55部分):
    IBM x3850X5服务器硬盘离线数据恢复的过程
    可以看出虽然节点中描述的uid还正常存在,但大小、属性、最初的分配块全部是错误的。通过日志确定原节点块的节点信息后进行修正,重新dd根分区,执行fsck -fn /dev/sda5/datahf.net检测,报错情况如下图:
    IBM x3850X5服务器硬盘离线数据恢复的过程
    经过分析发现,原来3号盘最先离线,节点信息新旧交集导致有多个节点共用数据块,工程师按节点所属的文件进行区别,清除错误节点后,再次执行fsck -fn /dev/sda5,依然有部分位于doc目录下的节点报错,由于不影响启动所以强行修复后重启系统,系统正常,启动数据库正常。

服务器数据恢复结论:

由客户方工程师对服务器数据进行验证,数据正常,数据恢复100%成功。

转载于:https://blog.51cto.com/sun510/2152171

你可能感兴趣的文章
grpc server线程退出
查看>>
JMX在Tomcat中的应用
查看>>
appache的日志和关闭错误日志的方法
查看>>
Python3 破冰
查看>>
重新定义用户界面体验:StoreFront3.0安装和配置
查看>>
python监控单台多实例数据库服务器的数据库端口
查看>>
Linux 环境变量PATH 配置
查看>>
NoSQL数据库:MongoDB的最佳实践
查看>>
squid常用命令集
查看>>
是谁在阻碍我们创新
查看>>
微信终极秘籍:精通公众号商业运营(最强作者阵容资深大号实战揭秘营销极限智慧唯一基于5.0)...
查看>>
你知道ping和traceroute,但你知道mtr网络诊断工具么?
查看>>
C++运算符重载-下篇 (Boolan)
查看>>
Js操作剪切板
查看>>
ubuntu19.04+mysql5.7 中 Mysql:ERROR 1698 (28000): Access denied for user 'root'@'localhost'
查看>>
R语言绘制横向柱装图
查看>>
掰弯Wicket: 让wicketstuff-restannotations与wicket-spri
查看>>
emacs 下载地址
查看>>
mysql 表导出/导入
查看>>
Java垃圾回收简介
查看>>