单个虚拟磁盘上的ZFS

公司如何在非常紧张的预算下pipe理大型文件服务器（例如17TB）及其相关备份？
在单个虚拟磁盘上使用ZFS（或BTRFS）是否可以进行写入时复制function以消除对fsck的需求？（即不为其RAID，快照等function）

具体情况：

我们需要退役一个古老的有问题的存储系统，它为NFS提供虚拟存储服务，并且仍然是我们的主要文件服务器。我现在有了一个新的基于40TB iSCSI FreeNAS的存储系统，并且已经将旧存储中的所有虚拟机迁移到了新的虚拟机，但是17TB的SMB / CIFS和AFP共享文件依然存在。

通过rsync完成备份需要很长的时间来扫描17 TB，所以我们分成了两个卷：

对于未修改为一年的文件，在只读“归档”卷上为13 TB。要进行备份，我们只需使用rsync进行现场和非现场复制 – 无需每日备份版本。
4 TB活动可写存储。每天使用rsync进行备份，并使用硬链接在当天创build文件服务器状态的“快照”/版本，以便我们可以恢复覆盖的文件。

当需要修改时，IT人员将文件从存档移到现场，但这些请求现在每天多次，不再可接受。

原计划：

创build一个虚拟的Linux文件服务器。
在我们新的40TB存储系统上创build2个虚拟磁盘。（13 TB存档+ 4 TB可写直播）
使用ext4文件系统格式化磁盘
使用带有挂载选项的UnionFS向用户呈现上述文件系统的单一统一视图，所有写入操作都将转至4TB可写入系统。

原计划的问题：

我们超出了rsync的基于文件的性质作为备份工具，例如重命名1TB顶级文件夹导致整个1TB文件夹的完整新副本。这只会为基于块的备份添加几个KB。
实施UnionFS只是给整个系统增加了一层复杂性，我真的很想避免。
由于rsync必须重新扫描整个文件服务器来比较已更改的文件，即使只更改了一些文件，也需要很长时间才能完成备份。
它要求我们进行连续存档，以保持可写容量足够小，备份一夜之间完成。

备选计划1：备份的一个大容量和ZFS快照

上面创build计划的Linux文件服务器，但有一个大的卷，而不是两个，消除了对于联盟的需要
要备份这个非常大的服务器，这将花费rsync太长时间，而是使用ZFS快照，并使用“zfs send”来复制异地。

替代计划1的问题：

在17TB ext4文件系统上的fsck需要几天的时间！想象一下，周一上午的事件需要重新启动，并在启动时强制fsck，或者更糟糕的是，文件系统损坏！

备选scheme2：Linux服务器上的ZFS / BTRFS文件系统

按照备选计划1，但使用写时复制文件系统（如ZFS或BTRFS）而不是ext4，因为这些文件系统不需要fsck。

替代计划2的问题/顾虑：

ZFS和BTRFS都需要直接访问原始磁盘来实现自己的RAID，因此通常不会在虚拟磁盘上使用。这将如何在单个虚拟磁盘上工作？

备选scheme3：FreeNAS直接作为文件服务器

而不是有一个单独的虚拟文件服务器，直接从FreeNAS共享文件

替代计划3的问题：

我们需要安装各种软件包和自定义的perl / bash / python脚本来将这个文件服务器与我们的作业跟踪系统集成在一起。在直接的Linux上这样可以，但是我不认为这是一个预先打包的基于FreeBSD的ZFS存储系统（FreeNAS）的好主意。更新可能会覆盖我们的更改等

问题：

是替代计划2 – 单个虚拟磁盘上的ZFS – 一个好主意？如果没有，为什么？
任何人都可以提出更好的select？

公司如何在非常紧张的预算下pipe理大型文件服务器（例如17TB）及其相关备份？

这取决于性能和预算限制。例如，Backblaze（一家云备份公司）对每个TB的预算都非常紧张，但是他们不需要数据的最佳性能或响应时间。其他一些公司可能需要廉价的性能，但find一种方法来减less所需的数据（通过重复数据删除，修剪旧的备份数据或简单地减less业务可能不需要的实际数据）。

在单个虚拟磁盘上使用ZFS（或BTRFS）是否可以进行写入时复制function以避免使用fsck？（即不为其RAID，快照等function）

我不会在任何非发展的情况下使用BTRFS，而您需要相信您的数据安全性作为第一原则。我会使用ZFS，因为我还没有find一个更便宜，更安全的替代scheme（其他具有与IBM，NetApp等类似function的FS更为昂贵，其他免费文件系统要么不够成熟（HAMMER2，BTRFS），要么缺less基本functionext2 / 3/4，reiserfs等）。

你的具体答案：我宁愿计划3，但计划2也会工作。

与在networking上浮动的很多FUD相反，ZFS不关心底层存储，无论是物理的，虚拟的还是混合的。当然，它只能像底层存储一样好/快/安全，只能推断出什么。这意味着，您的性能将不如原生，您的故障排除涉及两个图层，并且两个图层都可能有问题。如果你知道这一点，并提供这些缺点，我认为这是一个可行的select。

你仍然有舒适的function，如发送/ recv，快照，CoW，校验和和块级重复数据删除。你牺牲的主要是性能和可能的安全性（例如，如果你的SAN只是一个单一的磁盘）。创build池时，还应该将ZFS扇区大小（ ashift ）调整到底层存储。之后，您可以为各个文件系统设置不同的大小，但是如果不破坏池设置，则不能反转。

但是我首先要彻底评估这些脚本和集成的重写是否如你所想象的那样耗时。另外，即使像FreeNAS这样的设备（或者napp-it），通常也有用户脚本或者用户可定义的插件或者模块，这些插件或者模块能够在设备上保持更新并且能够很好地工作（新的FreeNAS 10也被Corral取代了它的插件架构与Docker，如果这是你熟悉的东西可能是一个替代）。