手动修复服务器阵列盘混乱实例一则（服务器和磁盘阵列的区别）
网管小贾 / sysadm.cc
人们使用阵列 RAID 这种方式来确保服务器磁盘上的数据安全由来已久。
阵列通常指的是磁盘阵列，大意为具有冗余能力的磁盘组合。
虽然阵列可以一定程序上保证了磁盘上的数据不丢失，但它还是有缺点的，其中最为严重的便是一旦阵列自身出现了问题，那真的是相当的麻烦。
一般来说，服务器阵列上的某块硬盘故障损坏，那么将它取下换上新的硬盘，阵列会自动识别并重建同步。
可是这一回，我们就要说一说二般的情况，就是它并不会自动重建，从而导致阵列出现了不可描述的问题。
公元某年某月某日，某某找到我，说他们部门有不新不旧、不好不坏的那么一台服务器放在某个神秘的角落里很长时间，好像出了问题，最近速度慢得不行。
在此之前它一直在正常工作着，可不知道什么时候，有人注意到它的硬盘居然闪着黄灯，明显是报警有故障啊，之后速度就越来越慢，于是找到我让我确认一下。
听完这个小故事后我当即打了个冷颤，感觉不像天灾更多的是人祸，但好奇心驱使我想去看看怎么回事。
来到光线昏暗的厂房内，在穿过张牙舞爪、奇形怪状的一排排机器后，我们步入了一座仓库。
又七拐八绕转过了堆满杂乱物品的货架，我们的脚步停留在了一个阴暗的角落。
这里只有一盏并不怎么亮堂的小灯，在光线不足的情况下，我一眼就瞥见了那诡异的硬盘指示灯，它们正幽幽地闪烁着，其中有一个是黄色的光。
我蹲下身子，大概的瞧了一眼这台落满灰尘的服务器，初步判断应该是磁盘阵列故障。
我环视了光线昏暗、拥挤不堪地四周，皱了皱眉头示意他们还是将这台服务器拿到我的工作台处理。
很快我的工作台上出现了这台服务器，于是我开始和它打起了交道......
收集可用信息，以备不时之需与以往处理故障不同，这次我并不需要解剖尸体，但表面观察还是要有的，于是我给它做了个简单的清洁工作。
这是一台Dell塔式服务器，一共三块硬盘，并按槽位顺序排列着。
在断电的情况下，我按顺序分别取下它们，并对应地记录下它们的型号和序列号。
OK，重新放回它们原有的位置，开机继续观察。
1、开机按 F2 进入系统设置程序 System Setup。很明显这台服务器的阵列卡是 H330 的。
一共有五项，分别是：
Configuration Management 配置管理Controller Management 控制器管理Virtual Disk Management 虚拟磁盘管理Physical Disk Management 物理磁盘管理Hardware Components 硬件组成基本上所有的阵列操作都在这些菜单项中了。
为了进一步确定故障的具体情况，我们需要确认阵列的现状，然后再进行下一步的操作。
我们选择主菜单的第一项 配置管理 Configuration Management 。
当前阵列有问题是没跑了，但目前我们只看到了它是 Raid 1 形式，至于这三块硬盘中究竟是哪两块组合成 Raid 1 我们还无法确定，所以还需要再看看有没有更多的信息以便我们在下一步操作、判断和处理问题时需要用到。
还是回到主菜单，进入 虚拟磁盘管理 Virtual Disk Management 。
和前面看到的一样，就一个 Raid 1 的阵列，状态是降级状态。
走过路过，不要错过，我们进去瞧上一瞧。
哎，有一项 View Associated Physical Disks ，意思是查看相关物理磁盘，进去看看。
呃...画面显示当前的 Raid 1 阵列成员是两块硬盘，一块在线，另一块则是失败状态。
阵列有问题自然不用说，不过你要是再仔细一瞧，你就会发现，哎，为啥这两块硬盘不是按顺序来的第一和第二块，而是第一和第三块呢？！
没看到？你看那个编号， 00:01:00 和 00:01:02 ，很明显是第一块和第三块嘛。
要是还不太确信，那么将编号是 00:01:02 的这块硬盘打上勾，点击下方的 View Physical Disk Properties 来直接查看它的物理属性信息。
这个时候，你可以在操作项中选择 Blink 和 Unblink ，再点击 Go 来测试哪一块是你在看的当前硬盘。
Blink 和 Unblink 的意思分别是闪烁和停止闪烁，你可以用这个操作来定位实际服务器上的哪一块硬盘。
当然，你也可以将硬盘的型号和序号对照，我们在开始之前是有记录过的。
果不其然，就是按顺序数下来的第三块硬盘。
好了，到目前为止，再结合之前的种种情况，最终印证了当前的 Raid 1 阵列的确是有问题的。
那么总结一下，当前阵列应该是只有第一块硬盘是正常工作着，其他两块处于失控状态。
如何修复阵列好了，故障情况已经清楚了，接下来就是制定具体的修复方案。
首先，数据最重要，肯定是先备份数据，其中也应该将失效硬盘上的部分数据备份（第二块和第三块硬盘被他们当作正常硬盘放入了数据）。
其次，由于第一块硬盘还算工作正常，所以不能轻易动它，应该将第二块硬盘转换为阵列成员，并与第一块重建同步数据。
再次，为加固 Raid 1 的安全性，应该将第三块硬盘转换成热备盘。
最后，确认阵列修复情况，并将数据恢复到阵列盘上。
实际操作说了这么多，除去数据备份等准备工作外，我们来看看具体的修复当前阵列的操作步骤。
由于当前阵列成员是第一块和第三块（虽然它是失败状态），而第二块硬盘成了游荡在外的落魄者，所以我们应该先将第三块变成非阵列成员，然后再将第二块硬盘正名，让它回来做它该做工作。
一、将第三块硬盘下线1、主菜单中选择 物理磁盘管理 Physical Disk Management ，选择第三块（编号 00:01:02 ）磁盘。
2、选择 强制离线 操作，将第三块硬盘强制下线。
3、看清提示，确认 Confirm 处打勾后点击 Yes 。
4、操作完成，点击 OK 返回。
1、主菜单中选择 物理磁盘管理 Physical Disk Management ，选择第二块（编号 00:01:01 ）磁盘。
2、操作选择转换为阵列兼容 Convert to RAID Capable ，然后点击 Go 。
3、操作完成，点击 OK 返回。
4、主菜单进入 虚拟磁盘管理 Virtual Disk Management，并选择当前阵列后，选择查看相关磁盘 View Associated Physical Disks 一项。
5、仔细确认是第二块硬盘无误后，在操作项中选择重建 Rebuild ，再点击 Go 。
6、阵列开始重建同步了，这时要注意千万别点击停止或暂停，最好要等它完成。
虽然重建很花时间（数小时至数十小时不等），但只要你不去停止它，它是会自动进行的，也就是说，只要不停电，你其实还是可以继续做其他的事情的。
主菜单中选择 物理磁盘管理 Physical Disk Management ，选择第三块（编号 00:01:02 ）磁盘。
之后操作项选择设定为全局热备盘 Assign Global Hot Spare ，然后点击 Go 。
因为热备盘不需要同步数据，所以很快就完成了。
至此，基本操作完成。
最后结语此次阵列故障我猜测应该是之前曾经有硬盘损坏，原有第三块热备盘自动顶替第二块成员盘重建数据。
但由于操作不当导致阵列恢复失败，之后又由于使用者也不懂所以导致第二块硬盘也无法切换回去，就这样被使用者胡乱写入了数据当成了普通硬盘使用。
阵列的出现是为了提高数据的安全性，然而现实中阵列一旦出现问题或故障，其操作很容易产生更大的问题甚至是灾难性后果。
基于阵列故障后的修复也会有一定的破坏性和风险性，所以强烈建议小伙伴们在平时务必做好数据的备份工作。
在此次修复过程中，最大的困难源于硬盘顺序的确认与重建所需大量时间的等待，所以需要我们十分地仔细和耐心。
最后这台服务器修好后又被迫再次回到了那个阴暗的角落，我是建议他们给服务器提供好一点的环境，也好减少或避免故障的发生。
最终你懂的，我等人微言轻，他们将我的话当屁用空气稀释后就再无任何动静。
当然我也没有因此较真，因为我很小的时候就懂得地球并非宇宙中心的道理。
好了，不要有什么怨言，努力工作、快乐生活，如果本文对你有所启发和帮助，还请小伙伴们积极点赞分享，我们下期再见吧！
网管小贾 / sysadm.cc
以上就是关于《手动修复服务器阵列盘混乱实例一则（服务器和磁盘阵列的区别）》的全部内容，本文网址：https://www.7ca.cn/tg/40299.shtml，如对您有帮助可以分享给好友，谢谢。
