rsync 默认基于修改时间与文件大小做增量同步，无需额外参数；加 –checksum 可强制内容比对，但会降低效率。
rsync 怎么只传变化的文件，不重复拷贝整个目录
rsync 默认就是增量同步的，核心靠 --checksum 和默认的「修改时间 + 大小」双校验。只要目标端文件没被手动改过、时间戳没被意外重置，它几乎不会重复传完整文件。
常见错误是加了 --ignore-times 还以为在做增量——其实这会让 rsync 忽略 mtime，强制全量比对 checksum，反而变慢；或者用了 -a 却忘了 -a 包含 -t（保留时间戳），而某些挂载文件系统（比如 FAT32 或某些 NFS）根本不存 mtime，导致每次都被判定为“已变更”。
- 生产环境优先用
rsync -a --delete，不加--checksum，依赖时间戳+大小判断更高效 - 若目标端可能被人工编辑（比如日志文件被截断但没改名），加
--checksum强制内容比对 - 遇到 NFS/CIFS 挂载点，先测试
stat是否返回合理 mtime；否则老老实实用--checksum，别赌运气
如何避免 rsync 把删除操作同步过去
加 --delete 是双刃剑：它让备份目录和源完全一致，但一旦源端误删，目标端跟着一起丢。很多人以为加个 --dry-run 就安全，其实它只模拟传输，不模拟 --delete 的删除动作——--dry-run 下你看不到哪些文件会被删。
- 真正保险的做法是分两步：
rsync -a --dry-run SRC/ DST/看传输列表，再单独跑rsync -a --delete --dry-run SRC/ DST/看删除列表 - 日常备份建议用
--delete-after而非--delete：等所有文件传完再删，避免传输中断导致目标端残留旧文件又丢了新文件 - 关键备份必须加
--backup --backup-dir=，例如--backup --backup-dir=/backup/deleted_$(date +%F)，把被删文件挪走而不是直接 rm
rsync over ssh 时权限和路径容易错在哪
最常踩的坑不是命令写错，而是 SSH 登录用户对目标路径没有写权限，或者用了相对路径却搞不清是在哪台机器上解析。
-
rsync -av /local/ user@host:remote/中的remote/是远程用户的家目录下的子路径，不是绝对路径；要写成user@host:/full/path/才明确 - 如果远程用户是
backup，但目标目录属主是www-data，即使backup在www-data组里，也得确认该组有写权限，且目录设置了 setgid（chmod g+s）否则新建文件属组会回退 - 用
rsync -e "ssh -p 2222"指定端口时，别漏掉引号，否则 shell 会把-p当作 rsync 自己的参数报错
大文件或大量小文件备份卡住或超时怎么办
rsync 本身不处理网络抖动，SSH 层的 TCP 超时和重传机制才是瓶颈。现象通常是卡在某个文件不动、或报 Write failed: Broken pipe。
- 加
-e "ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3"让 SSH 主动保活，比等底层 TCP 超时快得多 - 传大量小文件时，
--compress反而拖慢速度（压缩开销 > 网络节省），除非跨公网低带宽链路；内网备份直接关掉 - 单个超大文件（>10GB）建议加
--partial --progress，断点续传；但注意--partial不兼容--inplace（后者会直接覆盖原文件，无中间状态）
增量不是自动可靠的，它高度依赖时间戳完整性、SSH 连接稳定性、以及你是否看清了每个 flag 的实际作用——尤其是 --delete 和 --backup 同时出现时，删和备的先后顺序得自己心里有数。