我需要将数百 GB 的数据从几个 Xen VM 现场备份到同一网络中的专用服务器上的某些可用存储中，并使用千兆位连接。数据主要是 MySQL 数据 - 我使用 Percona XtraDB Cluster - 使用 Xtrabackup 在服务器上本地备份，因此我猜这些数据应该是高度可压缩的。
目前，我正在使用 duplicity 0.6.08b 并使用密码加密（我没有使用密钥），因为我还将使用 duplicity 创建的备份卷 rsync 到一些异地存储。压缩级别目前为 6，volsize 为 250。备份需要超过一天的时间，这就是我寻找推荐的 duplicity 设置的原因，这些设置可以快速备份到本地网络共享存储，而不会占用太多空间。
任何想法？
答案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 受限，无论是读取还是写入，并且你可能受网络限制。您谈到了具有千兆以太网连接的专用备份存储服务器，但您没有提到该连接的性质。物理主机之间的备份网络连接是共享的还是专用的？（如果只有一个 VM 或 HV 一次推送备份数据，则将每个 HV 连接到备份服务器的单独物理网络是可以接受的。）
如果备份服务器的物理网络连接与其他网络流量共享，则可以迁移到专用连接架构。从中可以获得多少好处在很大程度上取决于数据压缩的位置以及您当前实际看到的冲突数量，但如果您只这样做而不做其他事情，那么您可能能够使网络吞吐量加倍，因此，如果您受到网络限制，则可以将备份时间缩短一半。
如果您的 I/O 受限于读取和/或写入，那么迁移到允许磁盘 I/O 分散到多个磁盘的镜像或条带设置可能有助于提高吞吐量；这将增加总磁盘总线吞吐量。当然，这也有其自身的缺点。根据您一次推送的数据量，添加更多快速地磁盘缓存到备份存储服务器可能也有帮助，但我怀疑如果你受到 I/O 限制，那么它就在读取方面，因为写入可能或多或少是连续的，在这种情况下添加缓存对你没有太大帮助。
您还可以考虑将虚拟机或 HV 上的文件系统和/或备份存储服务器上的文件系统迁移到磁盘写入时对数据进行实时压缩，或者启用此类压缩（如果支持）。这将耗费 CPU 时间，但会增加有效的磁盘数据传输率更高，因为在存储相同数量的用户空间数据的情况下，需要从物理磁盘移出和移入的数据更少。这在任何一种情况下是否会带来净收益基本上是掷硬币决定的，需要根据具体情况进行评估，但这肯定是可能性适用于 I/O 受限的情况，特别是当数据一开始就具有高度可压缩性时。即使数据只能压缩 20%（相当于压缩比为 1.25:1，对于自然语言文本等来说绝对可以实现；相比之下，使用 gzip-9 压缩的 ZFS 在互联网网站上的样本上为我提供了 1.20:1 的压缩率，包括图像)，同样的 50 MB/s 的盘片传输速率突然为您提供超过 60 MB/s 的有用数据传输率，假设主机 CPU 可以跟上压缩和解压缩的速度。请注意，加密数据应该压缩效果极差，因为它应该类似于随机噪声；如果您打算加密数据，通常会在加密之前进行压缩，在这种情况下，加密端的文件系统级压缩对您没有任何好处。