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

舞夢輝影

发布时间：2026-02-12 22:31:03

794人浏览过

来源于php中文网

原创

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

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

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 复用能解决，但配置不对反而更慢甚至失败。

Tun2企业网站管理系统(支持静态生成)2.0.18

Tun2企业网站管理系统是一套针对企业开发的CMS。它是一款具有专业级的功能和傻瓜式管理的网站站管理软件。Tun2追求的是简单与实用。它不同于大型门户CMS，繁杂并令人无从下手。因为它正对的用户是企业网站，所以它将更贴近企业本身【2.0.18更新说明】1、修复linux主机无法群发邮件的bug2、增加自定义栏目静态文件保存名、内容静态文件保存名& K6 V& N4

下载

常见错误是只在客户端配了 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