rsync中源路径末尾加/表示同步目录内容，不加则同步目录本身；目标路径加/更安全，可避免意外嵌套。例如rsync -a /data/app/ /backup/同步内容，而rsync -a /data/app /backup/会创建/app子目录。
rsync 命令里斜杠 / 的位置决定同步行为
很多人同步失败，不是权限或网络问题，而是源路径或目标路径末尾有没有 / 搞错了。这直接决定是「把整个目录搬过去」还是「只搬里面的内容」。
比如想把 /data/app/ 里的所有文件同步到 /backup/，应该写成：
rsync -a /data/app/ /backup/
如果漏掉源路径末尾的 /，变成 rsync -a /data/app /backup/，结果就是创建 /backup/app/ 并把内容放进去——多了一层目录，备份结构就乱了。
- 源路径带
/：同步目录「内容」 - 源路径不带
/：同步目录「本身」（含目录名） - 目标路径带
/：更安全，避免意外嵌套（如目标是/backup而非/backup/，rsync 可能创建/backup下的同名子目录）
远程同步必须双方都装 rsync，且注意 SSH 用户权限
用 rsync -avz -e ssh /local/ user@host:/remote/ 这种方式时，user 必须在远程主机上存在，且对目标路径有写权限。常见错误是：
- 远程
user对/remote/没有写权限 → 报错rsync: failed to set times on ... Permission denied - 远程没装
rsync→ 报错rsync: command not found（即使本地有也不行） - SSH 密钥没配好，又没开密码登录 → 卡在连接阶段，无明确报错
验证方法很简单，在远程机器上手动执行 rsync --version，再用相同用户 ssh user@host 'ls -ld /remote/' 看权限。
实时同步别只靠 inotifywait 脚本，得防事件堆积和重复触发
inotifywait -m -e modify,create,delete,move 看起来能监听一切，但真实场景下容易出问题：
- 批量操作（如
cp -r一堆文件）会触发几十次事件，脚本可能并发跑多个rsync，互相冲突 - 文件正在写入中就被触发同步 → 目标端拿到的是不完整文件
- 脚本崩溃或被 kill 后，没有自动恢复机制
实用做法是加简单限流：
inotifywait -m -e modify,create,delete,move --format '%w%f' /source | \ while read file; do sleep 0.5 # 避免高频抖动 rsync -a --delete /source/ user@host:/dest/ break # 同步完就等下次事件，不循环重试 done
更稳的方案是换 lsyncd 或 Syncthing，它们内置队列、延迟合并和原子写入控制。
Syncthing 启动后外网访问不到？重点查 config.xml 和防火墙
默认 syncthing 只监听 127.0.0.1:8384，远程打不开 Web 界面，不是安装问题，而是配置没改。
必须做两件事：
- 编辑
config.xml，把<gui><address>127.0.0.1:8384</address></gui>改成<address>0.0.0.0:8384</address>，然后重启 Syncthing - 确认服务器防火墙放行
8384（Web UI）、22000（数据同步）、21027/udp（局域网发现）
如果用云服务器（如阿里云、腾讯云），安全组规则也得同步放开——光关本地 firewalld 不够。
