我正在考虑构建一个较大的 ZFS 池（150TB+），并且想听听大家由于硬件故障而导致数据丢失的情况，特别是区分仅丢失部分数据的情况和整个文件系统丢失的情况（如果 ZFS 中存在这样的区别）。
例如：假设由于外部驱动器机箱断电或控制器卡故障等故障导致虚拟设备丢失。据我所知，池应该进入故障模式，但如果虚拟设备恢复，池应该恢复吗？还是不能？或者如果虚拟设备部分损坏，是否会丢失整个池、一些文件等？
如果一台 ZIL 设备发生故障，会发生什么情况？或者只是几台 ZIL 中的一台发生故障？
确实，我们非常欣赏任何以深厚技术知识为依据的轶事或假设情景！
谢谢！
更新：
由于我们是一家小公司（大约 9 个人），所以我们以低成本做这件事，但我们生成了相当数量的图像数据。
数据大部分都是小文件，据我计算，每 TB 约有 500k 个文件。
数据很重要，但并非至关重要。我们计划使用 ZFS 池来镜像 48TB“实时”数据阵列（使用 3 年左右），并使用其余存储空间来存储“存档”数据。
该池将使用 NFS 共享。
该机架据称位于建筑物备用发电机线路上，我们有两个 APC UPS，能够为满负荷的机架供电 5 分钟左右。
答案1
正确的设计方式并且您将最大限度地减少 ZFS 数据丢失的可能性。但是，您还没有解释您在池中存储了什么。在我的应用程序中，它主要为 VMWare VMDK 提供服务并通过 iSCSI 导出 zvol。150TB 不是一个小数目，所以我会依靠专业人士的扩展建议。
我使用 ZFS 从未丢失过数据。
我有经历了其他一切：
- 十几个 SSD 故障（其中一些L2ARC 职责）
- 多个池磁盘发生故障
- 不可预测的 SATA 驱动器错误，最终需要用近线 SAS 磁盘替换
- 后果错误配置的重复数据删除
- 从安全模式恢复损坏或故障的 zpools
- 10GbE NIC 端口/线缆损坏
- 操作系统频繁崩溃
- A雷击...
但经历了这一切，数据从未出现明显丢失。只是停机时间。对于位于此存储上的 VMWare VMDK，事件发生后通常需要进行 fsck 或重新启动，但并不比任何其他服务器崩溃更糟糕。
至于 ZIL 设备丢失，这取决于设计、存储的内容以及 I/O 和写入模式。我使用的 ZIL 设备相对较小（4GB-8GB），功能类似于写入缓存。有些人会镜像他们的 ZIL 设备。使用高端 STEC SSD 设备会使镜像成本过高。我使用单个DDR 驱动改用 PCIe 卡。规划电池/UPS 保护，并使用带有超级电容器备份的 SSD 或 PCIe 卡（类似于 RAID 控制器BBWC 和 FBWC 实现）。
我的大部分经验都来自 Solaris/OpenSolaris 和NexentaStor事情的一面。我知道人们在 FreeBSD 上使用 ZFS，但我不确定 zpool 版本和其他功能落后多少。对于纯存储部署，我建议采用 Nexentastor 路线（并与经验丰富的合作伙伴)，因为它是一个专门构建的操作系统，并且与 FreeBSD 相比，在 Solaris 衍生版本上运行的关键部署更多。
答案2
我在最新版本的 OpenSolaris 上意外覆盖了两个 ZIL，导致整个池不可挽回地丢失。（这真是我的大错！我不明白丢失 ZIL 就意味着丢失池。幸运的是，停机后从备份中恢复了。）
不过，从版本 151a 开始（不知道 ZPool 版本具体指什么），这个问题已经修复了。而且，我可以证明它确实有效。
除此之外，我在 20TB 的服务器上丢失了零数据 - 包括由于几起用户错误、多次电源故障、磁盘管理不善、配置错误、大量磁盘故障等原因。尽管 Solaris 上的管理和配置界面在不同版本之间频繁且令人抓狂地变化，并且提出了不断变化的技能目标，但它仍然是 ZFS 的最佳选择。
我不仅没有在 ZFS 上丢失数据（在我犯下严重错误之后），而且它还一直在保护我。我不再遇到数据损坏的问题——过去 20 年来，这种问题一直困扰着我，影响了许多服务器和工作站。静默（或只是“相当安静”）数据损坏已经多次让我丧命，当数据从备份轮换中滚出，但实际上已在磁盘上损坏时。或者其他备份备份了损坏版本的情况。这是一个比一次性大量丢失数据（几乎总是会备份）更大的问题。出于这个原因，我非常喜欢 ZFS，无法理解为什么校验和和自动修复十年来一直不是文件系统的标准功能。（当然，真正生死攸关的系统通常有其他方式来确保完整性，但企业数据完整性仍然很重要！）
明智的做法是，如果您不想陷入 ACL 地狱，请不要使用 ZFS 内置的 CIFS 服务器。使用 Samba。（虽然您说您使用 NFS。）
我不同意 SAS 与 SATA 的争论，至少不同意 ZFS 中 SAS 总是优于 SATA 的说法。我不知道该评论是否涉及盘片旋转速度、假定可靠性、接口速度或其他属性。 （或者可能只是“它们成本更高，而且通常不被消费者使用，因此它们更胜一筹”。最近发布的一项行业调查（我敢肯定仍在新闻中）显示，SATA 的平均寿命实际上比 SAS 更长，至少在调查的大量样本中是如此。（这确实让我很震惊。）我不记得那是 SATA 的“企业”版本，还是消费者版本，或者速度是多少 - 但根据我丰富的经验，企业和消费者模型的故障率在统计上是相同的。（然而，消费者驱动器在发生故障时需要很长时间才能超时，这在企业中绝对很重要 - 但这并没有困扰我，我认为这与硬件控制器更相关，因为在这种情况下，硬件控制器可能会使整个卷脱机。但这不是 SAS 与 SATA 的问题，ZFS 从未因此而让我失望。由于那次经历，我现在使用 1/3 企业和 2/3 消费者 SATA 驱动器的混合。）此外，如果配置正确，我发现这种 SATA 组合不会对性能产生重大影响（例如三向镜像条带），但我对 IOPS 的需求较低，因此取决于您的商店规模和典型用例，YMMV。我确实注意到，在我的用例中，对于延迟问题，每个磁盘内置缓存大小比盘片旋转速度更重要。
换句话说，它是一个包含多个参数的信封：成本、吞吐量、IOPS、数据类型、用户数量、管理带宽和常见用例。说 SAS 始终是正确的解决方案，就是忽略了这些因素的大量排列组合。
但无论如何，ZFS 绝对很棒。