我正在尝试让备份系统尽可能高效地运行 - 我需要备份的大多数系统都是 Linux 的某种风格，我们目前将它们转储到 Ubuntu 16.04.3 服务器并将它们存储在 / 磁盘上。 Ubuntu VM 在 Hyper-V 中运行，并具有用于根磁盘的 .vhdx。 Ubuntu 操作系统运行 rsync 连接到每个生产服务器。
无论如何，我不想将它们存储在根磁盘上，而是将备份文件存储在可以与每日快照一起操作的新磁盘和新文件系统上。我已在 Hyper-V（当前为精简配置）中创建了一个 900GB 的卷，并将其附加到虚拟机。目前该磁盘在 Ubuntu 中显示为 /dev/sdd，未格式化，容量为 900GB。
寻找有关如何支持以下要求的建议：
- 允许通过 rsync 从多个总计约 60GB 的生产服务器将备份复制到文件系统
- 允许基本的每天运行卷或文件系统快照，这样我们就可以保留大约 7-10 天的备份文件信息。前一天的生产文件增量通常约为 30-35GB
- 允许对任何一个备份快照进行简单引用（例如 Ubuntu 中的简单挂载点），以防我们需要检索 X 天前的随机文件
- 自动删除超过 10 天的快照。
我不需要什么：
- 物理或 RAID 卷管理 - 新磁盘（900GB .vhdx）已存储在处理物理磁盘异常的 Windows 存储空间卷上
- 脚本 - 运行以挂载/卸载或合并快照 - 对于文件系统的包来说不是普通的。
我过去曾以 NexentaStor 的形式使用过 ZFS，这非常流畅。除了 RAID 管理之外，拍摄的快照也会自动提供给我：“/primary_volume/.zfs/snapshot_name”，并且从 X 天前获取文件非常灵活。
我在这里考虑的是 BTRFS 实现，还是 LVM 实现？或者是否有其他打包的、随时可用的解决方案可以为我填补这一空白？
答案1
听起来你已经拥有了所有基本选项，但我认为你还应该考虑另一个选项 — 稍后会详细介绍。你拥有两个支持快照（btrfs 和 ZFS）和设备映射器/LVM 快照的足够常见的文件系统。
btrfs 快照的工作方式与您已经熟悉的 ZFS 快照类似；你运行
btrfs subvolume snapshot -r /mountpoint/data "/mountpoint/snapshots/$(date -Is)"或类似来制作一个，然后它在 下可见/mountpoint/snapshots/$(date -Is)。您还可以执行文件系统的根目录 (/mountpoint)，它可以正常工作。我对 btrfs 的经验是这种用法很稳定。它还支持修剪（如果其他一切都支持它 - 我个人从未使用过 HyperV，所以不能说）将使用但现在释放的空间将返回到虚拟机管理程序的精简池。LVM（设备映射器）快照有所不同——它们对块设备进行快照。传统 LVM 快照会导致性能损失（由于写入时复制），这可能会或可能不会成为备份使用的问题。还有精简池快照，它们较新，可以避免该问题。由于它们在块设备级别运行，因此当您创建快照时，您将创建一个新的块设备 - 然后您必须安装该块设备才能访问快照文件。
使用这两种方法，您可以根据需要保留快照（磁盘空间允许），以任何顺序删除它们等。我还建议考虑rsync --inplace减小快照大小。考虑到它们之间的选择——我认为它们都会很好地工作，你可能应该选择你/你的团队熟悉的任何东西。
另一种方法：您当前正在编写自己的备份系统。许多备份系统已经存在，包括旨在对像这样的硬盘进行节省空间的备份的系统。示例包括 BackupPC、Bacula/Bareos（更专注于磁带，但也包括磁盘）、BorgBackup、restic、ZBackup 等等。我建议您查看 Arch Wiki 的同步和备份程序列表。