我目前的诊断是存在硬件故障，或者与硬件RAID控制器的内存有关，或者与硬盘驱动器在完全运行时需要多余的汁液有关。
试图更换PSU，没有骰子。 试过现场启动另一个操作系统，没有骰子。 无论操作系统如何，高磁盘IO都能确保硬关机。 我已经确定一个新的服务器是绝对需要的。
但是，现在我面临着对驱动器内容进行备份的挑战，而不会导致高IO。 我已经configuration了IOPS限制的cgroups，我曾经玩过，看看它有多高，而不会导致关机。 结果似乎从每个磁盘有所不同，但平均约100个似乎在崩溃之前工作了一段时间。 但考虑到大约有120GB的数据，这并不是真的可行。 顺便说一下，这些是SAS 15K驱动器。
限制IO看起来是有效的，但是这是一个累赘的过程，因为当服务器closures时我必须重新设置它。 我使用Runtime Live CD（Knoppix fork）将数据从驱动器复制到外部驱动器。
服务器大约7岁，我没有碰到驱动器的额外连接器。
面对这样的情况，从驱动器获取数据的可靠方法是什么？
仅供参考，这是帮助我设置限制IO的cgroup的链接： http : //fritshoogland.wordpress.com/2012/12/15/throttling-io-with-linux/
虽然是几年前，我也曾经见过类似的东西。
在我的情况下，这是问题的记忆和复制数据时，有一些forms的caching进行，我怀疑是慢慢地使用内存，直到它到了问题的记忆和…繁荣！ 电脑坠毁。 一个内存testing应该很容易地识别这个，或者删除一些内存来查看它是否解决或者恶化问题？
如果不是这样，那么我怀疑它的数据吞吐量是相关的，吞吐量只是拖延了问题，而隐藏了实际的原因。
这可能是值得检查的CPU临时工，以防万一数据副本导致足够的CPU工作，以提高到崩溃点？ 即风扇故障或散热片滑落？ 减慢数据复制速度只是减轻了足够的负担来延缓温度上升。
最后，你不说你的磁盘是如何configuration的？ 即RAID或JBOD？ 你能够将驱动器单独移动到另一台服务器，还是作为一个组？ 显然不要只是移动它们，如果他们是RAID驱动器，除非作为最后的，最后的手段！ 除非你知道你在做什么，当然！
HTH