本文将比较备份工具，但首先您应该了解它们从备份恢复数据的速度和效果如何。
为了便于比较，我们将考虑从完整备份恢复，特别是因为所有候选者都支持这种操作模式。 为简单起见，这些数字已被平均（多次运行的算术平均值）。 结果将汇总在表格中，其中还包含有关功能的信息：Web 界面的存在、设置和操作的简易性、自动化的能力、各种附加功能的存在（例如，检查数据完整性） ， ETC。 这些图表将显示将使用数据的服务器（而不是用于存储备份副本的服务器）上的负载。
数据恢复
rsync 和 tar 将用作参考点，因为 用于制作备份副本的简单脚本。
Rsync的 在 4 分 28 秒内处理完测试数据集，显示
这样的负载
恢复过程遇到了备份存储服务器磁盘子系统的限制（锯齿图）。 您还可以清楚地看到一个内核的加载，没有任何问题（低 iowait 和 softirq - 磁盘和网络分别没有问题）。 由于另外两个程序，即 rdiff-backup 和 rsnapshot，基于 rsync 并且还提供常规 rsync 作为恢复工具，因此它们将具有大致相同的负载配置文件和备份恢复时间。
焦油 做得更快一点
2分43秒：
由于软中断增加，系统总负载平均增加了 20%，即网络子系统运行期间的开销成本增加。
如果进一步压缩存档，恢复时间将增加到 3 分 19 秒。
主服务器上有这样的负载（在主服务器一侧解压）：
解压过程会占用两个处理器核心，因为有两个进程正在运行。 总的来说，这是预期的结果。 此外，在带有备份的服务器端运行 gzip 时获得了可比较的结果（3 分 20 秒）；主服务器上的负载配置文件与在没有 gzip 压缩器的情况下运行 tar 非常相似（参见上图）。
В rdiff-备份 您可以使用常规 rsync 同步上次所做的备份（结果将类似），但仍需要使用 rdiff-backup 程序恢复较旧的备份，该程序在 17 分 17 秒内完成了恢复，显示
这个负载：
也许这是有意的，至少是为了限制作者的速度 。 恢复备份副本的过程本身只需要不到一个核心的一半，并且通过 rsync 在磁盘和网络上具有按比例可比的性能（即慢 2-5 倍）。
快照 对于恢复，它建议使用常规 rsync，因此其结果将相似。 总的来说，结果是这样的。
打嗝 我在 7 分 2 秒内完成了恢复备份的任务
以此负载：
它运行得相当快，而且至少比纯 rsync 方便得多：你不需要记住任何标志、简单直观的 cli 界面、对多个副本的内置支持 - 尽管它慢了两倍。 如果您需要从上次备份中恢复数据，可以使用 rsync，但有一些注意事项。
该程序显示出大致相同的速度和负载 备份电脑 启用 rsync 传输模式时，部署备份
7分42秒：
但在数据传输模式下，BackupPC 处理 tar 的速度较慢：在 12 分 15 秒内，处理器负载普遍较低
一倍半：
表里不一 不加密的结果稍好一些，在 10 分 58 秒内恢复备份。 如果使用 gpg 激活加密，恢复时间将增加到 15 分 3 秒。 此外，在创建用于存储副本的存储库时，您可以指定拆分传入数据流时将使用的存档大小。 一般来说，在常规硬盘上，同样由于是单线程运行模式，并没有太大的区别。 使用混合存储时，它可能会出现不同的块大小。 恢复期间主服务器的负载如下：
没有加密
带加密
重复的 显示出类似的恢复速度，在 13 分 45 秒内完成。 又花了大约5分钟来检查恢复数据的正确性（总共大约19分钟）。 负载为
相当高：
当内部启用 aes 加密时，恢复时间为 21 分 40 秒，恢复期间 CPU 利用率达到最大（两个核心！）； 检查数据时，只有一个线程处于活动状态，占用一个处理器核心。 恢复后检查数据同样花费了 5 分钟（总共将近 27 分钟）。
导致
使用外部 gpg 程序进行加密时，duplicati 的恢复速度要快一些，但总的来说，与之前模式的差异很小。 运行时间16分30秒，数据验证6分钟。 负载为
如下：
AMANDA，使用 tar，在 2 分 49 秒内完成了它，原则上，这与常规 tar 非常接近。 原则上对系统进行负载
相同：
使用恢复备份时 备份 获得了以下结果：
加密、lzma 压缩
片长11分8秒
AES 加密、lzma 压缩
14运行时间分钟
AES 加密、lzo 压缩
片长6分19秒
总的来说，还不错。 这完全取决于备份服务器上处理器的速度，这可以从不同压缩器下程序的运行时间清楚地看出。 在备份服务器端，启动了常规tar，因此如果与它相比，恢复速度要慢3倍。 可能值得检查多线程模式（具有两个以上线程）下的操作。
博格备份 在未加密模式下，它比 tar 慢一点，需要 2 分 45 秒，但是，与 tar 不同的是，它可以对存储库进行重复数据删除。 负载结果是
以下内容：
如果启用基于 blake 的加密，备份恢复速度会稍慢。 该模式下恢复时间为3分19秒，负载消失
像这样：
AES加密稍慢，恢复时间为3分23秒，负载特别大
没有改变：
由于Borg可以在多线程模式下工作，因此处理器负载最大，当激活附加功能时，运行时间只会增加。 显然，以与 zbackup 类似的方式探索多线程是值得的。
雷斯蒂奇 应对恢复速度稍慢一些，手术时间为4分28秒。 负载看起来像
如下：
显然，恢复过程是在多个线程中进行的，但效率不如BorgBackup高，但在时间上与常规rsync相当。
同 备份 8分19秒即可恢复数据，负载为
如下：
负载还是不是很高，甚至比tar还低。 有的地方有突发，但不超过一个核心的负载。
比较标准的选择和理由
正如之前的一篇文章所述，备份系统必须满足以下条件：
- 使用方便
- 普遍
- 稳定性
- 迅速
值得更详细地单独考虑每一点。
操作方便
最好有一个按钮“做好一切”，但如果你回到真实的程序，最方便的将是一些熟悉的标准操作原理。
如果大多数用户不必记住一堆 cli 密钥、通过 web 或 tui 配置一堆不同的、通常晦涩难懂的选项，或者设置有关不成功操作的通知，那么他们很可能会过得更好。 这还包括将备份解决方案轻松“适应”现有基础设施的能力，以及备份过程的自动化。 还可以使用包管理器或通过一两个命令（例如“下载并解压”）进行安装。 curl ссылка | sudo bash - 一个复杂的方法，因为您需要检查通过链接到达的内容。
例如，在考虑的候选方案中，一个简单的解决方案是 burp、rdiff-backup 和 Restic，它们具有针对不同操作模式的助记键。 稍微复杂一点的是博格和口是心非。 最困难的是阿曼达。 其余的在易用性方面处于中间位置。 无论如何，如果您需要超过 30 秒的时间来阅读用户手册，或者您需要访问 Google 或其他搜索引擎，并且还要滚动浏览一长串帮助信息，那么无论如何，做出决定都是困难的。
一些被考虑的候选人能够通过电子邮件jabber自动发送消息，而其他候选人则依赖于系统中配置的警报。 此外，大多数复杂的解决方案都没有完全明显的警报设置。 无论如何，如果备份程序产生非零返回代码，系统服务将正确理解该代码以执行定期任务（消息将发送给系统管理员或直接发送给监控） - 情况很简单。 但是，如果无法配置不在备份服务器上运行的备份系统，则说明该问题的明显方式是复杂性已经过高。 无论如何，仅向 Web 界面或日志发出警告和其他消息是一种不好的做法，因为它们通常会被忽略。
至于自动化，一个简单的程序可以读取设置其操作模式的环境变量，或者它有一个开发的 cli，可以完全复制通过 Web 界面工作时的行为。 这还包括持续运营的可能性、扩张机会的可用性等。
普遍
部分呼应前一小节有关自动化的内容，将备份过程“适应”现有基础设施应该不是一个特殊的问题。
值得注意的是，使用非标准端口（当然，除了 Web 界面）进行工作、以非标准方式实施加密、使用非标准协议交换数据都是非标准的标志。 - 通用解决方案。 在大多数情况下，所有候选人都以某种方式拥有它们，原因很明显：简单性和多功能性通常不能同时存在。 作为一个例外 - 打嗝，还有其他的。
作为标志 - 使用常规 ssh 工作的能力。
工作速度
最有争议、最有争议的一点。 一方面，我们启动了该流程，它尽可能快地运行并且不干扰主要任务。 另一方面，备份期间流量和处理器负载会激增。 还值得注意的是，最快的复印程序通常在对用户重要的功能方面是最差的。 再次：如果为了获得一个带有密码的不幸的几十字节大小的文本文件，并因此而导致整个服务成本（是的，是的，我知道备份过程通常不应该归咎于这里），并且您需要按顺序重新读取存储库中的所有文件或扩展整个存档 - 备份系统永远不会很快。 另一个经常成为绊脚石的点是从存档部署备份的速度。 对于那些可以简单地将文件复制或移动到所需位置而无需太多操作（例如 rsync）的人来说，这里有一个明显的优势，但大多数情况下，必须根据经验以组织方式解决问题：通过测量备份恢复时间并公开告知用户此事。
稳定性
应该这样理解：一方面必须能够以任何方式将备份副本部署回来，另一方面必须能够抵抗各种问题：网络中断、磁盘故障、删除部分文件存储库。
备份工具比较
副本创建时间
复制恢复时间
简易安装
设置简单
使用简单
简单的自动化
您需要客户端服务器吗？
检查存储库的完整性
差异副本
通过管道工作
普遍
独立
存储库透明度
加密
压缩
重复数据删除
网页界面
填充至云端
Windows 支持
标记
Rsync的
4m15s
4m28s
是的
没有
没有
没有
是的
没有
没有
是的
没有
是的
是的
没有
没有
没有
没有
没有
是的
6
焦油
纯
3m12s
2m43s
是的
没有
没有
没有
没有
没有
是的
是的
没有
是的
没有
没有
没有
没有
没有
没有
是的
8,5
GZIP
9m37s
3m19s
是的
Rdiff备份
16m26s
17m17s
是的
是的
是的
是的
是的
没有
是的
没有
是的
没有
是的
没有
是的
是的
是的
没有
是的
11
快照
4m19s
4m28s
是的
是的
是的
是的
没有
没有
是的
没有
是的
没有
是的
没有
没有
是的
是的
没有
是的
12,5
打嗝
11m9s
7m2s
是的
没有
是的
是的
是的
是的
是的
没有
是的
是的
没有
没有
是的
没有
是的
没有
是的
10,5
表里不一
没有加密
16m48s
10m58s
是的
是的
没有
是的
没有
是的
是的
没有
没有
是的
没有
是的
是的
没有
是的
没有
是的
11
GPG
17m27s
15m3s
重复的
没有加密
20m28s
13m45s
没有
是的
没有
没有
没有
是的
是的
没有
没有
是的
没有
是的
是的
是的
是的
是的
是的
11
AES
29m41s
21m40s
GPG
26m19s
16m30s
备份
没有加密
40m3s
11m8s
是的
是的
没有
没有
没有
是的
是的
是的
没有
是的
没有
是的
是的
是的
没有
没有
没有
10
AES
42m0s
14m1s
AES+LZO
18m9s
6m19s
博格备份
没有加密
4m7s
2m45s
是的
是的
是的
是的
是的
是的
是的
是的
是的
是的
没有
是的
是的
是的
是的
没有
是的
16
AES
4m58s
3m23s
blake2
4m39s
3m19s
雷斯蒂奇
5m38s
4m28s
是的
是的
是的
是的
没有
是的
是的
是的
是的
是的
没有
是的
没有
是的
没有
是的
是的
15,5
备份
8m21s
8m19s
是的
是的
是的
没有
是的
没有
是的
没有
是的
是的
没有
是的
是的
是的
是的
没有
是的
12
阿曼达
9m3s
2m49s
是的
没有
没有
是的
是的
是的
是的
没有
是的
是的
是的
是的
是的
没有
是的
是的
是的
13
备份电脑
rsync的
12m22s
7m42s
是的
没有
是的
是的
是的
是的
是的
没有
是的
没有
没有
是的
是的
没有
是的
没有
是的
10,5
焦油
12m34s
12m15s
表图例：
- 绿色，操作时间少于五分钟，或回答“是”（“需要客户端服务器吗？”栏除外），1分
- 黄色，操作时间0.5至XNUMX分钟，XNUMX分
- 红色，工作时间超过十分钟，或回答“否”（“是否需要客户端服务器？”一栏除外），0分
根据上表，最简单、最快、同时方便且功能强大的备份工具是BorgBackup。 雷斯蒂奇位居第二，其余被考虑的候选人排名大致相同，最后相差一两分。
我感谢所有读完本系列文章的人，我邀请您讨论这些选项并提供您自己的选项（如果有）。 随着讨论的进展，该表可能会扩大。
该系列的成果将是最后一篇文章，其中将尝试开发一种理想、快速且可管理的备份工具，使您可以在最短的时间内部署回副本，同时又方便又容易配置和维护。
公告
备份第 6 部分：比较备份工具
备份第 7 部分：结论
来源： habr.com