我有一个configuration为RAID5的Perc H710，配有4个3TB Seagate 7200rpm硬盘。
两个月前，我得到这些虚假的错误，导致我相信我的控制器是坏的 。
我更换了控制器，一切正常，直到几天前我开始遇到类似的错误。 驱动器00和03被报告为失败，脱机或丢失。 戴尔派出了我又一个（第三）RAID控制器，现在的PERC BIOS说：
Drive 00 missing Drive 03 missing 于是我拿出驱动器，用磁盘工具单独检查它们。 事实上，驱动器00和驱动器03有坏道。 我用的Linux磁盘工具说，驱动器00有一些坏扇区，驱动器03有很多坏扇区。
真的吗？ 两个驱动器在同一天出去？
另一方面，是否有可能一个驱动器失败了一段时间，然后另一个失败，因为它不断旋转，试图重build第一个……或沿着这些线？
无法准确地说出X驱动器在Y时间内出现的可能性，但可以肯定地说，驱动器故障并不像通常假设的那样是完全独立的。 在相近的时间接近的同一arrays中的多个磁盘故障实际上是相当常见的事件。
不到一个月前，我们有一个接一个的生产服务器（相同的RAID设备）在同一个周末有4个驱动器故障。 几乎只要我们更换一个驱动器，另一个失败…我们最终最终取代所有7驱动器，是安全的。
正如你所提到的，一个原因是重build过程是磁盘密集型的，所以有一个不平凡的机会，即在坏的边缘摇摇欲坠的磁盘将被推到边缘而失败，这是由于压力增加的结果它在提供重build新磁盘的数据。
另一个需要考虑的因素是，RAIDarrays中的所有成员倾向于处于相同的物理环境，并且受到非常相似的物理应力（热，振动，功率波动等），这往往导致更高的发生率类似的故障时间比你在不同的环境下看到磁盘。
而且，如果你像大多数人一样，你可能刚刚从同一个地方买了4个相同的磁盘，并且最后有同一批次的4个磁盘，导致4个磁盘共享相同的制造特性（在制造期间的任何缺陷或exception批次可能在所有四个磁盘上共享）。 因此，在相同的环境中使用相同的磁盘是有道理的，因为它们可能会共享其他类似的特征，例如失败时。
最后，事实上，磁盘故障不是正态分布的（如钟形曲线）。 他们在生命初期（婴儿死亡率）往往有较高的失败率，而且经过很长一段时间后，由于受到的身体压力而磨损并死亡，其死亡率相对较低在中间失败（浴缸曲线）。
所以，是的，在同一个RAIDarrays中发生多个驱动器故障是有规律的，这也是您总是希望备份的原因之一。
这实际上相当普遍，而且经常build议从单个RAID组中购买不同批次的硬盘驱动器的主要原因。 相同的批次通常具有相同的缺陷或阈值。
而且，故障并不总是由于驱动器的简单老龄化而产生的，它们也可以通过最小的功率浪涌，几分钟的意外负载，相同的睡眠刺激等来触发。因此，机会当然小于单个驱动器故障，但不是平方百分比。 此外，不要忘记，单个磁盘故障意味着另一个磁盘上的负载增加，因为它们需要一起工作来重新计算缺失的数据。 这也可以推动另一个磁盘在边缘。 而在同一主题上，更换驱动器之后的重build是高度密集的操作，涉及所有磁盘的每个扇区，这意味着磁盘的另一个风险时间。
最后，它可能并不总是磁盘。 因为控制器认为4个磁盘中有3个被同时移除了几分钟，所以我曾经有一个RAID-5设备死在我身上。 这当然是控制器的失败，但是它仍然在日志中显示为3个磁盘在一分钟之后死亡。
是的，由于磁盘重build造成的第二次故障（以及重build读取的原始数据量，在密集的现代磁盘上读取错误的几率相对较高）是RAID-5带来一些固有风险的原因之一。
虽然听起来像RAID控制器没有确定地标记任何磁盘失败，只是“失踪”，这可能是您需要使用备份的情况下。
问题可能是您的某个磁盘在一段时间内有坏块，但没有被注意到，因为没有程序从这个扇区读取。
然后在另一个磁盘上有一个坏的部门。 其中之一被阅读和控制器删除这个驱动器或试图重build它。 然后它需要读取整个第二个磁盘，并在第二个驱动器上遇到第二个坏扇区。 那里你的RAID。
这就是为什么定期testing驱动器的坏道是至关重要的 – 这样才能长时间不被忽视。 有一个实用程序 – smartd软件包中的smartmontools – 可以在空闲时定期检查所有磁盘的坏块。 但并非所有控制器都允许将SMART命令发送到磁盘 – 这就是为什么我更喜欢软件RAID。
当磁盘再次写入时，磁盘会纠正（重映射）坏扇区。 所以，如果你知道哪个扇区是坏的（ smartctl -a可以告诉你），你可以检查哪个文件正在使用这个扇区，你可以从备份中重写这个文件，使磁盘再次正常。 但不要试图读取它，因为失败的读取可以强制从一个数组的磁盘。