本说明讨论通过在备份服务器上创建存档来执行备份的备份工具。
满足要求的包括口是心非（具有 deja dup 形式的漂亮界面）和 duplicati。
另一个非常出色的备份工具是 dar，但由于它有非常广泛的选项列表 - 测试方法仅涵盖其功能的 10% - 我们不会将其作为当前周期的一部分进行测试。
预期结果
由于两位候选人都以某种方式创建档案，因此可以使用常规 tar 作为指导。
此外，我们将通过创建仅包含完整副本与文件当前状态之间的差异或先前存档与当前存档之间（增量、减量等）的备份副本来评估存储服务器上数据存储的优化程度。 。
创建备份时的行为：
- 备份存储服务器上的文件数量相对较少（与备份副本的数量或以 GB 为单位的数据大小相比），但其大小相当大（数十到数百兆字节）。
- 存储库大小将仅包含更改 - 不会存储重复项，因此存储库大小将小于基于 rsync 的软件。
- 使用压缩和/或加密时，CPU 负载预计会很高，如果归档和/或加密进程在备份存储服务器上运行，则网络和磁盘负载可能会很高。
让我们运行以下命令作为参考值：
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"执行结果如下：
执行时间3分12秒。 可以看出，速度受到备份存储服务器的磁盘子系统的限制，如示例所示 。 只是快一点，因为…… 录音到一个文件。
另外，为了评估压缩，让我们运行相同的选项，但在备份服务器端启用压缩：
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"结果如下：
执行时间10分11秒。 最有可能的瓶颈是接收端的单流压缩机。
相同的命令，但通过压缩将原始数据传输到服务器，以测试瓶颈是单线程压缩器的假设。
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"结果是这样的：
执行时间为 10 分 30 秒，因为接收端有 2 个进程正在运行 - 瓶颈又是单线程压缩器，加上少量的加密开销。
UPD： 应 bliznezz 的要求，我添加了 Pigz 测试。 如果只使用压缩器，需要6m30s，如果还加上加密，则需要7m左右。 底部图中的凹陷是未刷新的磁盘缓存：
重复测试
Duplicity 是一款 Python 软件，通过创建 tar 格式的加密档案来进行备份。
对于增量存档，使用 librsync，因此您可以预期中描述的行为 .
可以使用 gnupg 对备份进行加密和签名，这在使用不同的提供程序存储备份（s3、backblaze、gdrive 等）时非常重要
让我们看看结果是什么：
这些是我们在不加密的情况下运行时得到的结果
剧透
每次试运行的运行时间：
发射 1
发射 2
发射 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
以下是启用 gnupg 加密且密钥大小为 2048 位时的结果：
加密后相同数据的运行时间：
发射 1
发射 2
发射 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
显示的块大小为 512 兆字节，这在图表中清晰可见； 处理器负载实际上保持在 50%，这意味着该程序使用的处理器核心不超过一个。
该程序的操作原理也非常清晰可见：他们获取一段数据，将其压缩，然后将其发送到备份存储服务器，这可能会非常慢。
另一个特点是程序的可预测运行时间，该时间仅取决于更改数据的大小。
启用加密并没有显着增加程序的运行时间，但它使处理器负载增加了大约 10%，这可以说是一个相当不错的奖励。
不幸的是，这个程序无法正确检测目录重命名的情况，结果存储库大小等于更改的大小（即全部 18GB），但可以清楚地使用不受信任的服务器进行备份涵盖了这种行为。
重复测试
该软件是用 C# 编写的，并使用 Mono 的一组库运行。 有 GUI 和 CLI 版本。
主要功能的大致列表与 duplicity 类似，包括各种备份存储提供商，但是，与 duplicity 不同的是，大多数功能无需第三方工具即可使用。 这是优点还是缺点取决于具体情况，但对于初学者来说，一次列出所有功能可能会更容易，而不是像现在这样为 python 安装额外的包口是心非的情况。
另一个小细微差别 - 程序会代表启动备份的用户主动写入本地 SQLite 数据库，因此您还需要确保每次使用 cli 启动进程时正确指定所需的数据库。 当通过 GUI 或 WEBGUI 工作时，详细信息将对用户隐藏。
我们看看这个方案能产生什么指标：
如果关闭加密（WEBGUI不建议这样做），结果如下：
营业时间：
发射 1
发射 2
发射 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
启用加密后，使用 aes，它看起来像这样：
营业时间：
发射 1
发射 2
发射 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
如果使用外部程序 gnupg，则会出现以下结果：
发射 1
发射 2
发射 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
正如您所看到的，该程序可以在多个线程中工作，但这并不意味着它是一个更高效的解决方案，如果您比较加密工作，它正在启动一个外部程序
事实证明比使用 Mono 集中的库更快。 这可能是由于外部程序更加优化所致。
另一个好处是存储库的大小与实际更改的数据完全相同，即duplicati 检测到目录重命名并正确处理了这种情况。 运行第二个测试时可以看到这一点。
总体而言，对该计划的印象相当积极，包括对新手相当友好。
结果
两位候选人的工作速度都相当慢，但总的来说，与常规 tar 相比，至少在复制方面有所进步。 这种进步的代价也很明显——一个明显的负担
处理器。 总体来说，预测结果没有特别的偏差。
发现
如果您不需要赶到任何地方，并且也有一个备用处理器，那么所考虑的任何解决方案都可以，无论如何，已经完成了相当多的工作，不应该通过在 tar 上编写包装器脚本来重复这些工作。 如果不能完全信任用于存储备份副本的服务器，则加密的存在是非常必要的属性。
与基于解决方案的比较 - 尽管事实上 tar 的纯粹形式比 rsync 快 20-30%，但性能可能会差几倍。
存储库的大小可以节省，但仅限于重复项。
公告
备份第 3 部分：审查和测试口是心非、重复、似曾相识
备份第 4 部分：审查和测试 zbackup、restic、borgbackup
备份第 5 部分：测试适用于 Linux 的 bacula 和 veeam 备份
备份第 6 部分：比较备份工具
备份第 7 部分：结论
发表者： 帕维尔·德姆科维奇
来源： habr.com