假设一个系统总是拥有主副本，而另一个系统总是拥有最近的副本（不到48小时），那么通过ssh镜像改进rsync的最佳技术是什么？
另外，还要做些什么来扩展这种方法来处理数十台机器推动这些变化？
如果：
您可以使用find -ctime或file -cnewer来创build自上次执行以来更改的文件的列表，并仅复制修改的文件（只是一个美化的差分推送）。
这对于多个主机来说很好地进行了翻译：只需在源文件上执行一个差异tar，然后在所有主机上解压。
它给你这样的东西：
find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt for HOST in host1 host2 host3 ... do cat /tmp/files_to_send.tar.gz | ssh $HOST "tar xpf -" done
脚本已经被改进了，但是你明白了。
假设你正在rsyncing的数据还没有被压缩，打开压缩（-z）可能会有助于传输速度，代价是任何一端的CPU。
如果你传输的文件很大，有很多变化，使用–inplace和–whole-file选项，我使用这些用于我的2Gb虚拟机映像，并且帮助了很多（主要是因为rsync协议没有做太多的工作与这些文件传递增量数据）。 尽pipe如此，我并不推荐这些选项。
使用–stats来查看使用rsync增量协议传输文件的效果。
另一个策略是使ssh和rsync更快。 如果您要通过可信networking（读取：private），则不需要encryption实际有效负载。 您可以使用HPN ssh 。 这个版本的ssh只encryptionauthentication。 另外，rsync版本3在构build文件列表时开始传输文件。 这当然是比rsync版本2节省了大量的时间。我不知道这是你在找什么，但我希望它有帮助。 另外，rsync支持以某种方式进行多播，但我不会假装理解如何。
在作为备份方法进行同步时，如果您备份了大量文件，则会遇到最大的问题。 Rsync可以处理大文件而不会出现问题，但是如果您备份的文件数量太大，您会注意到rsync无法在合理的时间内完成。 如果发生这种情况，您需要将备份分解成更小的部分，然后循环使用这些部分
find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/
或者下拉文件集以减less文件数量。
至于有几十台机器正在镜像这些变化，这取决于备份需要多么新鲜。 一种方法是将主服务器上的更改镜像到备份服务器上，然后让其他服务器通过初始备份服务器上的rsync守护程序从备份服务器上取下它们的更改，然后调度其他服务器以轻轻拉动不同的时间，或通过一个脚本使用无密码的SSH连接到每个服务器，并告诉他们拉一个新的备份副本，这将有助于防止压倒你的初始备份服务器 – 但是否你去那么多麻烦取决于还有多less台机器需要备份副本。
rsync有一个办法断开连接的副本。 换句话说，rsync可以（在概念上） 区分一个目录树并生成一个补丁文件，然后您可以将其应用于任何数量的与原始源相同的文件。
它要求你用--write-batch调用主和镜像的rsync; 它产生一个文件。 然后将该文件传输到任意数量的其他目标，然后使用--read-batch 将该批次应用于每个目标。
如果在主机的同一台机器上保留最后一个rsynced状态的本地副本（即现在的镜像的副本），则可以在主机上生成此“补丁”，而无需连接任何镜像：
主人：
rsync --write-batch=my-batch.rsync /master/data /current/mirror
添加你想要的其他选项。 这将做两件事情：
/current/mirror更改为反映/master/data my-batch.rsync 的二进制补丁文件 （或batch file）供以后使用。 将my-batch.rsync文件从主文件传输到所有的镜像文件，然后在镜像文件上应用补丁 ：
rsync --read-batch=my-batch.rsync /local/mirror
这种方法的好处：
--read-batch只是镜像本身的cpu / io密集型）