我最近构建了一个带有根分区的系统。与 相比，btrfs采用 的最令人信服的理由是，它具有接近零延迟的实时写时复制快照。与 相比，当完整系统备份需要关闭系统、从实时发行版安装并在可移动媒体上构建映像时，快照的承诺是可以在系统处于实时状态时在备份媒体上捕获快照。 btrfsext4ext4partclone
然而，令我惊讶的是，没有任何工具可以将整个快照捕获到外部媒体上的单个文件中，这样，如果从该文件恢复系统，所有应用程序都将具有与崩溃前相同的文件系统视图（除了其他快照或子卷丢失）。
文档建议使用 rsync 等工具镜像目录树，或使用btrfs-send/btrfs-receive捕获另一个系统上的增量更改。在第一种情况下，我总是发现几乎不可能通过镜像文件树而不是对文件系统进行映像来精确地重新创建文件树中的所有元数据，并且对恢复过程是否会非常顺利并不抱太大希望。我总是发现某些元数据（无论是权限、时间戳、隐藏文件等）未正确捕获。当传输发生在不同类型的文件系统之间时，问题会变得更加严重。另一个建议假设有另一个btrfs文件系统可用，但情况并非总是如此。
是否有任何建议可用于保存或恢复卷级图像，类似于部分克隆文件，但仅代表选定的子卷？
答案1
btrfs send并且btrfs receive正是您所需要的工具。
我一直发现，通过镜像文件树（而不是对文件系统进行映像）几乎不可能准确地重新创建文件树中的所有元数据，并且恢复过程不会非常顺利。我总是发现某些元数据（无论是权限、时间戳、隐藏文件等）没有被正确捕获。
你试过这些工具吗？我没有遇到过这样的问题btrfs。它们不适用于文件，btrfs send而是适用于整个子卷，可以访问所有 Btrfs 元数据btrfs receive天生地。
当传输发生在不同类型的文件系统之间时，问题会变得更加严重。另一个建议假设有另一个 Btrfs 文件系统可用，但情况并非总是如此。
只有在需要时才需要另一个 Btrfs 文件系统复制子卷就在那里。这通常是可取的，这样您就可以挂载它并访问其文件。如果您想逐步备份子卷，这是不可避免的。您需要两个位置的精确的先前快照才能逐步发送下一个快照。
但是，使用完整转储，您将获得一个独立流，它实际上是一个图像（但不是可浏览的备份，除非您btrfs restore这样做）。像使用任何其他流一样使用它：
btrfs send /source/subvolume >/another/filesystem/subvolume-image # just a file
# (or you can gzip it and/or send with nc on the fly, whatever)
# then later
</another/filesystem/subvolume-image btrfs receive /some/btrfs/directory
可能/some/btrfs/directory与 属于同一个 Btrfs 文件系统/source。