标签: snapshot

当我阅读时man zfs，zfs receive我看到

     -F      Force a rollback of the file system to the most recent snap-
             shot before performing the receive operation. If receiving an
             incremental replication stream (for example, one generated by
             "zfs send -R -Fi -iI"), destroy snapshots and file systems
             that do not exist on the sending side.

但我不太明白-F实际上会做什么。

如果我zfs receive tank/pool然后收到的快照在目标端文件系统上回滚，这就是我想要的。

我想在哪些情况下使用-F？

我已经测试了两台主机之间的 10Gbit 连接，以便能够从 host1 读取 10GB 文件并使用 netcat 将其写入 host2，其速度为 410MB/s。

当我通过相同的专用 10Gbit 连接使用 netcat 再次进行 ZFS 发送/接收时，我只能获得 70MB/s。快照为 2.5TB，包含 1500 万个文件。

题

这种放缓的原因可能是什么？瓶颈是回滚这么多文件的快照需要很多时间，还是文件数量不受ZFS回滚速度的影响？

更新

10GB 文件传输测试，我得到了 410MB/s，我想模拟了带回滚的 ZFS 发送/接收。因此，根据这个假设，我看到如此不同的速度让我感到非常惊讶。我使用速度来比较两个测试，所以我不必用随机数据生成 2.5TB 文件。

所以我不明白为什么“从主机 1 读取文件，使用 netcat 传输，将文件写入主机 2”比“zfs 从主机 1 发送快照，使用 netcat 传输，主机 2 上的 ZFS 接收/回滚”要快得多。

也许另一种问同样的方法是？：

如果我有两个相同大小的 2.5TB 快照，其中快照 1 包含 1 个文件，快照 2 包含 1500 万个文件。zfs receive他们两个的时间会一样吗？或者一个会比另一个更快？

抱歉这里有点新。我不得不接管一家拥有大约 10 个 ec2 实例的小公司的 aws。看起来实例每天都通过快照进行备份。目前有超过 400 个快照。我无法弄清楚它们是如何实现自动化的，因此我可以查看政策。

当我查看 Lifecycle Manager 时，目前没有政策。我还查看了 cloudwatch 中的事件，事件下没有规则。最后，我查看了服务器本身，看看是否有脚本通过 cron 运行而什么也没有。

所以我不知道这些快照是如何每天自动工作的？如果有人知道我应该在哪里找到它，将不胜感激。

这是我的场景：我有两台服务器（还有更多，但本场景有两台），一台是 Solaris 备份服务器，第二台是 CentOS Linux 服务器。每天晚上，CentOS 服务器都会运行一个 cron 作业来将自身同步到 Solaris 备份服务器。完成此操作后，它会将日期和时间放入 Solaris 服务器上的一个特殊文件中。Solaris 服务器每分钟运行一个 cron 作业，如果它看到这个文件，它就会抓取内容并使用它来制作快照。

结果很棒：每天备份都会自动运行，然后创建 ZFS 快照。工作了两个多月。我原以为现在空间不足，需要开始（手动）删除旧快照。但事实上，我在空间上很好。我唯一担心的是，随着每天增加 60 多个快照，大量 ZFS 快照是否存在任何已知问题？ZFS 文件系统可以拥有的 ZFS 快照数量是否有上限？或者我可以继续积累快照直到空间不足？

我在 Ubuntu 上使用 VirtualBox，其中安装了一些程序。并且快照文件不会停止增长。

我不需要这个功能。我只想将我的数据保存在虚拟 Windows 硬盘上。

如何删除 20GB 的快照而不丢失我的文档和设置，并且不启动另一个不断增长的快照？

谢谢你。

是否可以让 ZFS 仅在文件更改时制作文件系统的快照，即 pool/filesystem/？不是使用 cron 或其他东西每 5 分钟自动创建一个快照，是否可以在文件更改后让 ZFS 自动拍摄快照？

这可能吗？它会涉及什么？你会怎么做？

提前致谢。

我在 KVM/ubuntu 上运行了几个虚拟机，它们都是从参数开始的-snapshot（虚拟机只计算一些在重新启动后可能被破坏的东西）。

在我读过的文档中，更改不会写回图像，而是存储在临时文件中，并且在关闭后将被删除。

现在，我想知道这些“临时文件”存储在文件系统的哪里？

我们有一个运行 Win2k8 的虚拟机的大约 15 个快照的树，您可能已经猜到我们的数据存储很快就会耗尽空间。我的目标是删除所有快照，因为将快照用于备份目的似乎是一个巨大的错误。

现在我的问题是我们如何删除快照，以便将数据存储上的最少空间用于合并过程，因为剩下的空间不多。我们是否开始自下而上删除树，即。首先删除最近的快照并向上移动，还是开始删除最旧的快照并向下移动？

我正在寻找有关 AWS 托管环境中 MongoDB 灾难恢复的最佳实践建议。

我们的设置在这一点上是相当标准的，3 个服务器的副本集（1 个主服务器、1 个辅助服务器和 1 个仲裁器），主服务器和辅助服务器上的 mongo 卷是 EBS 支持的。所有这些都在一个区域中，分布在多个可用区中。最终我们需要跨越区域，但这是改天的讨论。

我在 Mongo 文档中看到的备份建议谈到了 EBS 快照（这很容易实现自动化）。然而，如果灾难来袭，它们不会让我们回到失败的时代。

• 我是否需要记录 oplog 并结合使用它们来在故障后恢复？
• 我是否应该在副本集中启动另一个实例，专门用于备份和快照，而不是拍摄主要和次要快照？如果是这样，我们又回到了 oplog 问题，不是吗？
• 我是否应该对每个副本卷进行快照并完全依赖副本集来覆盖故障和最后一个快照之间的时间？

我正在寻找可用的最强大的策略。高达第二次数据保护和故障后系统恢复速度的优先级高于价格。我们可以稍后优化价格。

在此先感谢您的所有建议...

在 ESXi 5.1 上，我几个小时前开始删除快照。

大约 800GB 的大快照。机器是 SQL Server。

删除时只有 34%。

我可以在删除时关闭机器，以便更快地完成吗？

后果：

好吧，仅供参考。这是负责我们的企业数据仓库的数据库服务器。它运行 SQL Server，每天都有很多活动，因为 ETL 过程正在运行。

那是一个月前的快照。

到昨天为止，ETL 的总时间是 8 小时，在删除快照后，它下降到 2.5 小时。干杯!