我有 8 台设备。一台是“集线器”，另外 7 台是“远程设备”。每台设备都位于不同的物理位置，我连接的是集线器和辐射型 VPN 配置，所有远程站点都可以访问集线器，但不能相互访问。我的同步中有超过 100,000 个文件/文件夹。
所有 RSYNC 均从 Hub (SITE0) 运行
注意：已使用 %SITE#% 作为实际单元 IP 的占位符。我刚刚删除了它们，因为它们对此是不需要的。我实际上在实际脚本中有一个 IP。
我已设置 Rsync 来执行以下操作：
MWF = 星期一星期三星期五。（TH = 星期二星期四）我使用以下命令将 Site1/Site2/Site3/Site4/Site5/Site6/Site7 同步到“Hub”：（其中%站点 N%= 实际单位的 IP)
rsync -vzar --size-only --no-g --no-times rsync://*%SiteN%*/Image/* /data/Image >> /data/Logs/$foo
（这包含>> /data/Logs/$foo 我已将其写入日志以供审查）
所有这些似乎总是有效，即新文件由“HUB”接收。
INBOUND 完成后，我使用此脚本将出站数据发送到 3 个单元（Site1/Site2/Site3）。
rsync -vzar --size-only --no-g --no-times --exclude "SubFolder1/" --exclude "Subfolder2/" /data/Image/* rsync://*%SITEN%*/Image >> /data/Logs/$foo
这就是我的问题所在。我的日志中出现以下内容。
呼叫 HUB 出站
rsync Started HUB->Site3 Thu Mar 28 05:32:00 EDT 2019
sending incremental file list
rsync Stopped HUB->Sit3 Thu Mar 28 05:53:39 EDT 2019
呼叫站点 1 出站
rsync Started Hub->Site1 Thu Mar 28 05:53:39 EDT 2019
sending incremental file list
rsync Stopped Hub->Site1 Thu Mar 28 06:08:41 EDT 2019
呼叫站点 2 出站
rsync Started HUB->Site2 Thu Mar 28 06:08:41 EDT 2019
sending incremental file list
rsync Stopped HUB->Site2 Thu Mar 28 06:23:46 EDT 2019
======= 但是如果我在 AM 手动运行 OUTBOUND 脚本，它就会成功运行。
我做错了什么？Rsync 是否认为它不需要更新更改，因为我之前做了 INBOUND？我以前也这么想过，这就是为什么我将脚本分解为由“主”调用的唯一脚本（见下文），希望如果 RSYNC 和内存出现问题。
有趣的是，在 TH 上我运行了一组不同的脚本，这些脚本反转了 MWF（Site1/Site2/Site3 入站和所有出站），并且我得到了与 Site1/Site2/Site3 相同的结果。
我发现它们之间的主要区别可能是 RSYNC 版本。在 HUB 和 Site1/Site2/Site3 上，Rsycn 版本为 3.1.3，在其他站点上为 3.0.9
任何帮助将不胜感激。
完整披露：我有一个“主脚本”，它调用单个脚本来运行所需的 Rsync。这样做是为了更容易阅读脚本。在我执行此操作之前，我遇到了这个问题，是我的调用脚本创建了看起来像“调用 Site2 出站”的行，它们调用的脚本有日志行，给出看起来像这样的行：“rsync Started HUB->Site2 Thu Mar 28 06:08:41 EDT 2019”
例如：主脚本：（已删除并缩短）
#!/bin/sh
foo=rsync-`date +%m%d%Y`.log
echo 'Syncing remote sites to main site Started '`date` >> /data/Logs/$foo
echo '------------------------------------------'>> /data/Logs/$foo
echo 'Calling Site1 Inbound' >> /data/Logs/$foo
/bin/sh /root/SiteScripts/Site1In.sh $foo
echo ' '>> /data/Logs/$foo
echo 'Calling Site2 Inbound' >> /data/Logs/$foo
/bin/sh /root/SiteScripts/Site2In.sh $foo
echo ' '>> /data/Logs/$foo
.
. Rest of sites
.
echo ' '>> /data/Logs/$foo
echo 'Syncing remote sites to main site Completed '`date` >> /data/Logs/$foo
.
.
.
echo 'Syncing main site to remote sites Started'`date` >> /data/Logs/$foo
echo '------------------------------------------'>> /data/Logs/$foo
echo 'Calling Site1 Outbound' >> /data/Logs/$foo
/bin/sh /root/SiteScripts/Site1Out.sh $foo
echo ' '>> /data/Logs/$foo
echo 'Calling Site2 Outbound' >> /data/Logs/$foo
/bin/sh /root/SiteScripts/Site2Out.sh $foo
echo ' '>> /data/Logs/$foo
echo 'Calling Site3 Outbound' >> /data/Logs/$foo
/bin/sh /root/SiteScripts/Site3Out.sh $foo
echo ' '>> /data/Logs/$foo
echo 'Syncing main site to remote sites Completed'`date` >> /data/Logs/$foo
从上面调用的脚本示例（对于入站仅进行反向操作）
#!/bin/sh
echo 'rsync Started Hub->Site1 '`date` >> /data/Logs/$1
rsync -vzar --size-only --no-g --no-times --exclude "Subfolder/" --exclude "SubFolder/" /data/OMSImage/* rsync://%Site1%/Image >> /data/Logs/$1
echo 'rsync Stopped Hub->Site1 '`date` >> /data/Logs/$1
=========================================================================== 4.2.2019 更新。
我昨晚再次运行了同步，现在增加了一个“v”（-vvzari）这是我得到的完整输出。
Calling Site1 Outbound (.86)
rsync Started Hub -> Site1 Tue Apr 2 04:25:12 EDT 2019
opening tcp connection to 192.168.86.61 port 873
sending daemon args: --server -vvloDprze.iLsfxC "--log-format=%i" --size-only . IMAGES/ (6 args)
sending incremental file list
[sender] hiding directory 3d-Volumes because of pattern FOLDER1/
[sender] hiding directory Romexis3d because of pattern FOLDER2/
[sender] expand file_list pointer array to 524288 bytes, did move
[sender] expand file_list pointer array to 1048576 bytes, did move
[sender] expand file_list pointer array to 2097152 bytes, did move
[sender] expand file_list pointer array to 1439480 bytes, did move
rsync Stopped Hub -> Site1 Tue Apr 2 04:40:19 EDT 2019
在我看来，RSYNC 已经枚举了路径，并且没有看到任何变化，但我确信有 100 个新文件。我是否忽略了 RSYNC 的工作方式？我只在两端都具有 RSYNC 3.1 的单元中遇到此问题。
自从我发布原始帖子以来，我已经部署了第四台新 NAS 设备，并且遇到了与此完全相同的问题。其余设备都是旧的（5 年以上），我没有遇到任何问题。
我现在想知道是否需要重新启动 HUB 或 Spokes 上的 RSYNC 服务才能实现这一点？
今晚我将添加第三个“v”......
- 我已经创建了一个新的脚本，并在上午从 CRON 运行，它只对故障设备进行出站处理，并且按预期运行。
2019 年 5 月 4 日更新。
添加额外的“v”后，我能够进行更多故障排除。我添加了一个“额外”的 NAS 设备。请记住，我有“HUB”，它可以毫无问题地“拉”所有远程站点。它只是不会“推送”到我的所有“较新”的 NAS 设备。
我已经将第二个 NAS（将硬件保存为名为 SPARENAS 的 HUB）添加到 HUB 的物理位置。
我进行了以下同步以测试全部输入到“HUB”，“HUB”发送到这个新的 NAS（SpareNAS），SpareNAS 发送到“远程”NAS 设备。
有趣的部分就在这里。
HUB 到备件 = 没有问题。备件到遥控器 = 存在相同问题。
这表明问题出在“远程” NAS 设备上。
我将进行更多测试，下一步将使用“sshpass”来告诉出现故障的“远程”NAS 设备在成功“拉出”后重新启动 Rsync。
如果这不起作用，我将在成功“PULL”后使用相同的方法重新启动远程 nas 设备。
同步需要几个小时，因此在我再次尝试访问它们之前，它们将有足够的时间启动。
我认为这至少证明了“推送”错误不在我的“HUB”上。
答案1
我相信我找到了这个问题的答案。从其他研究来看，我认为问题出在我使用的设备和固件上。我使用的是 NETGEAR ReadyNas 设备。有问题的设备使用的是固件 6.9.5。我还遇到过 SMB 访问速度慢的其他问题，我发现所有 6.9.x 版本的 ReadyNas 固件都存在 SMB 速度慢的问题，以及 Rsync（当用作 GUI 备份时）[NETGEAR 论坛上有大量关于此问题的帖子]。
NETGEAR 论坛 - SMB 速度慢 NETGEAR 论坛 - 6.9.x 之后 SMB 速度变慢
我没有以那种方式使用 RSYNC，但似乎我遇到了与其他人类似的问题。
因此，尽管我的脚本确实需要调整，并且运行得更好更快，并且不会像一个月前那样破坏权限，但我仍然遇到问题，但我认为我无法修复它们。我必须等待 NETGEAR 修复它们......