北亚数据恢复中心服务器硬盘故障数据恢复方案

简介:

【基本信息】

服务器型号:IBM X3850服务器,
硬盘型号:73G SAS硬盘,
硬盘数量:5块硬盘 其中4块组成一个RAID5,另一块做为热备盘(Hot-Spare),
操作系统:linux redhat 5.3,应用系统为构架于oracle的一个oa。

【故障表现】

3号盘早已经离线,但热备盘未自动激活rebuild(原因不明),之后2号盘离线,RAID崩溃。
oracle已经不再对本oa系统提供后续支持,用户要求尽可能数据恢复+操作系统复原。

【初检结论】

热备盘完全无启用,硬盘无明显物理故障,无明显同步表现。数据通常可恢复。

【恢复方案】

1、保护原环境,关闭服务器,确保在恢复过程中不再开启服务器。
2、把故障硬盘编号排序,用以确保硬盘取出槽位后可以完全复原。
3、将故障硬盘挂载至只读环境,对所有故障硬盘做完全镜像(参考<如何对磁盘做完整的全盘镜像备份>)。备份完成后交回原故障盘,之后的恢复操作直到数据确认无误前不再涉及原故障盘。
4、对备份盘进行RAID结构分析,得到其原来的RAID级别,条带规则,条带大小,校验方向,META区域等。
5、根据得到的RAID信息搭建一组虚拟的RAID5环境。
6、进行虚拟磁盘及文件系统解释。
7、检测虚拟结构是否正确,如不正确,重复4-7过程。
8、确定数据无误后,按用户要求回迁数据。如果仍然使用原盘,需确定已经完全对原盘做过备份后,重建RAID,再做回迁。回迁操作系统时,可以使用linux livecd或win pe(通常不支持)等进行,也可以在故障服务器上用另外硬盘安装一个回迁用的操作系统,再进行扇区级别的回迁。
9、数据移交后,由我数据恢复中心延长保管数据3天,以避免可能忽略的纰漏。

【预估周期】

备份时间:2小时左右
解释及导出数据时间:约4小时
回迁操作系统:约4小时。

【恢复费用】

略。。。

【过程详解】

1、对原硬盘进行完整镜像,镜像后发现2号盘有10-20个坏扇区,其余磁盘均无坏道。
2、通过对结构的分析得到的最佳结构为0,1,2,3盘序,缺3号盘,块大小512扇区,backward parity(Adaptec),结构如下图:

图一:
1

3、组好后数据验证,200M以上的最新压缩包解压无报错,确定结构正确。

4、直接按此结构生成虚拟RAID到一块单硬盘上,打开文件系统无明显报错。
5、确定备份包安全的情况下,经客户同意后,对原盘重建RAID,重建时已经用全新硬盘更换损坏的2号盘。将恢复好的单盘用USB方式接入故障服务器,再用linux SystemRescueCd启动故障服务器,之后通过dd命令进行全盘回写。
6、回写后,启动操作系统。
7、dd所有数据后,启动操作系统,无法进入,报错信息为:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied,分析为此文件权限有问题。
8、用SystemRescueCd重启后检查,此文件时间、权限、大小均有明显错误,显然节点损坏。
9、重新分析重组数据中的根分区,定位出错的/sbin/pidof,发现问题因2号盘坏道引起。
10、使用0,1,3这3块盘,针对2号盘的损坏区域进行xor补齐。补齐后重新校验文件系统,依然有错误,再次检查inode表,发现2号盘损坏区域有部分节点表现为(图中的55 55 55部分):

图二:
2

11、很明显,虽然节点中描述的uid还正常存在,但属性,大小,以最初的分配块全部是错误的。按照所有可能进行分析,确定无任何办法找回此损坏节点。只能希望修复此节点,或复制一个相同的文件过来。对所有可能有错的文件,均通过日志确定原节点块的节点信息,再做修正。

12、修正后重新dd根分区,执行fsck -fn /dev/sda5,进行检测,依然有报错,如下图:

图三:
3

13、根据提示,在系统中发现有多个节点共用同样的数据块。按此提示进行底层分析,发现,因3号盘早掉线,帮存在节点信息的新旧交集。

14、按节点所属的文件进行区别,清除错误节点后,再次执行fsck -fn /dev/sda5,依然有报错信息,但已经很少。根据提示,发现这些节点多位于doc目录下,不影响系统启动,于是直接fsck -fy /dev/sda5强行修复。
15、修复后,重启系统,成功进入桌面。启动数据库服务,启动应用软件,一切正常,无报错。

到此,数据恢复及系统回迁工作完成。
相关文章
|
2月前
|
存储 Oracle 关系型数据库
服务器数据恢复—光纤存储上oracle数据库数据恢复案例
一台光纤服务器存储上有16块FC硬盘,上层部署了Oracle数据库。服务器存储前面板2个硬盘指示灯显示异常,存储映射到linux操作系统上的卷挂载不上,业务中断。 通过storage manager查看存储状态,发现逻辑卷状态失败。再查看物理磁盘状态,发现其中一块盘报告“警告”,硬盘指示灯显示异常的2块盘报告“失败”。 将当前存储的完整日志状态备份下来,解析备份出来的存储日志并获得了关于逻辑卷结构的部分信息。
|
3月前
|
数据挖掘
服务器数据恢复——服务器异常断电造成raid5阵列故障的数据恢复案例
某服务器上有一组由12块硬盘组建的raid5磁盘阵列。 机房供电不稳定导致机房中该服务器非正常断电,重启服务器后管理员发现服务器无法正常使用。 意外断电可能会导致服务器上的raid模块损坏。
|
12天前
|
存储 固态存储 Linux
从 0 学服务器虚拟化:VMware 搭建 3 个虚拟主机,个人 / 小企业够用的方案
服务器虚拟化技术通过在单台物理机上运行多个虚拟机,显著提升资源利用率和管理灵活性。本文以 VMware ESXi 8.0 Update 3e 为例,详解如何搭建经济实用的虚拟化环境,支持 3 个虚拟主机稳定运行,适合个人开发者和小企业降低硬件投入、实现数据本地化与安全存储。
128 0
|
2月前
|
运维 前端开发 JavaScript
半夜服务器告警不再错过!运维人员必备的语音通知方案
为解决深夜服务器宕机错过告警的问题,本文介绍一款专为个人开发者与运维人员设计的语音通知方案。通过电话直接推送重要告警,确保第一时间响应,避免故障扩大。支持多种编程语言调用,配置简单,3步即可完成,实时性强,适合各类关键业务场景。
202 5
|
19天前
|
弹性计算 监控 网络协议
香港云服务器访问速度慢?阿里云精品BGP线路EIP一键提速方案
香港云服务器因默认BGP线路访问不稳定,尤其中国大陆用户面临高延迟与丢包问题。本文详解问题根源,并介绍阿里云国际站推出的精品BGP线路EIP解决方案,通过直连优化显著降低延迟,提升稳定性,助力企业实现高效跨境网络访问。
|
26天前
|
运维 数据可视化 数据库
一小时搞定服务器软件部署:资深工程师实测方案
本文分享了一位运维工程师在短时间内将30个不同软件部署到新服务器上的实战经验。面对全新 Rocky Linux 系统,传统手工部署方式效率低下且容易出错。作者尝试多种自动化方案后,最终选择使用自动化部署工具,通过其内置的 Docker Compose 模板和可视化界面,实现快速、批量部署,大幅提升效率,30个应用仅用约1小时完成,显著节省时间和人力成本。
|
2月前
|
Oracle 安全 关系型数据库
服务器数据恢复—热备盘未成功激活导致raid崩溃的数据恢复案例
一台服务器中有5块硬盘,其中的4块组建了一组RAID5阵列,剩下一块盘作为热备盘(Hot-Spare)使用。服务器操作系统为linux,应用系统为构架于oracle数据库的一个oa。 raid5阵列中一块盘离线,但热备盘未自动激活rebuild。直到另外一块盘离线,RAID崩溃。 由于oracle已经不再对本案例中的oa系统提供后续支持,用户方要求尽可能恢复数据和操作系统。经过检测发现热备盘完全没有启用,硬盘无明显物理故障,无明显同步表现。
|
3月前
|
存储 数据挖掘 数据库
服务器数据恢复—ocfs2文件系统数据恢复案例
服务器存储数据恢复环境&故障: 人为误操作将Ext4文件系统误装入一台服务器存储上的Ocfs2文件系统数据卷上,导致原Ocfs2文件系统被格式化为Ext4文件系统。
|
3月前
服务器数据恢复—服务器raid5阵列2块硬盘掉线的数据恢复案例
某品牌型号为X3850服务器上有一组由14块数据盘和1块热备盘组建的raid5磁盘阵列。 服务器在正常使用过程中突然崩溃,管理员查看raid5阵列故障情况的时发现磁盘阵列中有2块硬盘掉线,但是热备盘没有启用。
|
12天前
|
弹性计算 编解码 大数据
性价比最高提升50%!阿里云企业级云服务器上新
阿里云ECS云服务器推出全新升级的u2系列实例,包括基于Intel的u2i实例与首个基于AMD的u2a实例,提供企业级独享算力,综合性价比最高提升50%。u2i实例已开放公测,适用于中小型数据库、企业网站建设等场景。同时发布基于AMD的第九代旗舰实例g9ae,性能提升65%,适用于大数据、视频转码等密集型业务。
82 1

热门文章

最新文章