- 公司如何在非常紧张的预算下管理大型文件服务器（例如 17 TB）及其相关备份？
- 是否可以在单个虚拟磁盘上使用 ZFS（或 BTRFS），利用其写时复制特性来消除对 fsck 的需求？（即不利用其 RAID、快照等功能）
具体情况：
我们需要淘汰一个存在问题的古老存储系统，该系统为虚拟机提供 NFS 存储，并且仍然是我们的主要文件服务器。我现在有一个新的 40TB iSCSI FreeNAS 存储系统，并且已经将所有虚拟机从旧存储 vMotion 迁移到新存储，但 17 TB 的 SMB/CIFS 和 AFP 共享文件仍然存在。
备份是通过 rsync 完成的，扫描 17 TB 需要很长时间，因此我们将其分成两个卷：
- 13 TB 的只读“存档”卷，用于存储一年内未修改的文件。要进行备份，我们只需使用 rsync 进行现场和异地复制 - 无需每日备份版本。
- 4 TB 实时可写存储。它每天使用 rsync 进行备份，并使用硬链接创建当天文件服务器状态的“快照”/版本，以便我们可以恢复被覆盖的文件。
当需要修改时，IT 人员会将文件从存档移至实时状态，但这些请求现在每天都会多次，并且不再可接受。
原计划：
- 创建虚拟 Linux 文件服务器。
- 在我们新的 40TB 存储系统上创建 2 个虚拟磁盘。（13 TB 存档 + 4 TB 可写实时）
- 使用 ext4 文件系统格式化上述磁盘
- 使用带有 cow mount 选项的 UnionFS 向用户呈现上述文件系统的单一统一视图，所有写入都转到 4TB 可写系统。
原计划存在的问题：
- 我们已经不再满足 rsync 作为备份工具的基于文件的特性，例如，重命名 1TB 的顶级文件夹会导致整个 1TB 文件夹的完整新副本。这只会为基于块的备份增加几 KB。
- 实施 UnionFS 只会给整个系统增加另一层复杂性，我真的想避免这种情况。
- 由于 rsync 必须重新扫描整个文件服务器来比较更改的文件，因此即使只更改了几个文件，也需要很长时间才能完成备份。
- 它要求我们进行连续归档以保持可写卷足够小，以便备份可以在一夜之间完成。
备选方案 1：一个大卷和 ZFS 快照用于备份
- 创建上面计划的 Linux 文件服务器，但使用一个大卷，而不是两个，从而无需使用 UnionFS
- 要备份这个非常大的服务器，使用 rsync 会花费太长时间，请改用 ZFS 快照并使用“zfs send”进行异地复制。
替代计划 1 的问题：
- 对 17 TB ext4 文件系统进行 fsck 需要几天时间！想象一下周一早上发生需要重新启动并在启动时强制进行 fsck 的事件，或者更糟的是，文件系统损坏！
备选方案 2：Linux 服务器上的 ZFS/BTRFS 文件系统
- 按照替代计划 1，但使用写时复制文件系统（例如 ZFS 或 BTRFS）而不是 ext4，因为这些不需要 fsck。
对替代计划 2 的问题/疑虑：
- ZFS 和 BTRFS 都希望直接访问原始磁盘以实现自己的 RAID，因此通常不在虚拟磁盘上使用。这在单个虚拟磁盘上的效果如何？
方案三：FreeNAS 直接作为文件服务器
- 无需使用单独的虚拟文件服务器，直接从 FreeNAS 共享文件
替代计划 3 的问题：
- 我们需要安装各种软件包和自定义 perl/bash/python 脚本，以便将此文件服务器与我们的作业跟踪系统集成。这在纯 Linux 上没问题，但我认为在预打包的基于 FreeBSD 的 ZFS 存储系统 (FreeNAS) 上这不是一个好主意。更新可能会覆盖我们的更改等。
问题：
- 备选方案 2 - 在单个虚拟磁盘上使用 ZFS - 是个好主意吗？如果不是，为什么？
- 有人可以建议更好的选择吗？
答案1
公司如何在非常紧张的预算下管理大型文件服务器（例如 17 TB）及其相关备份？
这取决于性能和预算限制。例如，Backblaze（一家云备份公司）对每 TB 的预算非常紧张，但他们不需要顶级性能或数据响应时间。其他一些公司可能需要廉价的性能，但找到了减少所需数据的方法（使用重复数据删除、修剪旧备份数据或简单地减少业务可能不需要的实际数据）。
是否可以在单个虚拟磁盘上使用 ZFS（或 BTRFS），利用其写时复制特性来消除对 fsck 的需求？（即不利用其 RAID、快照等功能）
我不会在任何非开发领域使用 BTRFS，因为您需要将数据安全作为首要原则。我会使用 ZFS，因为我还没有找到更便宜、更安全的替代方案（IBM、NetApp 等公司提供的其他具有类似功能的 FS 更贵，其他免费文件系统要么不够成熟（HAMMER2、BTRFS），要么缺少基本功能（ext2/3/4、reiserfs 等）。
您的具体回答：我更喜欢计划 3，但计划 2 也可以。
与网络上流传的大量 FUD 相反，ZFS 并不关心底层存储，无论是物理存储、虚拟存储还是混合存储。当然，它只能与底层存储一样好/快/安全，并且只能推断给定的内容。这意味着，您的性能不会像本机那样好，您的故障排除涉及两个层，并且两个层都可能存在问题。如果您知道这一点并考虑到这些缺点，我认为它是一个可行的替代方案。
您仍然可以使用诸如发送/接收、快照、CoW、校验和以及块级重复数据删除等舒适功能。您牺牲的主要是性能和可能的安全性（例如，如果您的 SAN 只有一个磁盘）。ashift在创建池时，您还应该根据底层存储调整 ZFS 扇区大小（）。之后，您可以为各个文件系统设置不同的大小，但池设置不能撤消，否则会破坏它。
但我首先要彻底评估这些脚本和集成的重写是否如您想象的那样耗时。此外，即使是像 FreeNAS（或 napp-it，作为替代方案）这样的设备通常也有用户脚本或用户可定义的插件或模块，这些插件或模块在更新后仍能继续使用，并与设备很好地配合使用（新的 FreeNAS 10 又名 Corral 用 Docker 取代了其插件架构，如果您熟悉 Docker，它可能是一种替代方案）。