Restic: 慢，虽然它只是检查时间戳

创建于 2016-02-17 · 5评论 · 资料来源: restic/restic

我有 164809 个要定期备份的文件（大约 60GB）......每次我运行“静态备份”时，报告的速度都不会超过 33MB/s，并且使用 strace 检查它只是在进行 lstat() 调用。

这使得每次备份大约需要 20 分钟。我想知道restic在做什么，因为几乎所有文件都没有修改，它显示稳定的33MB / s，我知道它只需要lstat（）它们，这正是restic在备份的第一步已经做的，只是为了显示总大小，在 6 或 7 秒内。

是否只是检查同一文件/时间戳的内容所花费的 cpu 时间已经存在于先前的快照中？

feature enhancement

资料来源

viric

最有用的评论

是的，这很可能是原因。对于这个特定的用例，有一个解决方法：对backup命令使用-f ( --force ) 选项，这将再次在本地读取所有文件，而不是从 repo 加载元数据. 那应该很快。

fd0 于 2016-08-13

👍2

目前，文件和目录的元数据没有被缓存，而是从存储库中加载（和解密）。每个目录执行一次。我计划在本地缓存元数据，这尚未实现，但应该会大大加快“增量”备份的速度。

fd0 于 2016-02-19

👍2

你好

这是否还会导致通过慢速 WAN 连接进行增量备份的性能不佳？

我刚刚将一个包含超过 9000 个文件和 250MB 的文件夹备份到远程 s3 服务器。两台计算机都通过上下 50/5 mbit/s 的非对称互联网连接进行连接。

初始备份大约需要 5 分钟，看起来相当合理。但此后不久的第二次备份花费了几乎两倍的时间！文件较少的文件夹似乎要快得多。

Kidswiss 于 2016-08-13

fd0 于 2016-08-13

👍2

非常感谢！奇迹般有效！

Kidswiss 于 2016-08-13

我们在 master 分支中添加了一个本地元数据缓存（参见 #1040），我认为这个问题已经解决，因此我将关闭它。谢谢！

fd0 于 2017-09-26

此页面是否有帮助？

0 / 5 - 0 等级