让我们谈谈 OpenZFS 快照

在 ZFS 快照管理的基础知识中，我们演示了如何使用快照和克隆从给定的时间点访问数据。在本文中，我们将了解如何使用 ZFS 引导环境 (BE) 将操作系统本身引导到上一个时间点。如果您一直在关注本系列，您可能已经发现创建和管理 OpenZFS 快照是多么容易。如果您还没有使用过快照，请尝试一下！我们相信你很快就会想知道没有他们你是如何相处的。如果您已经在使用快照并且不是积极的快照修剪器，您可能想知道：多少快照太多了？由于没有无限存储容量这样的东西，您的可用磁盘空间是一个明显的限制因素。但是快照会在什么时候导致性能下降？与其他文件系统不同，一个或一千个快照的存在对文件系统的性能没有影响，读取和写入文件的执行方式相同。但是，管理操作（例如列出和删除快照）的性能受每个数据集中存在的快照数量的影响。有数百个快照可以吗？假设有足够的存储容量，那么拥有数千或数万个快照呢？根据我们的经验，在列出、创建、复制和销毁快照时，每个数据集超过 1000 个快照开始导致严重的性能问题。性能影响与系统上的快照总数无关，而是与每个数据集上的快照数量相关。 100 个数据集每个包含 100 个快照将不会对列表性能产生影响，而具有 2000 个快照的单个数据集可能需要几秒钟才能返回快照列表。虽然您可能永远不需要存储那么多快照，但您仍然希望随着时间的推移从快照消耗的空间中获得最大价值。互联网搜索不会给出多少快照太多的明确答案，答案范围从“不要担心”到“取决于”。虽然不尽如人意，但问题的关键是没有确定的答案，因为每个人的存储系统和数据使用情况不同。本文介绍了一些要问自己的问题，因为答案将帮助您更好地了解快照的使用。然后，您可以使用该信息来确定适合您需求的快照创建和修剪计划，而不会导致性能下降。第一个问题可能并不明显，但对于了解创建快照的时间和频率至关重要。理想情况下，您希望创建重要并提供最大价值的快照。举个例子：考虑一个 Web 服务器，其中的内容仅在有新产品发布或现有产品的新软件发布时才会更改，或者 Web 团队会定期扫描以刷新和改进内容。在内容更改之前拍摄快照是有意义的，网络团队可能希望将网站以前版本的存档保留数年。在这种情况下，快照数量最少，存储时间长，并且根据内容更改的数量，快照之间可能存在相当多的差异。

这种情况与存储许多用户的主目录的文件服务器甚至您整天工作的个人工作站完全不同。这些用例往往受益于定期的自动快照，例如在工作时间内每 15、30 或 60 分钟一次。这会导致大量快照的价值随着时间的推移而迅速减少。当用户对文件进行更改时，您如何确定文件更改的值（以及快照的频率和保留快照的时间）？当然，这取决于。如果系统管理员正在对配置文件进行更改，那么保留以前的更改非常有价值，至少在更改得到验证之前是这样。如果用户正在对电子表格进行更改，则定期快照可能会也可能不会捕获他们希望重新捕获的特定更改。这给我们带来了一个问题：用户在使用哪些应用程序？许多现代桌面应用程序和操作系统都提供了内置的文件版本历史记录。大多数开发人员使用修订系统，并被教导“尽早并经常提交”的口头禅。许多业务应用程序在线运行或托管在外部云中，通常提供版本历史记录。只有您才能了解您的用户正在使用哪些应用程序，他们是否正在利用内置的历史/修订系统，以及他们是否因为没有使用修订应用程序或总是忘记提交或保存版本而打扰您进行文件恢复.您还知道哪些系统在您的控制之下，哪些类型的数据足够重要以保证使用 OpenZFS 快照保留以前的版本。如果您有大量存储容量，则归档快照的成本会很低。但是，计划的快照确实会增加。考虑一下数学：每小时拍摄 1 个数据集快照会导致每周 168 个快照——换句话说，按照该计划需要大约 6 周才能实现每个数据集性能达到 1000 多个快照。对于此示例，您需要考虑是否每天每小时都需要一个快照，以及何时开始修剪较旧的快照。问问自己：在 3 个月前的上午 10:00 和上午 11:00 保留数据集的快照是否有价值？ 1个月前？上星期？这是上一个问题的另一面。如果您从 5 周前开始在上午 10:00 删除文件系统的快照，这会有什么大不了的吗？如果没有，您需要回溯多远才能保留有价值的快照？

也许您的快照是基于活动而不是计划驱动的？如果是这样，您还需要访问 3 个 pkg-updates 前的数据吗？问问自己：如果某个特定版本不再可用，您将花费多少时间和精力？到现在为止，您应该更好地了解哪些数据对快照很重要以及您希望捕获该数据的频率。接下来，您需要确定是否有足够的存储容量来维护所需数量的快照。如果容量成为一个问题，您可以决定是否值得添加更多容量或重新考虑您的快照修剪计划。首先列出池的空间属性 (-o)。这是我的笔记本电脑上的坦克池的剪辑示例： Zfs list -o space NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD tank 270G 69.2G 0 88K 0 69.2G tank/ROOT 270G 44.4G 0 48K4mar 0/4RO tank 41.6G 18.7G 23.0G 0 0 tank/usr/home/dru 270G 4.34G 1.17G 3.17G 0 2.36M 已用：使用量（与任何文件系统一样，OpenZFS 性能在接近容量时会开始受到影响；通常您希望保持在 80% 以下或考虑在系统开始接近 90% 时增加更多容量）在此示例中，此系统上仍有足够的存储容量。有趣的是，dru 主目录中超过 25% 的空间被快照使用。

在具有许多快照的系统上，这种类型的列表可以快速浏览哪些文件系统消耗最多的快照空间，以及指定池上仍有多少可用容量的总体视图。您还可以将特定数据集归零。请注意，最后一个命令是 zpool（为了查看池使用情况），而此命令使用 zfs（因为我正在列出一个数据集）。这次我将获得我的主目录数据集的 usedbysnapshots 属性：正如预期的那样，快照使用的空间与前面清单中看到的 1.17G 匹配。虽然 usedbysnapshots 属性给出了快照消耗了多少空间，以及如果数据集中的所有快照都被破坏将释放多少空间的概念，它并不表示如果您开始，您将获得多少空间只修剪一些快照。由于其 COW 性质，OpenZFS 无法释放仍被引用的块。例如，我将创建一个列表，显示我主目录中快照的 NAME、WRITTEN、REFER 和 USED 列（按此顺序）： zfs list -t all -o name,written,refer,used | grep dru@ tank/usr/home/dru@test-backup 2.71G 2.71G 176M tank/usr/home/dru@homedir。 176M 2.71G 12.6M tank/usr/home/dru@homedir-mod 18.5M 2.71G 18.1M 写入属性对于理解快照增长很有用，因为它表示自拍摄快照以来写入数据集的引用空间量。 used 列表示该快照有多少数据是唯一的；换句话说，如果删除该特定快照，将释放多少空间。

执行详细的空运行 (-nv) 将显示通过销毁指定快照将回收的空间量。数量将与上面列表中的 used 列匹配： zfs destroy -nv tank/usr/home/dru@test-backup 将销毁 tank/usr/home/dru@test-backup 将回收 176M zfs destroy -nv tank/ usr/home/dru@homedir 会破坏 tank/usr/home/dru@homedir 会回收 12.6M zfs destroy -nv tank/usr/home/dru@homedir-mod 会破坏 tank/usr/home/dru@homedir-mod会回收 18.1M 想了解更多关于 ZFS 的信息吗？在我们的系列文章中，我们一直在写关于 OpenZFS 的强大功能。了解哪些数据从快照中受益以及保留快照的时间长度将有助于您充分利用 OpenZFS 快照。将快照修剪为您需要的快照将使您更容易找到要恢复的数据、节省磁盘容量并防止 OpenZFS 系统出现性能瓶颈。在 Klara，我们有一个完整的团队致力于帮助您完成 FreeBSD 项目。无论您是在计划一个 FreeBSD 项目，还是在一个项目中间并需要一些额外的洞察力，我们都在这里为您提供帮助！