本文将考虑备份软件，该软件通过将数据流分解为单独的组件（块）来形成存储库。
存储库组件可以进一步压缩和加密，最重要的是 - 在重复备份过程中 - 重复使用。
此类存储库中的备份副本是彼此连接的命名组件链，例如基于各种散列函数。
有几个类似的解决方案，我将重点关注其中的 3 个：zbackup、borgbackup 和 Restic。
预期结果
由于所有申请人都需要以一种或另一种方式创建存储库，因此最重要的因素之一是估计存储库的大小。 理想情况下，根据公认的方法，其大小不应超过 13 GB，甚至更小 - 需要进行良好的优化。
我们还非常希望能够直接创建文件的备份副本，而无需使用 tar 等归档程序，并且无需使用 rsync 和 sshfs 等其他工具即可使用 ssh/sftp。
创建备份时的行为：
- 存储库的大小将等于或小于更改的大小。
- 使用压缩和/或加密时，预计 CPU 负载会很高，如果归档和/或加密过程在备份存储服务器上运行，则可能会出现相当高的网络和磁盘负载。
- 如果存储库损坏，在创建新备份和尝试恢复时都可能出现延迟错误。 有必要计划额外的措施来确保存储库的完整性或使用内置工具来检查其完整性。
使用 tar 作为参考值，如之前的一篇文章所示。
测试 zbackup
zbackup的一般机制是程序在输入数据流中查找包含相同数据的区域，然后选择性地压缩和加密它们，每个区域仅保存一次。
重复数据删除使用带有滑动窗口的 64 位环哈希函数来检查与现有数据块的逐字节匹配（类似于 rsync 的实现方式）。
多线程lzma和lzo用于压缩，aes用于加密。 最新版本能够将来从存储库中删除旧数据。
该程序是用 C++ 编写的，具有最小的依赖性。 作者显然受到了unix-way的启发，因此该程序在创建备份时接受stdin上的数据，在恢复时在stdout上产生类似的数据流。 因此，在编写自己的备份解决方案时，zbackup 可以用作非常好的“构建块”。 例如，文章作者从大约 2014 年开始就使用该程序作为家用机器的主要备份工具。
除非另有说明，数据流将是常规 tar。
让我们看看结果是什么：
该作品有 2 个选项进行检查：
- 创建存储库并在服务器上启动包含源数据的 zbackup，然后将存储库的内容传输到备份存储服务器。
- 在备份存储服务器上创建存储库，通过 ssh 在备份存储服务器上启动 zbackup，并通过管道将数据发送到它。
第一个选项的结果如下：43m11s - 当使用未加密的存储库和 lzma 压缩器时，19m13s - 当用 lzo 替换压缩器时。
原始数据服务器上的负载如下（显示了 lzma 的示例；lzo 的情况大致相同，但 rsync 的份额约为时间的四分之一）：
显然，这样的备份过程仅适用于相对罕见且较小的更改。 强烈建议将 zbackup 限制为 1 个线程，否则 CPU 负载会非常高，因为该程序非常擅长在多线程中工作。 磁盘上的负载很小，这对于现代基于 SSD 的磁盘子系统来说通常不会被注意到。 您还可以清楚地看到将存储库数据同步到远程服务器的过程的开始；操作速度与常规 rsync 相当，并且取决于备份存储服务器的磁盘子系统的性能。 这种方法的缺点是需要存储本地存储库，从而导致数据重复。
更有趣且更适用于实践的是第二个选项，直接在备份存储服务器上运行 zbackup。
首先，我们将在不使用 lzma 压缩器加密的情况下测试操作：
每次试运行的运行时间：
发射 1
发射 2
发射 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
如果使用 aes 启用加密，结果非常接近：
加密后相同数据的运行时间：
发射 1
发射 2
发射 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
如果使用 lzo 将加密与压缩结合起来，则如下所示：
营业时间：
发射 1
发射 2
发射 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
生成的存储库的大小相对相同，均为 13GB。 这意味着重复数据删除工作正常。 另外，在已经压缩的数据上，使用 lzo 效果显着；就总运行时间而言，zbackup 接近 duplicity/duplicati，但落后于基于 librsync 的 2-5 倍。
优点是显而易见的——节省备份存储服务器上的磁盘空间。 至于存储库检查工具，zbackup的作者没有提供；建议使用容错磁盘阵列或云提供商。
总的来说，给人留下了非常好的印象，尽管该项目已经停滞了大约 3 年（最后一次功能请求大约在一年前，但没有得到回应）。
测试 borgbackup
Borgbackup 是 attic 的一个分支，是另一个类似于 zbackup 的系统。 它用 python 编写，具有一系列与 zbackup 类似的功能，但还可以：
- 通过保险丝挂载备份
- 检查存储库内容
- 工作在客户端-服务器模式
- 对数据使用各种压缩器，并在压缩时启发式确定文件类型。
- 2 种加密选项，aes 和 blake
- 内置工具用于
绩效检查
borgbackup 基准测试 ssh://backup_server/repo/path local_dir
结果如下：
CZ-BIG 96.51 MB/秒（10 100.00 MB 全零文件：10.36s)
RZ-BIG 57.22 MB/秒（10 100.00 MB 全零文件：17.48s)
UZ-BIG 253.63 MB/秒（10 100.00 MB 全零文件：3.94s)
DZ-BIG 351.06 MB/秒（10 100.00 MB 全零文件：2.85s)
CR-BIG 34.30 MB/秒（10 100.00 MB 随机文件：29.15s)
RR-BIG 60.69 MB/秒（10 100.00 MB 随机文件：16.48s)
UR-BIG 311.06 MB/秒（10 100.00 MB 随机文件：3.21s)
DR-BIG 72.63 MB/秒（10 100.00 MB 随机文件：13.77s)
CZ-中 108.59 MB/秒（1000 1.00 MB 全零文件：9.21s)
RZ-中 76.16 MB/秒（1000 1.00 MB 全零文件：13.13s)
UZ-MEDIUM 331.27 MB/秒（1000 1.00 MB 全零文件：3.02s)
DZ-MEDIUM 387.36 MB/秒（1000 1.00 MB 全零文件：2.58s)
CR-MEDIUM 37.80 MB/秒（1000 1.00 MB 随机文件：26.45s)
RR-中 68.90 MB/秒（1000 1.00 MB 随机文件：14.51s)
UR-MEDIUM 347.24 MB/秒（1000 1.00 MB 随机文件：2.88s)
DR-中型 48.80 MB/秒（1000 1.00 MB 随机文件：20.49s)
CZ-小 11.72 MB/秒（10000 10.00 kB 全零文件：8.53s)
RZ-小型 32.57 MB/秒（10000 10.00 kB 全零文件：3.07s)
UZ-小 19.37 MB/秒（10000 10.00 kB 全零文件：5.16s)
DZ-小 33.71 MB/秒（10000 10.00 kB 全零文件：2.97s)
CR-小 6.85 MB/秒（10000 10.00 kB 随机文件：14.60s)
RR-小 31.27 MB/秒（10000 10.00 kB 随机文件：3.20s)
UR-小 12.28 MB/秒（10000 10.00 kB 随机文件：8.14s)
DR-小 18.78 MB/秒（10000 10.00 kB 随机文件：5.32s)
测试时，将使用压缩启发式来确定文件类型（自动压缩），结果如下：
首先，我们来看看没有加密的情况下它是如何工作的：
营业时间：
发射 1
发射 2
发射 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
如果启用存储库授权（身份验证模式），结果将接近：
营业时间：
发射 1
发射 2
发射 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
当激活 aes 加密时，结果并没有恶化太多：
发射 1
发射 2
发射 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
而如果将 aes 改为 blake，情况就会彻底好转：
营业时间：
发射 1
发射 2
发射 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
与 zbackup 的情况一样，存储库大小为 13GB，甚至更小，这是普遍预期的。 我对运行时间非常满意；它与基于 librsync 的解决方案相当，提供了更广泛的功能。 我还很高兴能够通过环境变量设置各种参数，这在自动模式下使用 borgbackup 时提供了非常重要的优势。 我对备份期间的负载也很满意：从处理器负载来看，borgbackup 在 1 个线程中工作。
使用时没有什么特别的缺点。
静态测试
尽管 Restic 是一个相当新的解决方案（前 2 个候选方案早在 2013 年或更早的时候就已为人所知），但它具有相当好的特性。 用 Go 编写。
与 zbackup 相比，它还提供：
- 检查存储库的完整性（包括检查部分）。
- 用于存储备份的大量受支持协议和提供程序，以及对用于云解决方案的 rclone - rsync 的支持。
- 相互比较 2 个备份。
- 通过保险丝安装存储库。
总的来说，功能列表与 borgbackup 非常接近，在某些地方更多，在其他地方更少。 其特点之一是无法禁用加密，因此备份副本将始终被加密。 让我们看看在实践中可以从这个软件中挤出什么：
结果如下：
营业时间：
发射 1
发射 2
发射 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
性能结果也与基于 rsync 的解决方案相当，并且通常非常接近 borgbackup，但 CPU 负载更高（运行多个线程）并且呈锯齿状。
最有可能的是，该程序受到数据存储服务器上磁盘子系统性能的限制，就像 rsync 的情况一样。 存储库大小为13GB，就像zbackup或borgbackup一样，使用该解决方案时没有明显的缺点。
结果
事实上，所有候选人都取得了相似的结果，但付出了不同的代价。 Borgbackup 表现最好，restic 稍慢一些，zbackup 可能不值得开始使用，
如果它已经在使用，请尝试将其更改为 borgbackup 或 Restic。
发现
最有希望的解决方案似乎是 Restic，因为...... 他的能力与运行速度的比例是最好的，但我们现在先不要急于得出一般性结论。
Borgbackup 基本上没有更差，但 zbackup 可能更好地被替换。 确实，zbackup 仍然可以用来确保 3-2-1 规则发挥作用。 例如，除了基于 (lib)rsync 的备份工具之外。
公告
备份第 5 部分：测试适用于 Linux 的 bacula 和 veeam 备份
备份第 6 部分：比较备份工具
备份第 7 部分：结论
发表者： 帕维尔·德姆科维奇
来源： habr.com