Tim Foster's Weblog

我即将完成这个版本的 ZFS Automatic Snapshot SMF 服务，刚刚将一些更改放到了 opensolaris.org 的 Mercurial Repository 上。

这是一个非常重要的版本，修复了一些从发布时起就一直困扰我的缺陷。但是不可避免地，大量的更改也会带来大量的 bug。所以，我希望在发布正式版本前获得一些反馈。

如果您敢于（就是说您还没有在生产中使用它！）使用您最喜欢的源代码管理系统（是 hg，对吗？）并访问大部分未经测试的 ZFS Automatic Snapshot 0.11 Early Access 版本，请访问：

hg clone ssh://anon@hg.opensolaris.org/hg/jds/zfs-snapshot

我与 Niall 及 Erwann（他们曾经在 DSK-5 工作过）一起在 Desktop 组工作，以获得桌面上的 ZFS Automatic Snapshots，到目前为止，看起来我的代码将提供后端服务（显然 ZFS 也一样），以便在台式机或膝上电脑运行时一些更改才能发挥作用。

因为这个原因，我没有对打包的 GUI 进行任何更改，因为它很快就要消失了。但是，我仍然尽力确保有办法关闭这些关注于小型系统的二进制代码，并且该服务与较早的清单保持向后兼容。

那么在 0.11 中有什么新内容呢？看到 Nils 以那种方式（稍后会有更多相关内容）写下他的更改后，我想我也应该开始写一个更改日志（Changelog）——这里是 0.11 到目前为止一些带注释的 Changelog 条目：

0.11

添加 RBAC 支持

• 该服务现在在 zfssnap 角色下运行
• 服务 start/stop 日志位于 /var/svc/log 下
• 其他日志保存到 /export/home/zfssnap（以及 syslog）[是的，这不怎么样——有更好的解决方案吗？ ]

添加了一个“zfs/interval”属性值“none”，它不使用 cron

向方法脚本添加了一个 svcprops 的缓存（好主意，Nils！）

添加了一个所有实例使用的 com.sun:auto-snapshot 用户属性，com.sun:auto-snapshot:$LABEL 优先

删除了快照名称的第二个字段——它不需要（好主意，H?kan！）

更改了 // 与递归快照工作的方式——忽视子快照，改为根据哪个数据集拥有 zfs 用户属性自动确定何时获取递归快照

将 avoidscrub 默认设置为 false（在 nv_94 中修复了 6343667）

修复了 Dan 提出的 bug（谢谢！）——卷也是数据集

通过在启动时设置 com.sun:auto-snapshot=true 自动快照所有内容。（这在所有顶层数据集上完成——在顶层数据集上设置为 false 的现有属性将覆盖它）

启动时检查丢失的快照

清除 shell 类型

清除 preremove 脚本（我知道，在移动到 IPS 之前，我需要使这些脚本冗余）

编写此变更日志

在用户可见性方面，最明显的变化是在 RBAC 下运行，以及默认情况下获取所有文件系统的快照——我意识到后者可能会有争议，但是如果您不喜欢它，您可以将其关闭。我也对“//”计划的改变感到很高兴——在这种特殊情况下，我们现在忽略“zfs/snapshot-children”，而使用标记为“com.sun:auto-snapshot=true”的文件系统列表来确定哪个文件系统获取递归快照，哪个必须获取单独快照。在大型系统上这会造成巨大的差异。

这个版本中唯一缺少的是 Nils Goroll 建议的一个更改，该更改旨在提高系统执行计划安排的方式——有关更多信息，请参阅此处。我觉得舍弃 cron 会导致该服务的工作方式比较陌生。如果 cron 是问题所在，当然一种解决方案是不用它，但是修复 cron 的缺陷是不是也不错呢？是的，这个问题留到以后有时间时再解决。

那我不再啰嗦了，在自述文件中有完整的文档——请尽情享用，如果您遇到什么奇怪的问题，请告诉我——在 2008 年 11 月之前仍有时间修复它（是的，所有这些都可以，尽管现在我的日常工作非常紧张！现在 xVM Server 花费了我 99% 的时间，所以我非常期望这个 ZFS 自动快照预览版能够发现大部分 bug！）

我已经完成了 ZFS Automatic Snapshot SMF Service 的一个新版本。

这个版本修复了两个缺陷修复，一个由 Reid Spencer 指出，而另一个来自于 Breandan Dezendorf。谢谢你们，非常感激！

在这个版本中也增加了一个新的小新功能，该功能由 Eric Kustarz 在 zfs-discuss 邮件列表上提出。即当发生 zpool 重新同步(resilvering)或清洗(scrubbing)时，该服务应该避免获取快照。

我希望此功能只是一个暂时的要求，6343667 有更多详细信息。

实现起来非常简单，但是运行地很好——在 SMF 清单中有一个新属性“zfs/avoidscrub”，默认情况下它被设置为 true。当执行 crontab 条目时，如果该属性被设置为 true，我们会检查支持将要快照的数据集的池，查看它当前是否正在清洗或重新同步中。如果是，我们会向 syslog 报告一条消息，并在调用这个 cron 作业时跳过当前的数据集。

我已经更新了自述文件，您可以以 zfs-auto-snapshot-0.10.tar.gz 形式下载这些更改。

希望这些对你们有用。跟以前一样，欢迎发表评论和报告缺陷！

在这篇博客中我会发布一组 ZFS Automatic Snapshot & Backup 工具，这也许是最后一组了。别担心——这些服务不会消失，但是 Desktop 组中有些人开始更仔细地着手这个工作，所以它们可能会作为一个项目转移到 opensolaris.org 上的某个地方。稍后提供更多相关内容。

我现在已经有了两个新包——每个包中主要的更改是有更多的 GUI 集成，只是一些简单的 zenity 工具，用户无需使用命令行就可以配置服务，安装后它将出现在 GNOME 菜单下的“Administration”中——您也许需要 pkill gnome-panel 或者注销后才能看到该更改。

我对这些 GUI 工具的权限模式不太满意（它们使用 gksu to root 运行），希望它们马上会被换掉。我还解决了更多其他困难以便适当地打包这些服务，这样安装/删除容易多了。以下有更多详细信息。

ZFS Automatic Snapshot Service 0.9

除了新的 GUI 代码，这里还有一些其他代码：

• 打包——现在我们拥有一个 Makefile，并且构建了一个暂时叫做 TIMFauto-snapshot 的包。欢迎给这个包取个更好的名字。这些只是 SVR4 包——我还没有带宽来使用 IPS，所以请留意 postinstall/preremove 脚本！


• 添加了一些经常使用的预配置 SMF 实例，例如每日、每小时、每周和每月快照计划，这样用户不必操心为它们创建一个清单。


• 包含了一个特殊的“fs-name”值“//”，使该服务可以查看 ZFS 用户属性“com.sun:auto-snapshot:<label>”，这样用户可以标记要被包含到给定快照计划的文件系统，而不需要接触 SMF 属性。上面的预定义实例使用这个值。


• 将启动和停止方法的超时更改为无限——当系统上有很多实例时，10 秒的超时有时会引起该服务放弃尝试启动。由于我添加 cron 条目的方式，我需要序列化这些实例的启动，这样它们就可以花 10 秒以上的时间来启动（取决于您拥有的实例数量）。这还不够理想，欢迎提供更好的建议。我想这也许可以修复 Siegfried 看到的问题，但是我仍然无法正确地重现它。


• 一位用户评论说，快照名称中含有字符“:”会使它们无法从 Samba 客户端访问——所以我添加了一个 $SEP 变量到该方法脚本中，以允许管理员更改。我现在犹豫不决，我不知道是否应该将它作为一个新的 SMF 属性添加进去，因为我不知道到底有多少人需要这项功能。目前来说，如果您需要，您可以编辑该方法脚本的第 64 行。

有关更多信息，请查看更新的自述文件。

ZFS Automatic Backup Service 0.2

没有太多更改——主要是增加了 GUI，并将该服务放入了它自己的包，自动快照服务的警告在这里也适用——这个包当前叫做 TIMFauto-backup。

有关更多信息，请查看更新的自述文件。

---

现在，公布完最新消息后，我想寻求一些帮助。鉴于这些服务在未来可能获得更多关注（创建 Indiana 的人认为在 distro 中拥有这些会很容易），我想看看我们是否能够让更多的人关心这些代码。

如果有人愿意检查这些这些服务的代码，我非常乐意接受您的批评。我自己定期使用它们，我知道有不少人也使用它们，所以它们确实在以预期的方式工作（至少目前是这样，根据墨菲法则，我今天发布的这些版本会给您带来灾难！）——但是，据我所知它们还未进行代码检查，无论是从高层的架构角度还是从个人的角度。

这些会成为 Desktop 整合或者某个其他定位于 Indiana 的整合的候选项吗？也许有一天整合到 Solaris 也说不定。当然，目前自动备份服务太以面向桌面了，但是计划快照服务似乎也是某种我们希望在服务器上实现的东西，不是吗？（我不知道如何开始那个决策过程）

所以，欢迎所有的评论——我可以接受，如果这意味着丢弃所有这些实现并返回绘图板，那么这将是一个最佳的时刻！

现在——您已经阅读了所有这些内容（谢谢）——以下是该软件。在每个 tarball 中，有一个预先创建的“proto”目录包含该包（这是一个架构无关项）。要进行安装，超级用户只需执行：

# cd <install dir>/proto
# pgkadd -d <name of package>

• zfs-auto-backup-0.2.tar.gz
• zfs-auto-snapshot-0.9.tar.gz

尽情享受吧！

这儿是对 ZFS Automatic Snapshot SMF 服务的一个小更新，这个更新最初在这里提到过。在这个版本中修复了一些缺陷，还添加了一个小功能。

第一个缺陷修复是好心的 Dick 指出的——对此很抱歉，但是现在没有问题了。

第二个有一点微妙。曾经有段时间，当我启动机器时，我注意到尽管快照服务实例都在 online 中列出，它们的日志也没有错误，但是却没有得到任何东西的快照——本来应该在启动该服务时添加到系统 crontab 的条目不存在。

后来发现，这是因为我没有以任何形式锁定我对 crontab 的访问，所以服务实例就会互相冲突：在这种情况下，SMF 将非常“高效”，它将并行启动所有实例（理应如此！）:-) 我现在使用的锁定可能不是最好的——有更好的想法请告诉我。但它似乎很有效。

我还添加了一个小功能——给实例添加了一个“verbose”属性，其默认设置为 false。在我的一个文件系统上，每 10 分钟有一个递归回滚快照，我已经厌烦了系统日志中总是充满了被删除的旧快照实例，而这个功能解决了该问题。

像以前一样，如果您有任何反馈，请告诉我——我很乐意改进这项服务。

新版本可以从 zfs-auto-snapshot-0.8.tar.gz 下载，我已经在自述文件中添加了这些更改。

我刚刚对 ZFS Automatic Snapshots SMF Service 完成了一个相对比较次要的更新。

这里最主要的更新源于 Bill 的（友好的）抱怨：当从 cron 脚本运行时该服务有一点噪音。太对了！每次服务运行时，它都要为该服务调出 FMRI - 即使一切正常时，它仍然会打印，因此导致比必要输出更多的噪音。

（出于某种原因，现在我对意外的输出特别敏感，对于婴儿比平常要吵的叫声倍加敏感[Bananas 今天注射了 2 个月大时应该注射的疫苗，这使她有点不舒服]）。

除了修复该问题，我还检查了方法脚本记录日志的方式。以前，脚本中的 stdout 由 cron 处理，将输出用邮件发送到根。现在，我已经更改了脚本中所有的日志记录，现在消息都通过 logger(1) 报告到 syslogd(1M)：我仍然喜欢让消息到达每个实例相应的 SMF 日志中，但是由于我们是从 cron（而不是 SMF）运行脚本，这会有一点棘手。由于这些更改，现在运行该服务时，您将在 syslog 中得到类似下文的消息：

Nov 27 11:55:16 haiiro zfs-auto-snap:[ID 702911 daemon.notice] space/timf@zfs-auto-snap:frequent-2006-10-28-22:30:00 being destroyed as per retention policy.

- 该服务不是太冗长，如果您有任何反馈，请告诉我。我已经更新了自述文件，在文中提及此事。

新版本现在可以从 zfs-auto-snapshot-0.7.tar.gz 下载。

我已经为 ZFS Automatic Snapshots SMF Service 原型编写了下一轮功能。您可以以 zfs-auto-snapshot-0.6.tar.gz 形式下载

本版本中主要的新功能包括：

• ZFS Send/Receive 支持
• 每个文件系统多个计划

发送/接收支持意味着，需要时服务可以发送每个快照的备份，无论是完整的流还是递增的流（取决于该服务的配置）。该服务还将发送所有子文件系统的快照（如果需要），尽管在 ZFS 中没有 send -r 支持，现在这还有一点小问题。

有一个 SMF 属性，用户可以在恢复备份流的命令中使用该属性。通常，这应该是“zfs receive”，但是理所当然应该将输出 cat 到 NFS 服务器上的单个文件中。我还修改了打包的 GUI,以便在构建新的清单时请求这些新选项：

每个文件系统多个计划的功能允许用户给每个快照计划分配一个可选标签，这样同一数据集可以有多个计划。例如，对于一个给定文件系统，您可以选择每月进行完整备份，发送到远程服务器（并且作为平面文件备份到磁带），也可以选择每天进行增量备份，通过 zfs 发送/接受不同的服务器。

该标签还可以快速告诉您哪些文件系统运行了哪些服务。例如，这里是我桌面的当前配置：

root@haiiro[236] svcs | grep zfs
online         Aug_31   svc:/system/filesystem/zfs/auto-snapshot:space-archive
online         Aug_31   svc:/system/filesystem/zfs/auto-snapshot:tank-root_filesystem
online         13:28:27 svc:/system/filesystem/zfs/auto-snapshot:space-timf
online         17:47:37 svc:/system/filesystem/zfs/auto-snapshot:default
online         18:00:02 svc:/system/filesystem/zfs/auto-snapshot:tank-new,backup
online         18:01:02 svc:/system/filesystem/zfs/auto-snapshot:tank-new,moreoften

我已经更新了这些新功能的文档和自述文件，如果有任何不清楚的地方，请告诉我。

最后，我努力在面对失败时作出正确的事情。如果备份因为某种原因失败了，该服务将会移动到 maintenance（维护）状态，在这种情况下，应该删除 cron 作业。另外，我也在做一些基本的锁定，以在尝试发送同一实例的另一个备份流之前，查看 zfs send 命令是否仍然在运行。不幸的是，据我所知，似乎没有一种便捷的方法来设置/获取 SMF 的属性（欢迎反馈）。

我希望这个这对您有用，如果您遇到问题，欢迎报告这些 bug！

另： Chris 也在使用 ZFS 快照做一些很漂亮的东西——都在他的博客上：非常值得看一看！

[ 更新此处 ]

前几天，Roger 要求将一个额外功能加入我编写的 ZFS Automatic Snapshots SMF 服务。这个功能是，为每个文件系统配置多个快照计划的能力。

例如，我拥有一个 ZFS 文件系统，已为其配置了一个每周执行一次快照的快照服务，并让它们在系统上保留几个月时间。但是，在白天，我还希望系统每隔一小时可以自动获取该文件系统的快照，但是只保留前 6 个小时的快照。

“容易！”，我想——然后开始编写对该功能的支持。在这个过程中，我还添加了对新的 snapshot -r ZFS 功能的支持，现在 Solaris Nevada 中具有该功能，它的确提高了速度。

但是，当我思考这个功能时，很快就遇到了问题（真糟糕）。当时，每个快照服务的实例配置一组不同的自动快照。例如，这是我桌面上的：

root@haiiro[59] svcs auto-snapshot
STATE          STIME    FMRI
disabled       16:49:03 svc:/system/filesystem/zfs/auto-snapshot:space-test
online         16:08:55 svc:/system/filesystem/zfs/auto-snapshot:space-archive
online         16:08:55 svc:/system/filesystem/zfs/auto-snapshot:space-timf
online         16:08:55 svc:/system/filesystem/zfs/auto-snapshot:tank-root_files ystem
online         16:49:03 svc:/system/filesystem/zfs/auto-snapshot:default

每个实例的 FMRI 细致地限定了每组快照的边界——实例名称没有任何特殊意义，除了显示那一瞬间系统的状态。我获取快照所需的所有有用的信息实际上都存储在实例属性中。

但是，当我开始思考同一文件系统的多个实例时，我总是遇到名称空间冲突（不同于这些）

我无法创建实例名称 "svc:/system/filesystem/zfs/auto-snapshot:space-timf:hourly"、"svc:/system/filesystem/zfs/auto-snapshot:space-timf@hourly" 或 "svc:/system/filesystem/zfs/auto-snapshot:space-timf$hourly"—— SMF 不允许实例名称中有这些字符。

我想我在寻求以某种方式细分实例——我曾考虑过在每个实例内有单独的属性组，每个组对应该文件系统的一个不同的计划，但是随后服务的粒度会出现问题：对于给定的文件系统，我无法禁止每小时一次的快照，同时启用每月一次的快照。这也许没关系？

我会继续思考这个问题。另外，我仍在为 cron 作业寻找将快照状态记录到 SMF 日志的最佳方式——将 cron 脚本的输出重定向到每个 FMRI 相应的 restarter/logfile 似乎不是正确的做法。也许再来点儿喝咖啡会有所帮助，但是不管怎么样，欢迎提供更多的想法！

Wes 曾非常友好地指出，ZFS Automatic Snapshots SMF Service 前几个版本中基于 zenity 的 GUI 在早期版本的 JDS 下无法工作。进行一番研究之后，我们发现，在较早的基于 GNOME 2.6 的 zenity 中，我依赖的一些 zenity 功能不存在。

所以，我已经准备了该软件的另一个版本供您试用 - zfs-auto-snapshot-0.4.tar.gz（链接现在删除了，请参阅这个帖子底部的“更新”），这比我预期的要快。

现在我们会检测系统上有哪个版本的 zentiy，然后进行正确的操作。我在里面包含了一个自述文件，以方便第一次使用的用户。

我还清除了一些为每个快照计划创建 SMF 实例名称的逻辑。在较早的代码中，如果您的两个 ZFS 文件系统 tank/foo-bar 和 tank/foo/bar 具有独立的 快照计划（不是严格要求，因为您可以拥有一个 tank 的计划，并使用“snapshot all child datasets”[对所有子数据集进行快照]选项），SMF 将无法导入第二个实例——在 SMF 实例名称中我们不能使用“/”，所以我使用字符“-”来代替，因此名称空间产生了冲突。现在这个问题已经修复了，欢迎所有的反馈！

据说最好的备份是您不需要担心的备份，我认识到 ZFS 快照只是“合适的”备份解决方案的第一步，在我每天测试 ZFS 的日子里，这个东西已经让我免于寻求磁带的帮助……

也许下一步应该是扩展现有的功能，提供一个使用 zfs 接收/发送的选项，这样伴随着按计划获取快照，我们还可以将这些快照增量地存储到一台远程机器上（而且还可以进行电子邮件提醒！- Zawinski 法则？提出！）

但是，现在是都柏林最漂亮的时候，这在这里是很少见的，所以我要出去玩了:-)祝大家周末愉快！

6 月 30 日更新：Joe 指出了一个 bug，即递归快照没有严格遵守保留限制：这是因为我在 shell 函数中使用的变量名和调用它的函数所使用的一样（我以为 ksh 使用 local-scoping 作为变量名）。您可以在 zfs-auto-snapshot-0.5.tar.gz 中获得修复的代码。再次感谢 Joe 报告了这个 bug！

9 月 6 日更新：更多信息请参阅此处。

11 月 27 日更新：更多信息请参阅此处。

我刚刚更新了我以前提到过的 ZFS Automatic Snapshot SMF 服务。

现在我们支持仅保留固定数目的快照，删除最旧的自动快照。如果我们要求该服务快照所有子数据集，这项功能也可以正确执行。当然，当我们寻找要删除的旧快照时，我们仅查看由此服务创建的快照，至少也要查询与我们的命名模式 (erm) 匹配的快照。也许我应该整理的好一点……

同样更新的是，该服务方法现在行为完全正常了，如果您以前没有见过 SMF，那么您肯定会喜欢这个更新。如果该服务方法内的任何任务失败了，现在我们会将该服务移动到 maintenance（维护）状态，然后等待管理员修复它。

仍然有更多工作要做，我想找到一种正确的方法，将 cron 作业的消息记录到该服务实例正确的 SMF 日志中——仅将 stdout 和 stderr 重定向到（比如）/var/svc/log/system-filesystem-zfs-auto-snapshot:space-timf.log 似乎不太合适。谁有更好的想法？

timf@haiiro[571] svcs -l svc:/system/filesystem/zfs/auto-snapshot:space-timf
fmri         svc:/system/filesystem/zfs/auto-snapshot:space-timf
name         ZFS automatic snapshots
enabled      true
state        online
next_state   none
state_time   Tue May 30 13:58:35 2006
logfile      /var/svc/log/system-filesystem-zfs-auto-snapshot:space-timf.log
restarter    svc:/system/svc/restarter:default
dependency   require_all/none svc:/system/filesystem/local (online)
dependency   require_all/none svc:/system/cron (online)

至今没有 GUI 更改，但如果您希望了解一下，可以下载最新的 tarball zfs-auto-snapshot-0.3.tar.gz。

欢迎评论和建议！

6 月 8 日更新：可以在这里查看最近有关此主题的帖子

最近我思考了很多关于 ZFS 快照的问题，并且有了一些人们可能会感兴趣的想法。下面我将介绍其中一个想法（其他想法将陆续推出——请关注此空间）

在 zfs-discuss 上，有些人在思考一种根据计划自动获取快照的机制，这是一个好主意。我很赞同这个想法，我建议最好集成到 SMF 中，我还发表了一些关于如何实现该机制的看法。

现在，我有了一个可以使用的原型。它以 SMF 为基础，创建一个 cron 作业，周期性地获取您指定的文件系统的快照。

我认为您应该拥有多个该服务的实例（而不是一个默认实例），每组您想获取的自动快照都有一个实例。我也获得了对创建递归快照的支持，给 zfs snapshot 加上一个 -r 标志会使该支持更好（并且更简单！）

我还没有实现“rolling snapshot”（滚动快照）功能，所以我们只能保持 x 个旧快照。为此，我正在焦急地等待新的 ZFS 标志 -s，该标志使我能根据快照创建时间排序，并删除最老的快照（就是 tail -1 那个快照！）。cron 当前的功能对我也有一点限制，但是我想这些对于初学者来说已经足够了。

它看起来是什么样的？下面是一个“屏幕快照”：

# svcs | grep zfs
online         18:36:11 svc:/system/filesystem/zfs/auto-snapshot:space-timf
# svcs -l svc:/system/filesystem/zfs/auto-snapshot:space-timf
fmri         svc:/system/filesystem/zfs/auto-snapshot:space-timf
name         ZFS automatic snapshots
enabled      true
state        online
next_state   none
state_time   Wed May 10 18:36:11 2006
logfile      /var/svc/log/system-filesystem-zfs-auto-snapshot:space-timf.log
restarter    svc:/system/svc/restarter:default
dependency   require_all/none svc:/system/filesystem/local (online)
dependency   require_all/none svc:/system/cron (online)

是的，看起来并不是那么 令人兴奋。为了更加简便，我写了一个简单的管理 GUI，它向您询问一些相关的问题，并为您构建实例清单。它需要最新版的 zenity（感谢 Glynn！）才能工作，但是这已经包含在 Solaris 中了，所以应该没有问题。看起来就像这样：

对了，如果您希望试一试，请下载此 tarball 的副本，并执行以下操作：

# cp zfs-auto-snapshot/lib/svc/method/zfs-auto-snapshot /lib/svc/method
# svccfg import zfs-auto-snapshot/zfs-auto-snapshot.xml
#  [ now create an instance, using my GUI, or your text editor of choice ]
# svccfg import my-auto-snapshot-instance.xml
# svcadm enable svc:/system/filesystem/zfs/auto-snapshot:tank-foo

如果一切顺利，您应该在 crontab 中看到一个新条目（使用 crontab -l 检查），并且将开始获得定期的快照。由于这是 SMF，您可以使用 svcadm disable svc:/system/filesystem/zfs/auto-snapshot:tank-foo 禁用。我已经在 snv_35 上对其进行了测试，似乎没什么问题，但是如果您遇到了什么奇怪的事情，请告诉我。

现在，还有一些工作要做：特别是，这里处理的错误并不是重点（如果我们因为某种原因无法获得快照，我愿意该服务降级），我还需要实现回滚快照功能，并且应该在安全角色和配置文件方面更加敏感。尽管如此，但作为第一次尝试，我想这已经很不错了。

下面展示的是我拥有的所有快照，包括文件系统的自动快照和手动快照：

# zfs list -r space/timf
NAME                   USED  AVAIL  REFER  MOUNTPOINT
space/timf            1.28G  24.9G  1.28G  /space/timf
space/timf@backup     1.66M      -   458M  -
space/timf@more-recent   114K      -   989M  -
space/timf@something_else  87.5K      -  1003M  -
space/timf@zfs-auto-snap-2006-05-10-19:00:00      0      -  1.28G  -

欢迎评论！

5 月 11 日更新：我已经修复了方法脚本中的一个缺陷，该缺陷可能引起一个自动快照 cron 作业覆盖另一个作业，被覆盖的作业应该是当前作业的子作业。我还调整了 GUI，以根据间隔类型更改快照周期。以上链接更新为指向新的 tarball。

5 月 12 日更新：修复了另一个创建 cron 作业方面的 bug。

6 月 8 日更新：可以在这里、这里、 这里还有这里查看最近有关此主题的帖子。