Linux 文件同步工具选型与对比

本地或局域网用 rsync，跨云存储必须用 rclone；rsync 基于 mtime+size 增量，rclone 默认靠哈希；混用增复杂度，误删风险高，需按场景选工具并理解数据变更源头。

rsync 和 rclone 哪个更适合日常增量同步

多数人卡在第一步：该用 rsync 还是 rclone？答案取决于目标位置——本地或局域网用 rsync，跨云存储（如 S3、OneDrive、WebDAV）必须用 rclone。两者不互斥，但混用会引入额外复杂度。

常见错误是拿 rclone sync 当 rsync --delete 用，结果误删远端非文件类对象（比如 S3 的 multipart upload 临时分片）。rsync 的增量逻辑基于 mtime+size，而 rclone 默认靠哈希（可关），但关闭后无法检测内容变更，只认修改时间——这点在 NFS 或某些 NAS 上容易失效。

• rsync -avz --delete /src/ user@host:/dst/：适合可信网络，注意末尾斜杠含义（/src/ 表示同步目录内容，/src 表示同步目录本身）
• rclone sync /src remote:dst --checksum --update：加 --checksum 强制比对内容，但会显著拖慢速度；--update 跳过目标端更新时间更晚的文件，避免覆盖
• Windows 用户注意：rsync 在 WSL 下工作正常，但原生 Windows 版（如 cwRsync）已多年未维护，时区和换行符处理易出错

inotifywait + rsync 实现“实时”同步的可靠性边界

所谓“实时”，其实是事件驱动的伪实时。只要不是高并发小文件写入场景，inotifywait 配合 rsync 是够用的。但它扛不住原子写（如 vim 保存时先写临时文件再 rename）、程序批量 flush（如数据库导出）、或 NFS 客户端缓存延迟。

典型失败现象：文件改了，同步没触发；或者触发了，但同步的是空文件或旧版本。这是因为 inotifywait 监听的是 IN_MOVED_TO 或 IN_CLOSE_WRITE，而很多 工具（如 cp --reflink=auto 或某些日志轮转脚本）用的是 rename()，且源文件可能还没落盘。

• 务必加 --exclude='*.swp' --exclude='.git/' 等过滤，避免编辑器临时文件干扰
• 用 inotifywait -m -e close_write,moved_to,create -m /path | while read …… 时，管道会缓冲事件，突发大量事件可能丢事件；改用 --format '%w%f' --quiet 单行输出 + xargs -n1 更稳
• 别依赖单次 rsync 完成同步：加上 --timeout=30 --contimeout=10 防卡死，失败时记录日志而非静默重试

rsync over SSH 的连接复用与超时陷阱

rsync 默认每次执行都新建 SSH 连接，频繁同步时开销大、易触发服务器连接数限制。启用 SSH 复用能解决，但配置不对反而更慢甚至失败。

常见错误是只在客户端配了 ControlMaster auto，却没设 ControlPersist 600，导致连接建好即断；或服务端 MaxStartups 过低（默认 10），多个复用连接排队超时，报错 ssh: connect to host x.x.x.x port 22: Connection timed out。

• 客户端 ~/.ssh/config 加：

  Host target     HostName x.x.x.x     ControlMaster auto     ControlPath ~/.ssh/cm-%r@%h:%p     ControlPersist 600     ServerAliveInterval 30

• 服务端 /etc/ssh/sshd_config 检查：MaxStartups 50:30:100（防止排队溢出），ClientAliveInterval 60（配合客户端保活）
• 测试是否生效：ssh -O check target 应返回“Master running”；ssh -O exit target 手动清理

rclone mount 的挂载点权限与缓存一致性问题

rclone mount 不是 FUSE 文件系统意义上的“真挂载”，它把远程存储映射成本地路径，但所有读写都经 rclone 中转。这意味着：权限由挂载参数控制（不是远端真实权限），且默认开启写缓存——你 echo "x" > file 后立刻 ls 能看到，但远端可能还没上传。

最常踩的坑是脚本里写完文件立刻调用 rclone ls 或 curl 查远端，结果找不到；或者多进程同时写同一文件，因缓存未刷导致内容丢失。

• 加 --vfs-cache-mode writes：至少保证文件 close() 后才上传；full 模式更安全但占磁盘、启动慢
• 权限相关必加：--uid 1000 --gid 1000 --umask 002（按实际用户 ID 调整），否则挂载点可能对普通用户不可读
• 不要用 mount -t fuse 或 systemd automount 管理 rclone mount，它自身有 --daemon 和重启逻辑，交由 systemd 管理时需用 Type=notify 并配 Restart=on-failure

真正难的从来不是选哪个工具，而是搞清数据变更的源头行为——是人手动改的？程序追加写的？还是定时任务覆盖的？不同源头对应不同的监听策略、校验方式和失败恢复路径。漏掉这个，再好的工具链也只是一层薄冰。