ibm 3650 raid5恢复 ibm x3650m4 重做raid

X3850服务器，五个73G SAS硬盘，其中四个形成RAID5，另一个是热备盘。3号磁盘长期脱机，但热备盘没有自动激活重建(原因不明)。然后，2号磁盘离线，RAID崩溃。操作系统是linux redhat 5.

X3850服务器，五个73G SAS硬盘，其中四个形成RAID5，另一个是热备盘。3号磁盘长期脱机，但热备盘没有自动激活重建(原因不明)。然后，2号磁盘离线，RAID崩溃。操作系统是linux redhat 5.3，应用系统是基于oracle的oa。数据很重要，时间很紧迫。由于oracle不再对该oa系统提供后续支持，用户要求尽可能做到数据恢复+操作系统恢复。

【初检恢复方案】根据北亚工程师的检查，完全没有启用热备，硬盘没有明显的物理故障，没有明显的同步性能。通常情况下，数据是可以恢复的，工程师已经给出了解决方案:1。保护原始环境，关闭服务器，并确保在恢复过程中不会再次打开服务器。2.标记故障硬盘的序列号，确保取出插槽后可以完全恢复。3.将故障硬盘安装到只读环境，并完全镜像所有故障硬盘。备份完成后，归还原故障磁盘，在确认数据正确之前，后续恢复操作不会涉及原故障磁盘。4.分析备份磁盘的RAID结构，得到其原始RAID级别、条带规则、条带大小、校验方向、元区域等。5.根据获取的RAID信息构建虚拟RAID5环境。解释虚拟磁盘和文件系统。6.检查虚拟结构是否正确。如果没有，重复4-7的过程。确认数据无误后，根据用户要求取数据。如果仍在使用原始磁盘，有必要确保原始磁盘已完全备份，重建RAID，然后进行回迁。在迁移操作系统时，可以使用linux livecd或者win pe(一般不支持)等。或者，您可以安装一个操作系统，以便在故障服务器上用另一个硬盘进行迁移，然后在扇区级别进行迁移。【数据恢复流程】1。镜像原硬盘后发现2号盘有10-20个坏扇区，其余盘无坏磁道。2.结构分析:得到的最佳结构是0，1，2，3盘序列，第三盘缺失。3.数据组装后，验证200M以上的最新压缩包解压缩时没有错误，结构正确。4.虚拟RAID是按照这种结构直接在单个硬盘上生成的，打开文件系统没有明显错误。5.在确定备份包安全的情况下，会在客户同意的情况下重建原盘的RAID，重建时已经将损坏的2号盘更换为新的硬盘。通过USB将恢复的单个磁盘连接到故障服务器，然后通过linux SystemRescueCd启动故障服务器，再通过dd命令写回整个磁盘。6.写回后，启动操作系统。【系统恢复过程】dd所有数据后，启动操作系统，无法进入，错误信息为:/etc/RC . d/RC . sysinit:line 1:/sbin/pidof:权限被拒绝。怀疑该文件的权限有问题。用SystemRescueCd重新启动后，发现文件在时间、权限、大小上有明显错误，节点明显损坏。重新分析重组数据中的根分区，定位错误的/sbin/pidof，发现问题是2号盘坏磁道造成的。使用三个磁盘0、1和3，对磁盘2的损坏区域进行异或运算。补上后，mcrc系统再次出现错误。再次查看inode表，发现2号盘损坏区域有一些节点。显然，虽然节点中描述的uid仍然正常存在，但是属性、大小和初始分配块都是错误的。根据所有可能的分析，确定没有办法恢复这个损坏的节点。您只能修复此节点或复制一个相同的文件。对于所有可能有错误的文件，通过日志确定原始节点块的节点信息，然后进行修正。更正后重新添加根分区，执行fsck -fn /dev/sda5，仍然报错。

根据提示，发现系统中多个节点共享同一个数据块。根据这个提示，底层分析显示，由于3号盘早期断网，新老节点信息没有交集。根据节点所属的文件，清除错误节点后，再次执行fsck -fn /dev/sda5，仍然很少有错误消息。根据提示发现这些节点大多位于doc目录下，不影响系统启动，所以fsck -fy /dev/sda5直接强制修复。修复后重启系统，成功进入桌面。启动数据库服务，启动应用软件，一切正常，没有错误。至此，数据恢复和系统迁移完成。