磁盘阵列raid后数据恢复 服务器数据恢复
来源：互联网 2023-06-25 16:04:02
hello大家好，我是城乡经济网小晟来为大家解答以上问题，磁盘阵列raid后数据恢复，服务器数据恢复很多人还不知道，现在让我们一起来看看吧！
服务器数据恢复环境：
ibm x3850系列服务器；
(资料图)
5块硬盘组成raid5磁盘阵列；
linux redhat 5.x操作系统；
oracle数据库。
服务器故障：
服务器上两块硬盘由于未知故障离线，服务器数据丢失，管理员联系我们数据恢复中心要求恢复故障服务器的数据。经过服务器数据恢复工程师对故障服务器进行初检，发现服务器阵列中有两块硬盘处于离线状态，热备盘未激活。硬盘无物理故障，无明显同步表现。
服务器数据恢复过程：
1、将故障服务器关机，标记好故障盘后取出槽位挂载至准备好的数据恢复服务器环境进行镜像备份。对原硬盘镜像后发现除了2号盘有10-20个坏扇区外其他硬盘均正常。完成镜像后将硬盘重新安装到原服务器。
2、服务器数据恢复工程师分析备份盘中的raid结构，获取阵列中的raid条带大小、校验方向、条带规则以及meta区域等信息。经过分析发现最佳盘序结构是0-1-2-3，缺失3号盘，结构如下图：
北亚数据恢复——raid5数据恢复
根据分析出来的raid信息虚拟搭建一组raid5环境，组好后进行数据验证，200M以上的最新压缩包解压无报错，按照这一结构将虚拟raid生成到一块硬盘上，通过USB的方式把恢复后的单盘接入原服务器，通过软件启动故障服务器后进行全盘回写。
3、数据回写完成后无法进入操作系统，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。数据恢复工程师重启服务器后发现文件的权限、时间、大小都有明显错误，对根分区再次分析定位出错的/sbin/pidof/，发现问题的原因是2号盘坏道。
4、利用其他盘对2号盘的损坏区域进行xor补齐并重新校验文件系统，依然报错，数据恢复工程师再次对inode表进行检查，发现2号盘损坏区域有部分节点表现为(图中的55 55 55部分)：
北亚数据恢复——raid5数据恢复
5、虽然节点中描述的uid还正常存在，但大小、属性、最初的分配块全部是错误的。通过日志确定原节点块的节点信息后进行修正，重新dd根分区，执行fsck -fn /dev/sda5检测，报错情况如下图：
北亚数据恢复——raid5数据恢复
6、经过分析发现，原来3号盘最先离线，节点信息新旧交集导致有多个节点共用数据块。数据恢复工程师按节点所属的文件进行区别，清除错误节点后再次执行fsck -fn /dev/sda5，依然有部分位于doc目录下的节点报错。由于不影响启动所以强行修复后重启系统，系统正常，启动数据库正常。
7、由服务器管理员亲自对服务器数据进行验证，验证结果表示数据正常，数据恢复成功。
本文就为大家讲解到这里，希望对大家有所帮助。
