IBM X3650服务器数据恢复解决方案

在网络大环境下，服务器是其中的重要组成部分，基本是我们平时所享受的服务大部分都是服务器管理并提供。服务器一旦出现问题，不仅仅影响千万人正常使用服务，同时也对服务提供商造成无法估计的损失。

这次小编给大家分享一起由5块SAS 600GB硬盘组成RAID5的IBM X3650服务器数据恢复的案例，通过案例我们来看看服务器的数据恢复过程。

在该案例里面，其中4块硬盘组成RAID5，另一块硬盘作为热备盘。服务器成员盘一开始先掉线一块RAID变成降级状态，热备盘被启用。在服务器数据同步的过程中，随后又有另一块硬盘离线，造成了RAID损坏无法读取数据。

根据情况，我们制定了以下方案：

一、先检测硬盘情况，分析溯源故障原因

由于服务器是因为RAID阵列首先有一只硬盘掉线了，掉线后系统启用热备盘，可在同步过程中，又因为有其他硬盘掉线，最终导致服务器不可用。根据情况判断，我们先对所有硬盘进行物理检测。发现最先掉线的3号硬盘是由于磁头损坏导致的，后面掉线的1号和2号硬盘是坏道导致。

二、备份数据

数据恢复最基本的是要确保数据的安全性以及可还原性，因此，在数据恢复前需要将所有硬盘数据进行一个镜像备份，以避免因其他原因导致数据无法再次恢复。

三、分析阵列信息

将备份好的镜像挂载至只读环境，对所有镜像进行阵列信息的分析，确定数据的时效性，完整性。通过分析得知，原阵列的XOR分块的大小为128扇区，结构为0 1 2 3 ，3号为先离线的硬盘。

四、虚拟重建阵列并检验数据

分析完阵列信息，我们将镜像挂载到虚拟环境上进行重组，恢复原来服务器掉线时的状态，恢复重建目录信息，检查数据是否完整。

在检查过程中发现一个最新修改日期的数据库做DBCC 检查时有2个一致性错误。

再检查镜像出来的镜像文件发现全部正常，应该是服务器在运行时数据库有写入造成的一致性错误。这个问题不大，通过运行SQL Server 的dbcc 修复语句进行修复后，恢复正常。

整个服务器恢复过程到这里大致上完成，但最后迁回到原机器上的时候，我们发现原机器背板也是有问题，通过与客户沟通协商，最后我们根据客户要求，将系统和数据迁移到另一台同型号的好机器上，到此完满结束。

这么多年来，凭借我们过硬的实力和良好的服务，得到了广大客户和同行的一致肯定。我们很高兴我们的付出能帮助到大家，我们会不断地鞭策和提升自己，如有需要的小伙伴们，可以关注我们，联系我们。我们下期再见。