rsync同步失败后需外层控制重试，典型做法是用shell循环结合退出码判断与sleep：for i in {1..3}; do rsync -avz --delete /src/ user@host:/dst/ && break || sleep 5; done，成功则跳出，失败则等待5秒后重试，最多3次。
rsync 同步失败后怎么加重试？
rsync 本身不内置重试逻辑，rsync 命令执行完就退出，失败不会自动重试。真要重试，得靠外层控制——最常用、最可靠的是用 shell 循环 + sleep + 退出码判断。
典型写法：
for i in {1..3}; do
rsync -avz --delete /src/ user@host:/dst/ && break || sleep 5
done
要点：
-
&& break表示成功就跳出循环，不用再试 -
|| sleep 5表示失败后等 5 秒再下一轮，避免密集打爆远端或触发限流 - 最大重试次数由
{1..3}控制，可按需改成{1..5} - 别用
while true无限重试——网络抖动时可能卡死或填满日志
lsyncd 怎么配失败重试？
lsyncd 的重试不是靠参数开关，而是靠底层 rsync 的 exit code 和配置中的 maxProcesses、delay 配合实现的“软重试”。它本身不重试单次失败的 rsync，但会持续监听变更，只要文件再次被修改（或未完成写入后再次触发事件），就会重新同步。
真正起作用的其实是这三项：
-
delay = 5：缓存变更 5 秒再发 rsync，避开编辑器刚打开就同步的“半截文件”问题 -
maxProcesses = 1：防止并发 rsync 冲突，保证同一路径串行处理，失败后下次变更仍能触发新任务 -
rsync = { ... }块里加archive = true和compress = true，减少传输中断概率；不要加--partial（lsyncd 默认不传该参数，加了反而干扰）
注意：lsyncd 不会为一次 rsync 失败单独补发，它只响应 inotify 新事件。所以“重试感”来自变更的自然再触发，不是传统意义的 retry。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
systemd service 里怎么让 rsync 失败自动重启？
如果你把 rsync 封装成 systemd service（比如定时同步或 oneshot 任务），可以用 Restart= 策略让它失败后重启，但必须配合 RestartSec= 和 StartLimitIntervalSec= 防止雪崩。
关键配置项：
-
Restart=on-failure：仅当 rsync 进程 exit code 非 0 时重启（rsync成功返回 0，失败常见为 23、24） -
RestartSec=10：每次重启前等 10 秒，留出网络恢复时间 -
StartLimitIntervalSec=60和StartLimitBurst=3：60 秒内最多启动 3 次，超限后 service 进入 failed 状态，需手动干预 - 务必加
ExecStartPre=/bin/sleep 2：避免服务启动太快，远端 ssh 或 rsyncd 还没 ready
漏掉 StartLimit* 容易导致系统反复 fork rsync 进程，最终耗尽内存或触发 systemd 自保机制停服。
为什么 rsync --timeout 不等于重试？
--timeout=30 是设置 rsync 单次连接或传输空闲超时（单位秒），不是重试次数。它只中断当前运行的 rsync 进程，不会自动拉起下一次。
常见误解：
- 以为加了
--timeout就能“自动重试”，其实只是让卡住的 rsync 快点退出，方便外层脚本捕获失败 - 和
--contimeout混用：后者只控制连接建立阶段超时，对已连上的数据传输无效 - 在高延迟链路上，
--timeout设太小（如 5）会导致频繁误判失败；设太大（如 300）又拖慢故障响应
真正要重试，还是得回到 shell 循环或 systemd 的 Restart=，--timeout 只是让失败更快暴露出来。
