ZFS数据丢失方案

我正打算建立一个大型的ZFS池（150TB +），我想听听人们关于由于硬件故障而造成的数据丢失情况的经验，特别是区分只有一些数据丢失的实例与整个文件系统的实例（即使在ZFS中也是如此）。

例如：假设由于外部驱动器机箱断电或控制器卡出现故障等原因导致vdev丢失。从我读到的内容来看，池应该进入故障模式，但是如果vdev返回了，池应该恢复吗？或不？或者如果vdev部分损坏，是否会丢失整个池，某些文件等？

如果ZIL设备发生故障会怎样？还是只是几个ZIL之一？

确实，任何由深厚的技术知识支持的轶事或假设方案都值得赞赏！

谢谢！

更新：

由于我们是一家小型企业（9人左右），因此我们以便宜的价格进行此操作，但是我们会生成大量的成像数据。

数据大部分是较小的文件，据我估计，每TB约有500k文件。

数据很重要，但不是超级关键。我们计划使用ZFS池来镜像48TB“实时”数据阵列（使用3年左右），并将其余存储空间用于“归档”数据。

该池将使用NFS共享。

机架应该位于建筑物的备用发电机线上，并且我们有两个APC UPS能够在满负载下为机架供电5分钟左右。

设计正确的方法，您可以最大程度地减少ZFS数据丢失的机会。不过，您尚未解释池中存储的内容。在我的应用程序中，它主要服务于VMWare VMDK并通过iSCSI导出zvol。150TB并非微不足道的数量，因此我将依靠专业人士来提供扩展建议。

我从未使用ZFS丢失数据。

我已经经历了一切：

• 十几个SSD故障（有些是L2ARC职责）
• 多个故障池磁盘
• 不可预测的SATA驱动器错误，需要最终用近线SAS磁盘替换
• 错误配置的重复数据删除工作的后果
• 从安全模式恢复损坏或有故障的zpool
• 错误的10GbE NIC端口/电缆
• 频繁的OS崩溃
• 一个雷击 ...

但是通过所有这些操作，永远不会出现明显的数据丢失。只是停机时间。对于位于该存储顶部的VMWare VMDK，在事件发生后通常需要进行fsck或重新启动，但不会比任何其他服务器崩溃都严重。

至于ZIL设备的损失，取决于设计，要存储的内容以及I / O和写入模式。我使用的ZIL设备相对较小（4GB-8GB），其功能类似于写缓存。有些人镜像他们的ZIL设备。使用高端STEC SSD设备会使镜像成本过高。我改为使用单个DDRDrive PCIe卡。规划电池/ UPS保护，并使用具有超级电容器备份的SSD或PCIe卡（类似于RAID控制器BBWC和FBWC的实现）。

我的大部分经验是在Solaris / OpenSolaris和NexentaStor方面。我知道人们在FreeBSD上使用ZFS，但是我不确定zpool版本和其他功能有多远。对于纯存储部署，我建议您采用Nexentastor路由（并与经验丰富的合作伙伴交谈），因为它是专用操作系统，并且在Solaris衍生产品上运行的关键部署要比FreeBSD多。

我不小心覆盖了最新版本的OpenSolaris上的两个ZIL，这导致整个池不可挽回地丢失。（对我而言，这确实是一个严重的错误！我不明白失去ZIL意味着失去池。所幸从停机中恢复了。）

从151a版本开始（不知道ZPool是什么意思），此问题已得到解决。而且，我可以证明它可行。

除此之外，我还丢失了20TB服务器上的ZERO数据-包括由于其他几种用户错误情况，多次电源故障，磁盘管理不当，配置错误，大量故障磁盘等造成的。 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绝对是不可思议的。