btrfs子卷很棒，可以嵌套。 Docker支持btrfs，并大量使用嵌套快照。
我正在尝试将/ var / lib / docker移至新驱动器。
过程“应该”。
1-制作/ var / lib / docker
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限制吗？
答案 0 :(得分：0)
让我们暂时将BTRFS-Subvolumes视为“常规”分区，然后看一个示例：
/mnt/hdd上，第二个分区安装在/mnt/hdd/nested上。.img或.iso），则将不包含第二个分区，只是因为当前已安装该分区在第一个分区“内部”。即使第一个分区未未安装，您仍然可以对其进行备份。
由于BTRFS子卷的处理与分区类似，因此递归btrfs发送（包括当前“已安装”的子卷）更加复杂。
据我所知，没有内置函数可以仅使用一个命令来完成此操作。
我曾经浏览过Wiki上提到的BTRFS备份工具，据我所知，其中一个工具正好具有此功能：https://btrfs.wiki.kernel.org/index.php/Incremental_Backup#Available_Backup_Tools
现在就使用BTRFS（据我了解）：
如果您挂载BTRFS分区（例如，通过/etc/fstab），则默认情况下，它是在所需位置挂载了顶层Subvolume。
所有驻留在已安装的BTRFS子卷中的子卷（通过与顶层子卷有子代关系）也将自动“安装”在相对子路径中。
尽管并非所有BTRFS设备的所有子卷都必须始终可见：如果使用挂载选项subvolid=<ID-of-some-Subvolume>，只有子子卷会自动“挂载”在相对的子路径上。
（由于子Subvolumes未真正安装 ，因此多次在引号中加上“ mount”字样-它们在正常的Linux装载中不可见）
答案 1 :(得分：0)
简而言之：不，嵌套子卷不包含在其父级的快照中，而是如您所见，在父级快照中用空目录表示，请参阅 BTRFS Wiki。
要对嵌套子卷布局进行快照，您必须手动递归地对所有包含的子卷进行快照。