本评论继续
UrBackup 评论。
应参加者要求
在全备份模式下,得到如下结果:
营业时间:
首先开始
第二轮
第三次发射
第一次测试
8m20s
8m19s
8m24s
第二次测试
8m30s
8m34s
8m20s
第三次测试
8m10s
8m14s
8m12s
增量备份模式下:
营业时间:
首先开始
第二轮
第三次发射
第一次测试
8m10s
8m10s
8m12s
第二次测试
3m50s
4m12s
3m34s
第三次测试
2m50s
2m35s
2m38s
两种情况下的存储库大小约为 14 GB,这表明重复数据删除在服务器端正常工作。 还应该注意的是,服务器和客户端上的备份创建时间之间存在差异,这从图表中非常明显可见,并且是一个非常令人愉快的好处,因为 Web 界面显示了备份过程的运行时间服务器端不考虑
客户的情况。 一般来说,完整副本和增量副本的图表是无法区分的。 唯一的区别可能是服务器端的处理方式。 我还对冗余系统上的低处理器负载感到满意。
备份电脑评论
应参加者要求
使用rsync创建全量备份的方式,得到如下结果:
首先开始
第二轮
第三次发射
第一次测试
12m25s
12m14s
12m27s
第二次测试
7m41s
7m44s
7m35s
第三次测试
10m11s
10m0s
9m54s
如果您使用完整备份和 tar:
首先开始
第二轮
第三次发射
第一次测试
12m41s
12m25s
12m45s
第二次测试
12m35s
12m45s
12m14s
第三次测试
12m43s
12m25s
12m5s
在增量备份模式下,我不得不放弃 tar,因为备份不是使用这些设置创建的。
使用rsync创建增量备份的结果是:
首先开始
第二轮
第三次发射
第一次测试
11m55s
11m50s
12m25s
第二次测试
2m42s
2m50s
2m30s
第三次测试
6m00s
5m35s
5m30s
一般来说,rsync 具有轻微的速度优势;rsync 与网络的配合也更经济。 使用 tar 作为备份程序时,CPU 使用率会降低,这可能会部分抵消这一影响。 rsync 的另一个优点是它可以使用增量副本。 创建完整备份时存储库的大小是相同的,在增量副本的情况下为 16 GB - 每次运行 14 GB,这意味着重复数据删除有效。
阿曼达评论
应参加者要求
使用 tar 作为归档器并启用压缩的测试运行结果如下:
首先开始
第二轮
第三次发射
第一次测试
9m5s
8m59s
9m6s
第二次测试
0m5s
0m5s
0m5s
第三次测试
2m40s
2m47s
2m45s
该方案满载一个处理器核心,但由于备份存储服务器端磁盘IOPS有限,无法实现较高的数据传输速度。 一般来说,设置比其他参与者稍微麻烦一些,因为该程序的作者不使用 ssh 作为传输,而是使用密钥实现类似的方案,创建和维护成熟的 CA。 可以广泛地限制客户端和备份服务器:例如,如果它们不能完全信任彼此,那么您可以作为一个选项,通过将相应变量的值设置为零来阻止服务器启动备份恢复设置文件。 可以连接 Web 界面进行管理,但一般来说,配置的系统可以使用小型 bash 脚本(或 SCM,例如 ansible)完全自动化。 有一个用于设置存储的有点不简单的系统,这显然是由于支持各种用于存储数据的设备(LTO 盒式磁带、硬盘驱动器等)的广泛列表。 还值得注意的是,在本文讨论的所有程序中,AMANDA 是唯一能够检测目录重命名的程序。 一次运行的存储库大小为 13 GB。
公告
备份第 6 部分:比较备份工具
备份第 7 部分:结论
来源: habr.com