btrfs是否适合作为备份文件系统？

现在，我在ext4之上有一个非常传统的备份文件系统结构。每次进行备份时，backup-DATE都会创建一个新文件夹，将文件rsync到该文件夹​​（使用rsync的--link-dest选项进行硬链接）。

由于我已经阅读了有关bitrot的文章，因此我希望透明地为所有文件提供一个校验和。显然ext4无法做到这一点，但是btrfs确实提供了对数据校验和的支持（甚至内置RAID1模式）。首先，我想btrfs用作支持数据校验和的“哑”文件系统，而不使用RAID，子卷快照，发送/接收等高级功能。

但是，他们的Wiki并没有真正激发人们对文件系统进行备份的信心：

“尽管许多人可靠地使用它，但是仍然发现问题。您应该保留并测试数据备份，并准备好使用它们。” - 入门

“ btrfs是否稳定？长答案：[..]无论您做什么，我们都建议保留良好的，经过测试的系统外（和异地）备份。” - 常见问题解答。

我的用例是进行脱机备份。因此，该磁盘将很少使用（以小时为单位），并且会频繁插入/拔出（eSATA或USB 3.0）。必须拥有可靠的文件系统。它一定不能比ext4 wrt更糟。停电，不正常关机等

实际上是否建议将btrfs用作文件系统以进行备份？btrfs是否还有其他属性可能使它不太适合（或更多）？

我只是提供一个简短的答案，因为我认为这是被过度考虑的。

如果您阅读有关btrfs（sub-）命令的主要内核Wiki ，则会发现有两个命令可用于：

1. 进行“备份”：btrfs-send
2. 并恢复：btrfs-restore

以防万一，这意味着它不是（设计为）备份，而是成为快照文件系统，其想法是在需要时回滚，而不是作为备份而是“灵活”的。

因此-不，请勿将其用作备份-将其用作版本化的文件系统，可以在此进行测试并返回。不要依赖它

我最近在最新的内核4.10.0上遇到了btrfs文件系统的问题。文件系统在virtualbox VM中被破坏了，因为TRIM似乎没有在某处正确实现，而AFAIK与子卷的索引号有关。切换到VMware后，文件系统仍然损坏，并且令人惊讶地btrfs check无法找到并修复错误。最后，我切换回ext4。

好消息：我没有丢失数据。至少对于阅读而言，btrfs似乎始终是一致的，但是它向我表明，它离生产就绪还很遥远。

无论如何，在服务器上，我仍将其用作备份卷，因为在那里我需要使用复写功能进行重复数据删除（正是您的用例）。对于传统的文件系统而言，数据量太大。

更新资料

我的服务器上仍然有文件系统（请参见上文），但是在我将其发布到这里后它就坏了。现在，我有一个700G的大只读备份量，如果我尝试使用复制所有内容，它将在ext4上扩展到〜7TB tar|tar。由于时间不足，我尚未检查较新的内核版本是否可以处理它。实际的问题是“事务异常中止”，它在装入可写文件后约2秒钟出现，并以只读方式重新装入该卷。最初的原因可能是的损坏版本btrfs-convert，该版本是我几年前创建此卷时使用的，但仍是当前功能的有限集，btrfs check至少应该能够找到该卷上的所有损坏，这些损坏可再现地导致交易中止或任何其他问题，而不仅仅是说我的文件系统是健康的。