我正在考虑在我的数据驱动器上使用 btrfs，以便我可以使用鲷鱼，或者像 snapper 这样的东西，可以拍摄基于时间的快照。我相信这会让我浏览旧版本的数据。这将是我当前的异地备份的补充，因为驱动器故障会清除数据和快照。
据我了解，btrfs 快照不会占用太多空间（元数据和已更改的块，可能还有一些开销），因此空间似乎不是一个限制。
如果我有一百万个快照（例如，两年内每分钟一个快照），假设我有足够的磁盘空间来存储数据、更改的数据和元数据，这会造成严重破坏吗？
如果快照数量有实际限制，它是否取决于文件数量和/或文件大小？
答案1
作为使用btrfs文件系统Arch Linux近2几年的人，我可以有把握地说，可以轻松达到的快照数量似乎没有实际限制。但也有一些注意事项。btrfs文件系统可能会导致碎片。因此，建议使用内置的在线碎片整理功能btrfs。此外，还可以充分利用 的btrfs压缩功能。这些措施应该可以解决大多数性能问题，这些问题可能会在相当不错的计算机上因创建大量快照而明显出现。
您可能知道，btrfs将子卷视为文件系统，因此快照的数量确实受到限制：即受文件大小的限制。根据 btrfswiki，可以达到的最大文件大小是2^64 byte == 16 EiB[1]。
除了这些限制之外，当您用完空间而没有立即意识到时，可能总会出现问题，因为检查btrfs文件系统上的可用空间有时可能很棘手，即无法区分测量btrfs文件系统上可用空间的不同方法。轻松跟踪实际剩余的空间量。防止这种情况的一种可能方法是使用配额。这确保了用户（或者只有一个用户时的用户）只能使用一定量的空间。这个概念讨论得非常巧妙这里并且这里。
最后但并非最不重要的警告：我不是btrfs文件系统方面的专家，只是在不久前遇到同样的问题时才阅读这些内容。此外，总是存在一个“快速移动的目标”的问题（我认为btrfs很好的措辞是从维基页面上窃取的。）所以事情可能会改变。Arch Linux
答案2
虽然从技术上讲快照的数量没有限制，但我询问了BTRFS 邮件列表:
（实际）答案在某种程度上取决于您如何使用 btrfs。
Btrfs 确实存在由于快照过多而导致的扩展问题（或者实际上使用了 reflinks 快照，使用 reflinks 进行重复数据删除可能会触发相同的扩展问题），因此，强烈建议每个快照子卷使用个位数到低两位数的快照。
但扩展问题主要影响 btrfs 维护命令本身，平衡、检查、子卷删除。虽然数百万个快照将使平衡变得无法实现（它会起作用，但可能需要几个月的时间），但正常的文件系统操作（例如读取和保存文件）往往不会受到影响，除非碎片成为问题（牛文件系统（例如 btrfs）以碎片着称，除非采取碎片整理等步骤来减少碎片）。
看来使用快照作为类似于时间机器/快照器的归档备份并不是一个好主意。
答案3
您总共可以拥有 2 64 个快照和子卷。
这btrfs设计维基页面说（强调我的）：
子卷基本上是一个保存文件和目录的命名 btree。它们在树根树内有 inode，并且可以有非根所有者和组。可以为子卷指定块配额，一旦达到该配额，就不允许进行新的写入。子卷内的所有块和文件范围都经过引用计数以允许快照。FS 上最多可以创建 2 64个子卷。
快照与子卷相同，但它们的根块最初与另一个子卷共享。拍摄快照时，根块上的引用计数会增加，写时复制事务系统可确保快照或源子卷中所做的更改对于该根而言是私有的。快照是可写的，并且可以多次创建快照。如果需要只读快照，则在创建时将其块配额设置为 1。