当我在 Linux 中时，我可以从lsblk（从输出中删除不相关的驱动器）获取以下信息：
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 298G 0 disk
sdb 8:16 0 2.7T 0 disk
当我手动将驱动器从服务器中拉出时，我可以看出我实际使用了以下驱动器：
0 Seagate 320GB
1 Seagate 320GB
2 Hitachi 1TB
3 Hitachi 1TB
4 Hitachi 1TB
5 Hitachi 1TB
6 [empty]
7 [empty]
因为服务器中的物理存储空间多于 Linux 中的可用空间，这意味着我显然在使用某种形式的 RAID 系统。通过一些数学运算，我通常可以弄清楚正在使用哪种类型的 RAID 系统。
有没有办法让我检测我是否在 Linux 内部使用硬件 RAID ，并找出有关它的所有信息（例如 RAID 类型、可用驱动器），而无需关闭服务器、物理拔出驱动器，并阅读他们的标签？
这些信息可以从 Linux 内部收集，还是硬件 RAID 的目的是使底层系统对操作系统“不可见”？
我打算购买一台采用 RAID 10 固态硬盘的服务器 (Dell PowerEdge R740)，我的首要任务是写入性能和数据完整性。它将运行 Linux。SSD 具有带断电保护的写入缓存。
这些似乎是我的 RAID 选项：
我的问题：
相关问题：
当我将快照和 RAID 与 btrfs 一起使用时，我能想到的备份的两个主要原因似乎得到了照顾。（这里的 RAID，我指的是 RAID1 或 10）
所以作为现场备份解决方案，这似乎工作得很好，它甚至不需要单独的数据存储设备！
但是，我听说 RAID 和快照都不是正确的备份，所以我想知道我是否遗漏了什么。
除了 btrfs 还不是一项成熟的技术，你能想到我遗漏了什么吗？或者我的想法是否正确，这是一个有效的现场备份解决方案？
我正在设置两个新的 4TB 硬盘驱动器的 RAID1 阵列。
我以前在某个地方听说过，将同时购买的新相同硬盘驱动器制作成 RAID1 阵列会增加它们在相似时间点发生故障的可能性。
因此，我正在考虑单独使用其中一个硬盘驱动器一段时间（可能是几周），以尝试减少两者在短时间内出现故障的可能性。（未使用的驱动器将保持断开连接在抽屉中）
这似乎是一种合理的方法，还是我更有可能只是在浪费时间？
我有一个使用了一个多月的 NAS 设备。它被配置为通过电子邮件发送从硬盘驱动器的 SMART 数据生成的警报。一天后，其中一个硬盘驱动器报告一个扇区损坏并被重新分配。在第一周，这个数字攀升到有问题的硬盘驱动器的六个扇区。一个月后，这个数字达到了 9 个重新分配的扇区。这个速度似乎肯定在减速。
NAS 在 RAID-5 配置中配置了六个 1.5 TB 驱动器。使用如此大容量的驱动器，我预计某个扇区会不时出现故障，因此我并不担心最初的几个扇区何时被重新定位。尽管其他磁盘都没有报告任何问题，但让我感到困扰。
我应该开始担心驱动器的健康状况吗？这可能会因驱动器的容量而异吗？
我被要求使用 Symantec Backup Exec 设置一个新的备份服务器，该服务器存储到硬盘而不是磁带，因为备份大小超过了磁带容量。
我想知道它是否真的有意义，或者备份服务器运行任何类型的 RAID 是否有任何优势，因为它是“备份”？
对我来说，好处并不足以证明增加的成本是合理的。
我有兴趣看看其他人的想法。
谢谢！
为什么嵌套 RAID 级别 1+5 或 1+6 几乎闻所未闻？该嵌套的RAID级别维基百科的文章，目前缺少的部分。我不明白为什么它们并不比 RAID 1+0 更常见，尤其是与 RAID 1+0 三重镜像相比时。
很明显，重建时间变得越来越成问题，因为驱动器容量的增长速度快于其性能或可靠性。有人告诉我 RAID 1 重建速度更快，RAID 1 对的 RAID 0 阵列可以避免这个问题，但 RAID 5 或 6 RAID 1 对阵列肯定也会如此。我至少希望它们成为 RAID 1+0 的常见替代方案。
对于 16 个 1TB 驱动器，以下是我对求助于备份的天真概率的计算，即简化假设，即驱动器以偶数概率独立：
RAID | storage | cumulative probabilities of resorting to backup /m
1+0 | 8TB | 0, 67, 200, 385, 590, 776, 910, 980, 1000, 1000, 1000
1+5 | 7TB | 0, 0, 0, 15, 77, 217, 441, 702, 910, 1000, 1000 …我最近一直在研究 RAID5 与 RAID6，我一直看到 RAID5 不再足够安全，因为 URE 等级和驱动器的大小不断增加。基本上，我发现的大部分内容都说，在 RAID5 中，如果磁盘出现故障，如果阵列的其余部分为 12TB，那么您几乎有 100% 的机会遇到 URE 并丢失数据。
12TB 的数字来自这样一个事实，即磁盘的额定读取率为 10^14 位以达到一个 URE。
好吧，有些事情我没有得到。读取是由磁头在扇区上完成的，导致读取失败的原因是磁头死亡或扇区死亡。也可能是因为其他原因读数不起作用（我不知道，就像振动使头部跳动......）。所以，让我解决所有 3 种情况：
如您所见，从我确定的 3 个故障点来看，没有任何意义。那么到底什么是URE，我的意思是具体的？
有人可以向我解释一下吗？
编辑 1
在第一波答案之后，似乎原因是该部门失败了。好消息是固件、RAID 控制器和操作系统 + 文件系统有适当的程序来及早检测并重新分配扇区。
好吧，我现在知道什么是 URE（实际上，这个名字是不言自明的 :)）。
我仍然对根本原因感到困惑，主要是他们给出的稳定评级。
有些人将失败的扇区归因于外部来源（宇宙波），然后我感到惊讶的是 URE 率是基于读取计数而不是年龄，宇宙波确实应该对旧磁盘产生更多影响，因为它已被暴露更多，我认为这更像是一种幻想，尽管我可能是错的。
现在是与磁盘磨损有关的另一个原因，有人指出较高的密度会产生较弱的磁畴，这是完全有道理的，我将遵循解释。但是正如这里很好地解释的那样，新的不同大小的磁盘主要是通过在 HDD 机箱中放置或多或少相同的盘片（然后相同的密度）来获得的。扇区是相同的，并且都应该具有完全相同的可靠性，因此较大的磁盘应该比较小的磁盘具有更高的评级，读取的扇区较少，情况并非如此，为什么？这虽然可以解释为什么采用新技术的新磁盘没有比旧磁盘获得更好的评级，仅仅是因为更好的技术收益被更高密度造成的损失所抵消。
我打算在我的系统（HP ML370 G5、Smart Array P400、8 SAS 磁盘）上使用 ZFS。我希望 ZFS 单独管理所有磁盘，以便它可以利用更好的调度（即我想在 ZFS 中使用软件 RAID 功能）。
问题是，我找不到禁用 RAID 控制器上的 RAID 功能的方法。现在，控制器将所有磁盘聚合到一个大的 RAID-5 卷中。所以 ZFS 看不到单个磁盘。
有没有办法完成这个设置？
目前可用的任何硬件 RAID 控制器都支持TRIM吗？
如果没有，是否有任何制造商有支持 TRIM 的目标日期？
我应该关心安装在性能敏感工作站中的 SSD 的 TRIM 吗？
在您提出建议之前，是的，软件 RAID 会回避这个问题，但我的要求不允许软件 RAID。
编辑：目前的答案似乎是“没有 RAID 控制器支持 TRIM”。
更新： 截至 2012 年 8 月，英特尔 7 系列主板确实支持 RAID 0 TRIM。现在可能会有更多供应商在 2015 年支持此功能