加密备份枪战

最近，我一直在花时间来提高bupstash（我的加密备份工具）的性能，并想将其与一些现有工具进行比较，以尝试在备份工具领域中找到其相对性能。

这篇文章比较了一系列简单的基准测试中的bupstash，restic，borg备份和普通的tar + gzip + GPG。

随时查看项目网站以了解更多信息，让我们进入基准测试。

该测试计算机具有AMD Ryzen Threadripper 1950X 16核处理器，16 GB内存和NVMe SSD硬盘驱动器。最好只是相对地比较结果，因为要完全复制我的测试环境将很困难。

我用于基准测试的脚本可以在这里找到，尽管它们确实需要针对您的环境进行调整。

对于此基准测试，我们采用20个连续的Linux内核源代码版本，并将它们全部添加到同一目录中，然后创建快照并测量生成的tarball /存储库的大小。

为此测试选择的linux内核版本是5.9版之前的所有连续git commit，其结果目录包含21 GB的未压缩文件。

该基准测试表明，与普通的tarball相比，更先进的工具具有优势，当将相似的数据多次添加到备份存储库中时，它们都具有极好的压缩率。

快照都是针对tmpfs创建的，因此希望不会测量网络或磁盘活动引起的延迟。

该基准与新鲜的本地快照基准相同，只不过这些文件是通过ssh发送到托管在Google云上的远程服务器的。该基准仅应视为延迟对工具性能的影响的近似值，因为它取决于网络速度。

在进行基准测试时，与远程服务器的连接可以总结如下：

普通的tar赢得了胜利，Restic在这里表现不佳，它具有对时延敏感的上传协议。

该基准与新的本地快照基准相同，除了现在我们使用工具的内置缓存机制来测量增量快照的时间。这意味着每个工具都会记录其已发送的文件，并且能够跳过此工作。

增量tar是这里的明显赢家，但是为什么其他工具速度较慢？我认为这主要是因为其他工具将每个快照作为完整备份呈现给用户，因此进行了额外的工作以使最终用户免于手动管理增量备份。

我也很有趣，bupstash put比其他类似工具快一个数量级，尽管我目前无法清楚地解释为什么可能是这种情况。

该基准与增量本地快照基准相同，只不过这些文件是通过ssh发送到托管在Google云上的远程服务器的。

在此基准测试中，我们会将在新的本地快照基准测试中创建的快照还原到tmpfs。这是衡量需要从备份存储库进行批量灾难恢复时发生的情况的信息。

在此基准测试中，我们会将在新的远程快照基准测试中创建的快照还原到tmpfs。与以前的基准测试的主要区别是在备份存储库和还原点之间引入了Internet连接。

有趣的是，网络的引入使tar领先于bupstash进行备份还原-这是我非常有兴趣进一步研究的事情。

在此基准测试中，我们将从同一台计算机上的备份存储库中删除旧快照。对于此测试，我们生成一个备份存储库，其中包含不同版本的Linux内核源代码的50个不同的快照，然后确定删除其中一个快照所花的时间。当不再需要旧基准备份时，此基准可以模拟将旧备份从备份存储库中循环出来。

具有增量备份的Tar无法轻易支持对旧备份的修剪，因此不参与此基准测试。

在修剪备份存储库时，bupstash垃圾收集器的速度比restic和borg快了一个数量级。

在此基准测试中，我们将从存储在远程服务器上的备份存储库中删除旧快照。远程服务器与新鲜远程快照基准测试中使用的服务器相同，测试数据与本地修剪基准标记相同。

对于此基准，我们重复新的快照基准，但是要测量“ time”命令报告的客户端ram峰值使用量（RSS）。对于tar，我们通过将tar，gpg和gzip的峰值内存使用量相加来近似得出。

与restic和borg相比，Bupstash的存储效率非常高，但最终却失去了tar + gzip + GPG的简单性。

GNU Tar + gzip + gpg是一个出色的加密备份选项，性能比我预期的要好。我认为tar和gpg对于喜欢自己备份自己的备份脚本的用户来说仍然是一个不错的选择。考虑到这一点，我们必须问其他工具解决的tar问题是什么？我的观点是，与使用borg / restic / bupstash相比，使用增量tar时管理增量备份，重复数据删除，修剪和搜索备份要困难得多。使用增量tar，很快很难跟踪哪些增量tarball相互依赖，并且您通常需要定期进行完整快照-失去了大部分速度优势。

作为bupstash有偏见的作者，我也对bupstash的表现感到满意，并希望我将来能将其进一步推广。 Restic，尽管在本地操作上速度很快，但是当网络延迟变得混乱时，似乎落后于其他工具。 Borg是一个全方位的出色工具，并且表现出色。

我可以看到每种测试工具的优点和改进的余地，并鼓励大家尝试一下，如果您还没有尝试过的话。