btrfs 子卷很棒，可以嵌套。 Docker支持btrfs，并大量使用嵌套快照。
我正在尝试将我的/var/lib/docker 移动到新驱动器。
程序"应该"是。
1- 制作/var/lib/docker 的 ro 快照
btrfs sub snap create /var/lib/docker /var/snapshots/docker_some_datetime
源和目标位于同一 FS 上。
2.- 将快照发送到新驱动器
btrfs send /var/snapshots/docker_some_datetime | btrfs receive /mnt/drive2/snapshots/
在 Docker 文件夹中，有一个装满子卷的 BTRFS 文件夹。我希望快照中的文件夹也是子卷，但它们似乎只是常规文件夹。
;TLDR 那么，问题是，如果我拍摄嵌套了子卷的
子卷的快照，它们是否也应该在快照中成为子卷？我在这里遇到了 btrfs 限制吗？
简而言之：不，嵌套子卷不包含在其父级的快照中，而是正如您在父级快照中看到的空目录所表示的那样，请参阅 BTRFS Wiki。
要为嵌套子卷布局创建快照，您必须手动递归地拍摄所有包含的子卷。
让我们将BTRFS-Subvolumes 视为"普通"分区，并看一个例子：
- HDD 的一个分区挂载在
/mnt/hdd上，第二个分区挂载在/mnt/hdd/nested上。 - 如果您对第一个分区进行完整备份(例如作为
.img或.iso)，这将不包括第二个分区，因为它当前已挂载在第一个分区的"内部"。
即使第一个分区未挂载，您仍然可以对其进行备份。
由于BTRFS子卷的处理方式与分区类似，因此递归btrfs-send(包括当前"挂载"的子卷)更为复杂。
据我所知，没有内置函数可以只用一个命令来做到这一点。
我曾经挖掘过维基上提到的BTRFS备份工具，据我所知，其中一个工具正是具有该功能：https://btrfs.wiki.kernel.org/index.php/Incremental_Backup#Available_Backup_Tools
现在是BTRFS(据我所知)：
如果您挂载BTRFS分区(例如通过
/etc/fstab)，默认情况下，它是顶级子卷获取挂载在所需位置。并且驻留在挂载的BTRFS-子卷中的所有子卷(通过与顶级子卷具有子-父关系)也会自动"挂载"在相对子路径上。
尽管并非一个 BTRFS 设备的所有子卷都必须始终可见：如果使用挂载选项
subvolid=<ID-of-some-Subvolume>，则只有子子卷会自动"挂载"在相对子路径上。
(我在引号中多次输入"mounted"，因为子子卷没有真正挂载 - 它们在普通 Linux 挂载时不可见)