如何加速我的 Duplicity 备份？

Question

我需要使用千兆位连接将数百 GB 的现场备份从几个 Xen VM 备份到同一网络中专用服务器上的一些可用存储。数据主要是 MySQL 数据——我使用 Percona XtraDB Cluster——使用 Xtrabackup 在服务器上本地备份，所以我想这些数据应该是高度可压缩的。

目前我正在使用带有密码加密的 duplicity 0.6.08b（我没有使用密钥），因为我还将使用 duplicity 创建的备份卷同步到一些异地存储。当前压缩级别为 6，volsize 为 250。备份需要一天以上的时间，这就是我正在寻找推荐的重复设置的原因，该设置将导致快速备份到本地网络共享存储而不会占用太多空间。

任何的想法？

Answer 1

您在评论中说您看到这些备份的吞吐量约为 50 MB/s。

50 MB/s大约是您对单个旋转锈盘的半随机磁盘吞吐量的预期数量级（即，未镜像或条带化的 RAID 允许读取跨磁盘分布以增加吞吐量）。请注意，某些 RAID 配置甚至将最佳情况下的吞吐量有效地限制为最慢驱动器的吞吐量。是的，许多 HDD 的额定值高达 ~200 MB/s，但请记住，这些数字是最佳情况下的顺序访问数。50 MB/s 也是大约 400 Mbit/s，加上对 IP 开销等的一些捏造，在网络线路上会达到 500-600 Mbit/s，所以当你没有仅仅用它来饱和千兆链路时，你越来越接近可能发生碰撞的区域。

在备份运行时，您没有给出任何 CPU 利用率的数字，只是说您“有三个虚拟机管理程序，每个管理程序都有一堆虚拟机，或多或少很忙”。但是复制数据和压缩数据并不是非常占用 CPU，而且如果在备份运行时您有任何可用的 CPU 时间，那么您就不会受到 CPU 的限制。真正回答这个问题的唯一方法是弄清楚是什么因素限制了吞吐量，然后将精力集中在那里。

我的猜测是您受 I/O 限制，无论是读取还是写入，而且您可能受网络限制。您谈论的是具有千兆以太网连接的专用备份存储服务器，但您并未提及该连接的性质。物理主机之间的 for-backups 网络连接是共享的还是专用的？（如果在任何时间只有一个 VM 或 HV 推送备份数据，则可以接受将每个 HV 连接到备份服务器的单独物理网络。）

如果与备份服务器的物理网络连接与其他网络流量共享，您可以转向专用连接架构。您从中获得多少好处在很大程度上取决于数据压缩的位置以及您当前真正看到的冲突数量，但是如果您这样做而没有其他任何事情，您可能能够使网络吞吐量翻倍，因此，如果您是网络绑定，将备份时间减少一半。

如果您在读取和/或写入时受到 I/O 限制，那么转移到允许磁盘 I/O 分布到多个磁盘的镜像或条带设置可能有助于提高吞吐量；它会增加总磁盘总线吞吐量。当然，这也有其自身的缺点。根据您一次推送的数据量，向备份存储服务器添加更快的磁盘缓存也可能有所帮助，但我怀疑如果您受 I/O 限制，它在读取端，因为写入可能是或多或少是顺序的，在这种情况下，添加缓存对您没有多大帮助。

您还可以考虑迁移到 VM 或 HV 和/或备份存储服务器上的文件系统，该系统对写入磁盘的数据进行即时压缩，或者在支持的情况下启用此类压缩. 这将花费 CPU 时间，但会增加有效的磁盘数据传输速率，因为对于存储的相同数量的用户空间数据，必须将更少的数据移入和移出物理盘片。在任何一种情况下这是否会成为净收益基本上都是抛硬币，需要根据具体情况进行评估，但这肯定是一种可能性对于 I/O 受限的情况，特别是如果数据一开始就高度可压缩。即使数据只能压缩 20%（相当于 1.25:1 的压缩率，并且绝对可以通过例如自然语言文本实现；为了比较，使用 gzip-9 压缩的 ZFS 对我的样本进行了 1.20:1 的压缩Internet 网站，包括图像），假设主机 CPU 可以跟上压缩和解压缩的速度，那些相同的 50 MB/s 盘片传输速率突然为您提供超过 60 MB/s 的有用数据传输。请注意，加密数据应该是压缩得非常差，因为它应该类似于随机噪声；如果您打算加密数据，您通常会在加密之前进行压缩，在这种情况下，加密端的文件系统级压缩对您没有任何好处。