设置：
我希望每周备份 1 TB产品到备份服务器。服务器在 Linux Ubuntu-1004-lucid-64-minimal 2.6.32-35-server 下运行。
有 BACKUP 服务器（我在这里启动 rsync 程序）和带有数据的 PROD 服务器。
我当前使用的命令如下：
time rsync -r --delete [email protected]:/home/myuser/data .
问题：
问题是：PROD 服务器几乎无响应。在 PROD 服务器上运行的 Web 应用程序几乎要崩溃了。
更新：当前有效的解决方案
经过一些反馈后，我现在使用此命令来备份 1TB 的数据，并且它绝对运行良好：
rsync -r --delete --rsync-path "ionice -c 3 nice rsync" --bwlimit=30000 [email protected]:/home/myuser/data .
请注意，我已将带宽限制设置为 30 Mbps，因为 PROD 和备份服务器之间的连接速度为 100 Mbps，并且该带宽与我的 Web 应用程序的生产流量共享。
请注意，我在 BACKUP 服务器上执行此命令，因此我使用 rsync-path 选项来对远程服务器（PROD）上的进程进行 nice 和 ionice。
我最初的问题以及可能的解决方案
我如何控制 rsync（在 BACKUP 服务器上启动）的影响？
您将如何解决这个问题？
我的小研究发现了以下可能性：
以某种方式执行 rsync，以便 1TB 分块同步？例如
rsync /source/[0-9]* [email protected]:/source_backup rsync /source/[a-h]* [email protected]:/source_backup/ rsync /source/[i-p]* [email protected]:/source_backup/ rsync /source/[q-z]* [email protected]:/source_backup/使用选项限制带宽是否有帮助
--bwlimit=10000是否有可能通过某种方式来改善远程机器上的进程？例如
nice -n19 backup.sh
我不知道PROD机器上的流程是否也会很好？
欢迎任何帮助和想法。
答案1
我喜欢 rsync。但它仍然有一个设计缺陷，即它想要“加载”它正在扫描的目录树中每个文件的列表。以前，它曾经等待整个树加载完毕后才开始将列表传输给对等方。这个问题现在似乎已经解决了，它比以前更好地并行处理事情。然而，它仍然想要加载整个列表。影响与文件数量成正比，而不是数据大小。
虽然这一切都需要 I/O 来从所有分散的目录中加载列表，但这种影响无法通过拆分来改变，因为仍然必须扫描所有内容。但是，我发现当列表在一次运行中非常大时，影响会更大，因为它占用了大量的虚拟内存，并且对将该列表保持在实际 RAM 中提出了很高的要求，因为它对列表的操作方式。这种内存需求迫使其他进程进行交换。
正如您所建议的那样，分解目录树将有助于分解内存需求的影响。
如果您的数据使用硬链接文件，那么这也有一个缺点。如果您有硬链接文件并且它们在目录树分解成的部分之间是硬链接的，那么您将失去 rsync 在目标（备份服务器）上维护相同硬链接的能力。这将导致目标上空间的使用量增加，并且根据您使用硬链接的目的，可能会破坏数据的工作原理（例如，期望一个文件的更改在另一个文件中可见）。如果您没有明确使用硬链接，那么这方面对您来说不是问题。
计算您拆分的每个部分中的文件数量。尽量保持平衡。限制的最佳数量取决于您可用的物理 RAM 以及其他进程对该 RAM 的需求。
带宽和良好的设置不太可能对内存问题有太大帮助。如果还存在网络容量问题，带宽仍然会有所帮助。