备份，第3部分：概述和测试重复性，重复

本文介绍了通过在备份服务器上创建档案进行备份的备份工具。

满足要求的是重复性（重复性好，以deja dup的形式存在）和重复性。

另一个非常出色的备份工具是dar，但是由于它具有很多选择，因此测试方法几乎不能覆盖它所能提供的功能的10％，因此我们不在当前周期中对其进行测试。

预期结果

由于两位候选人都以一种或另一种方式创建档案，因此您可以使用普通tar作为指导。

此外，我们通过创建仅包含文件的完整副本与当前状态之间或过去与当前存档之间的差异（递增，递减等）的备份，评估存储服务器上数据存储的优化程度。

备份行为：

1. 备份存储服务器上的文件数量相对较少（与备份数量或以GB为单位的数据大小相比），但是文件大小却很大（数十到数百兆字节）。
2. 存储库的大小将仅包括更改-不会存储重复项，因此存储库的大小将小于基于rsync的软件的大小。
3. 使用压缩和/或加密时，预计会对处理器造成沉重负担；如果归档和/或加密过程将在备份存储服务器上正常工作，则可能会对网络和磁盘子系统造成足够大的负担。

作为参考值，运行以下命令：

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar" 

执行结果如下：

播放时间3分12秒。 可以看出，速度取决于备份存储服务器的磁盘子系统，如rsync示例所示。 只是快一点，因为 记录转到一个文件。

另外，要评估压缩，我们将运行相同的选项，但是在备份的服务器端启用压缩：

 cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz" 

结果如下：

前置时间为10m11s。 瓶颈很可能是接收方的单线程压缩器。

相同的命令，但是将压缩与原始数据一起传输到服务器，以检验瓶颈是单线程压缩器的假设。

 cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz" 

原来是这样的：

前置时间为9分37秒。 压缩机清晰地显示出一个芯的负载，因为 网络传输速度和源磁盘子系统上的负载是相似的。

要评估加密，可以通过将可选的openssl或gpg命令连接到管道来使用openssl或gpg。 作为参考，将有这样一个命令：

 cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc" 

结果如下：

由于在接收端启动了两个进程，因此执行时间为10m30s-瓶颈仍然是单线程压缩器，加上小的加密开销。

UPD：应bliznezz的要求，我添加了Pigz测试。 如果仅使用压缩器-压缩时间为6m30秒，如果还添加加密，则压缩时间约为7m。 底部图中的失败是未分配的磁盘缓存：

测试重复性

Duplicity是通过创建加密的tar存档的python备份软件。

对于增量归档，将使用librsync，因此，您可以期望上一循环注释中描述的行为。

可以使用gnupg对备份进行加密和签名，这在使用各种提供程序来存储备份（s3，backblaze，gdrive等）时很重要。

让我们看看结果是什么：

指定的块大小为512 MB，在图表上清晰可见； 处理器负载实际上保持在50％，这意味着该程序使用的处理器内核不超过一个。

该程序的工作原理也非常清晰可见：他们获取了一部分数据，将其摇晃后发送给备份存储服务器，这可能会很慢。
另一个功能是程序的可预测运行时间，它仅取决于更改后的数据的大小。

启用加密并没有显着增加程序的运行时间，但是将处理器负载增加了大约10％，这可能是一个不错的奖励。

不幸的是，该程序无法通过重命名目录来正确检测到这种情况，结果存储库的大小等于更改的大小（即全部18GB），但是使用不受信任的服务器进行备份的功能肯定可以解决此问题。

测试重复

该软件用C＃编写，是使用Mono的一组库启动的。 有一个GUI以及一个cli版本。

主要功能的示例列表几乎是重复的，包括各种备份存储提供程序，但是，与重复不同，大多数功能无需第三方工具即可使用。 加号或减号-这取决于具体情况，但是，对于初学者来说，很容易在安装python软件包之前一次列出所有功能，就像重复一样。

另一个小问题是，该程序代表开始备份的用户主动写入本地sqlite数据库，因此，每当该过程开始使用cli时，您都需要另外监视所需数据库的正确指示。 通过GUI或WEBGUI进行操作时，详细信息将对用户隐藏。

如您所见，该程序可以在多个线程中工作，但这不是一个更有效率的解决方案，如果您比较加密，它将启动一个外部程序
结果比使用Mono套件中的库更快。 也许这是由于外部程序得到了更优化的事实。

一个令人愉快的时刻也是事实，即存储库的大小恰好与更改实际数据一样多，即 duplicati检测到目录重命名并正确处理了这种情况。 运行第二项测试时可以看到这一点。

总的来说，该程序给人留下了很积极的印象，包括对初学者的友好程度。

结果

两位候选人的工作都相当缓慢，但总的来说，与通常的焦油相比，有进步，至少是重复的。 这种进步的代价也是可以理解的-明显的负担
处理器。 通常，在预测结果时没有特别的偏差。

结论

如果您不需要着急，并且处理器上还有余地，那么考虑到的任何解决方案都可以做，无论如何，已经完成了很多工作，不应通过在tar之上编写包装脚本来重复执行这些工作。 如果不能完全信任用于存储备份的服务器，则加密的存在是非常必要的属性。

与基于rsync的解决方案相比，尽管tar的纯格式工作速度比rsync快20-30％，但性能可能会差好几倍。
可以节省存储库的大小，但这仅用于重复项。

公告公告

备份，第1部分：为什么需要备份，方法，技术概述
备份，第2部分：概述和测试基于rsync的备份工具
备份，第3部分：概述和测试重复性，重复性，重复性
备份，第4部分：概述和测试zbackup，restic，borgbackup
备份，第5部分：测试Linux的Bacula和Veeam备份
备份：读者要求的部分：AMANDA审查，UrBackup，BackupPC
备份，第6部分：比较备份工具
备份第7部分：结论

由 Finnix 发布