现在我有一个基于 ext4 的非常传统的备份文件系统结构。每次进行备份时，backup-DATE都会创建一个新文件夹，文件将被 rsync（使用 rsync 选项创建硬链接--link-dest）。
由于我已经阅读过有关 bitrot 的内容，因此我希望透明地对所有文件进行校验和。显然 ext4 无法做到这一点，但 btrfs 确实提供了对数据校验和的支持（甚至内置 RAID1 模式）。首先，我想使用 btrfs 作为一个“哑”文件系统，它支持数据校验和，而不使用其高级功能，例如 RAID、子卷快照、发送/接收等。
然而，他们的 wiki 并没有真正激发人们对用于备份目的的文件系统的信心：
“虽然许多人可靠地使用它，但仍然发现问题。您应该保留并测试数据备份，并准备使用它们。” -入门
“btrfs 稳定吗？长答案：[..]无论您做什么，我们都建议保留良好的、经过测试的、系统外（和场外）备份。” -常问问题。
我的用例是进行离线备份。因此，磁盘的使用率非常低（以小时为单位），并且会频繁插入/拔出（eSATA 或 USB 3.0）。拥有可靠的文件系统是必须的。在电源故障、非正常关机等方面，它一定不会比 ext4 差。
实际上是否建议使用 btrfs 作为文件系统进行备份？ btrfs 是否还有其他属性可能使其不太（或更）合适？
答案1
我只会提供一个简短的答案，因为我认为这是考虑过度的。
如果您阅读了有关的主要内核 wikibtrfs（子）命令，你会发现有两个命令：
以防万一，这意味着它不是（设计为）备份，而是快照文件系统，其想法是在需要时回滚，不是作为备份，而是作为“灵活”。
因此，不，不要将其用作备份，将其用作版本化文件系统，您可以在其中进行测试并返回。不要依赖它。
答案2
我最近在最新内核 4.10.0 上使用 btrfs 文件系统时遇到了问题。文件系统在 virtualbox VM 中被破坏，因为 TRIM 似乎没有在某处正确实现，并且 AFAIK 它与子卷的索引号有关。切换到 VMware 后，文件系统仍然损坏，并且令人惊讶的是btrfs check无法找到并修复错误。最后我又切换回ext4。
好处是：我没有丢失数据。 btrfs 似乎至少在阅读方面总是一致的，但它向我表明它距离生产就绪还很远。
不管怎样，在服务器上我仍然使用它作为备份卷，因为我需要牛复制功能来进行重复数据删除（正是您的用例）。对于传统文件系统来说，数据太大了。
更新
我的服务器上仍然有文件系统（见上文），但在我将其发布到此处后它就损坏了。现在，我有一个 700G 的大只读备份卷，如果我尝试使用tar|tar.由于时间不够，我还没有检查较新的内核版本是否可以处理它。实际问题是“事务中止”，它在安装可写卷后约 2 秒发生，并将卷重新安装为只读。最初的原因可能是 的一个损坏版本btrfs-convert，我几年前创建此卷时使用的，并且仍然是当前版本的有限功能集btrfs check，至少应该能够寻找卷上的所有损坏都会重复导致事务中止或任何其他问题，而不仅仅是说我的文件系统是健康的。
更新2
我终于能够通过使用 python 脚本（基于 oss 重复数据删除工具）将所有内容复制到新卷来解决这个问题。它根据校验和与目标文件系统上的文件池一起工作，并从那里创建牛链接。这个半高效的过程花了 2 天，但随后我有了一个新的干净的基于 btrfs 的文件系统，所有数据都恢复了。如果需要，可以发布该代码，但不要指望有一个完美、易于使用且防错的工具。