我们在内部网上有一个文件夹结构，其中包含大约80万个文件分成大约4000个文件夹。 我们需要将其同步到我们的DMZ中的一小群机器。 结构的深度很浅（从来没有超过两层深）。
大多数文件永远不会改变，每天有几千个更新的文件和1-2000个新文件。 这些数据是在源数据已被清除的地方维护的历史报告数据（即，这些数据是源数据足够老的归档和删除的最终报告）。 同步每天一次就足够了，因为它可以在合理的时间内发生。 报告是在一夜之间生成的，我们在早上同步第一件事情作为计划任务。
很显然，由于这样的文件很less有变化，我们可以从增量复制中受益匪浅。 我们已经尝试了Rsync，但是只需要8到12个小时就可以完成“build立文件列表”的操作。 很显然，我们正在快速超越rsync的能力（12小时的时间太长）。
我们一直在使用另一种名为RepliWeb的工具来同步这些结构，并且可以在大约45分钟内完成一次增量传输。 然而，看起来我们已经超出了限制，它开始看到文件显示为删除时，他们不（可能是一些内部内存结构已经用尽，我们不知道）。
有没有其他人遇到这种大型同步项目？ 有什么devise来处理像这样的同步大文件结构？
如果您可以信任文件系统上次修改的时间戳，则可以通过将Rsync与UNIX / Linux“查找”实用程序相结合来加快速度。 'find'可以组合所有在过去一天内显示上次修改时间的文件的列表，然后将这个缩短的文件/目录列表pipe理到Rsync。 这比使用Rsync比较发件人上的每个文件的元数据与远程服务器的速度要快得多。
简而言之，以下命令将在最近24小时内发生更改的文件和目录列表上执行Rsync：（Rsync不会检查任何其他文件/目录）。
find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/. 如果您不熟悉“find”命令，则会通过特定的目录子树进行recursion，查找符合您指定条件的文件和/或目录。 例如，这个命令：
find . -name '\.svn' -type d -ctime -0 -print
将从当前目录（“。”）开始，并遍历所有子目录，寻找：
它在标准输出上打印任何符合这些条件的完整path名（“-print”）。 选项'-name'，'-type'和'-ctime'被称为“testing”，选项'-print'被称为“动作”。 “查找”手册页包含testing和操作的完整列表。
如果你想要非常聪明，你可以使用'find'命令的'-cnewer'testing，而不是'-ctime'来使这个过程更容错和灵活。 '-cnewer'testing树中的每个文件/目录是否具有比某个参考文件更近的被修改的元数据。 使用'touch'在每次运行开始时，在'find … |之前创buildNEXT run的参考文件 rsync …“命令执行。 这是基本的实现：
#!/bin/sh curr_ref_file=`ls /var/run/last_rsync_run.*` next_ref_file="/var/run/last_rsync_run.$RANDOM" touch $next_ref_file find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/. rm -f $curr_ref_file
该脚本会自动知道上次运行的时间，只会传输自上次运行后修改的文件。 虽然这更复杂一些，但是由于停机或其他错误，它可以保护您免受24小时以上的工作错误。
试一试，它是专门devise来解决这个问题的，通过在每个服务器本地保存更改列表（build立文件列表），加快计算增量的时间以及之后通过线路发送的减less量。
如果您在rsync上使用-z开关，请尝试在没有它的情况下运行。 出于某种原因，我已经看到这个速度，甚至最初的枚举文件。
从没有压缩的rsync命令中取出-z，使“接收文件列表”变得更快，我们不得不传输大约500 GB。 在用-z开关花了一天之前。