☰

Btrfs：要启用子卷快照，是否需要为每个数据子卷创建专用于快照的单独子卷？

tag-icon • tag-icon debian btrfs snapshot
Btrfs：要启用子卷快照，是否需要为每个数据子卷创建专用于快照的单独子卷？

作为最初的免责声明，我不希望快照包含 Inception 风格的快照。

因此，例如，如果我已@安装在/，并@_snapshots安装在/.snapshots，那么由于/.snapshots是一个子卷，因此它不会包含在 的快照中/，但仍会显示在 下/。这很好。

但是，比如说@home_fsinatra，安装在 处呢/home/fsinatra？该子卷的快照“应该”放在哪里？在一个名为 的专用快照子卷中@home_fsinatra_snapshots，显示在/home/fsinatra/.snapshots?或者在某个地方/.snapshots/...（尽管我不确定如何实现）。

我非常熟悉 ZFS 固有的嵌套数据集和快照，并且从一开始就使用了 Btrfs，但直到现在才避免弄乱快照。这是为了在 Btrfs 上安装一个新的系统驱动器，就像我当前在 ZFS 上的系统一样，它将实际使用逻辑嵌套的子卷和快照（尽管为了简单起见可能采用字面平面配置并通过“嵌套” fstab）。快照可以是手动的，也可以通过 Snapper 自动生成。

我并没有执着于任何特定的想法或要求，除了 Btrfs - 以及对某些内容（例如系统和个人用户主页）进行快照，但不对其他内容（例如各种 tmp 和缓存目录、/opt、/var、docker 等）进行快照。我的子卷也没有需要坦白说，我只是根据时代精神假设这是最简单的。

（这适用于 SSD 上的 Debian Bookworm BTW、amd64。）

答案1

这似乎不仅仅是一个不受欢迎的话题或需要回答的问题，而且地球上还有很多关于这个话题的错误信息，或者至少是人们对这个话题的理解很差，而 12 个人对此非常关心，并在互联网上写下了相关文章。

更相关的是，在我看来，作为文件系统用户工具设计决策，一般概念似乎不必要地复杂。

我最初回答了我自己的问题，并解释了为什么我最初的问题中提出的主张可能确实是“最好的”（如果不是唯一的）方法。具体来说：

但是，比如说@home_fsinatra，安装在 处呢/home/fsinatra？该子卷的快照“应该”放在哪里？在一个名为 的专用快照子卷中@home_fsinatra_snapshots，[手动安装] 位于/home/fsinatra/.snapshots？

但这不是唯一的方法。事实上，这种方法的缺点很快就变得明显：如果您频繁或自动（或实际上任何）快照 - 比如说您的主目录 - 那么在您的主文件夹下（特别是在该文件夹中）很快就会积累一堆垃圾~/.snapshots，这使各种公用事业陷入困境——有些是难以或不可能真正避免的。当然，您可以使用许多实用程序（例如 rsync 和备份程序）以及其他实用程序的某些标志来排除它 - 但不能使用其他实用程序。例如，它不仅仅作为符号链接出现。

ZFS 通过默认隐藏的虚拟文件夹以出色的方式解决了这个难题。 （不仅仅是点隐藏，我的意思是它永远不会出现在目录列表中，因此除非通过名称专门戳，否则无法访问。）

ZFS 在子卷下呈现“子卷”（又名数据集或文件系统）的快照，与上面提出的想法非常相似。但是默认情况下，除非您通过文字字符串手动遍历它，否则它是不可发现的。任何实用程序或程序都不会通过遍历/扫描文件系统而偶然发现它，除非它被编程为出于某种原因显式测试该确切命名的文件夹。

但由于 Btrfs 不这样做（公平地说，它不是很“标准”），我预计这种“卷下快照”对于典型用户来说有太多缺点。尽管如此，通过成为自己的子卷，它仍然避免了“快照启动”问题。然而，这仍然可以通过更轻量级的符号链接来完成，大多数工具已经非常擅长检测和避免，除非用户要求不这样做。

因此，我的新方法是使用一个快照卷，与@和@home（以及其他）同级，所有快照都在该卷下。我的裸 Btrfs 卷看起来像这样：

@/                          -> /
@home~fsinatra/             -> /home/fsinatra/
@snapshots/                 -> /.snapshots/
@snapshots/@/               -> /.snapshots/@/
@snapshots/@home~fsinatra/  -> /.snapshots/@home~fsinatra/

请注意，@snapshots 下的第一级对象只是常规文件系统文件夹，而不是嵌套子卷。换句话说， for @snapshots/@/,@snapshots是一个子卷，但@其下只是一个普通文件夹。 （当我发布这个问题时，我不知道这是可能的，但它让事情变得更容易。）当为@or创建快照时/，它们只是被定向到下面/.snapshots/@/

每个子卷都有自己的专用文件夹，具有相同的名称，位于@snapshots/. （当然都是手动设置的。）

没有理由你有镜像快照下的子卷名称和相同的平面布局。您可以改为模仿安装的层次结构。但是，将快照文件夹与层次结构文件夹混合在一起看起来很奇怪，而且很难管理，后者可能会增长到数百或数千个。我认为明确定义例如快照是更清晰的仅有的在根 ( @) 下，每个子卷在同一级别都有自己的专用快照文件夹。

再说一遍，如果您确实希望快照文件夹嵌套在分层文件系统中，只需将符号链接文件夹命名.snapshots回/.snapshots.通过符号链接，它避免了重量级安装文件夹所带来的大多数上述问题。

（对我来说）仅镜像 下的子卷名称 1:1 也是有意义的/.snapshot。然后快照可以命名为 YYYMMDD-HHMMSS，并且在上下文中具有完美的意义。

无论您采用什么策略，您都需要了解巨大的警告

如果您想要一个真正平坦的子卷布局（无论您是否通过手动 via 嵌套它们fstab）：

您不应该在已安装的文件系统上创建子卷。

如果这样做，所有新的实际上都会嵌套在@. （或者您安装在的任何子卷名称/。）

相反，您需要做的是将底层 Btrfs 分区本身（未指定子卷）安装到安全且不碍事的地方。 （说， 。）我只是暂时/mnt/btrfs-root这样做，也许是永久的。fstab这使您可以轻松访问顶层，在那里您只能看到 和@以及@home任何其他顶层子卷。因此，当您为快照和/或用户主目录创建其他平面子卷时，请使它们相对于/mnt/btrfs-root/（或其他），而不是相对于/.这样，它们将是其他子卷（包括“根”子卷）的兄弟姐妹，而不是子卷。

（否则你必须指定，比如说，-o subvol=@/@snapshotsin fstab，否则它不会挂载。它不会存在于@snapshots。这就是让我陷入这个被遗弃的兔子洞的陷阱。）

一旦理解了这个概念，它可能看起来很明显，也许对你来说总是显而易见的，读者 - 但据我所知，整个互联网上可能只有一个人写过关于它的文章 - 这让我省了很多[进一步]头痛，愿奥丁在来世眷顾他或她的灵魂。

愿这有助于在未来十年内为另外三个人带来回报。

还有一个技巧让我和其他人深感困惑：在 Debian 测试中，当 Calamares 安装在 Btrfs 上时，它会将子卷条目放入fstab命名/@和/@home.而 Ubuntu 总是分别将它们命名为@和@home（不带前导斜杠）。我测试了它，在带和不带前导斜杠的情况下启动，在我的情况下，它以任何一种方式工作。我推测前导斜杠更精确，否则mount只是假设它是相对于安装时指定卷的根目录的。

相关内容