rsync必须搭配SSH实现安全增量备份：默认走22端口，改端口需用-e指定；禁用交互式登录须限制authorized_keys中command；增量依赖硬链接快照（cp -al）与--link-dest，非rsync自身功能。
rsync + SSH 是当前最稳妥的远程备份组合
不用 rsync 的纯 scp 备份，容易丢增量、难校验、无法断点续传；用 rsync 但裸跑（没走 SSH），又暴露数据和认证凭据。真正落地时，rsync 必须搭配 ssh 作为传输层，且默认就支持——它不依赖守护进程，也不开额外端口。
常见错误现象：rsync: failed to connect to host: Connection refused，其实是误用了 rsync:// 协议而非 SSH 模式；正确写法必须带 user@host: 或显式指定 -e "ssh -p 2222"。
- 默认走 SSH 的 22 端口，改端口必须用
-e "ssh -p 2345"，不能只写--port=2345（那是 rsync daemon 模式） - 排除临时文件用
--exclude='.tmp'，注意路径是相对于同步起点的，不是绝对路径 - 加
-a --delete能镜像目录，但首次运行前建议先加--dry-run看实际要删什么 - 如果目标机 SSH 配了
ForceCommand（如某些跳板机），rsync会失败，得换用rdiff-backup或手动打包再传
SSH 密钥免密登录必须限制命令权限
直接 ssh-copy-id 推公钥上去，看似省事，实则等于给备份账号开了全系统 shell 权限——只要私钥泄露，对方就能执行任意命令。生产环境必须锁定 SSH 命令范围。
使用场景：只允许该密钥调用 rsync，禁止交互式登录或执行其他命令。
- 在目标机的
~/.ssh/authorized_keys里，把公钥行开头加上：command="rsync --server --sender -vlogDtpre.iLs . /backup/path",no-pty,no-agent-forwarding,no-X11-forwarding -
--server --sender是 rsync 内部通信协议必需参数，漏掉会报protocol version mismatch - 别用
restrict代替具体禁用项，OpenSSH 7.0+ 才支持，旧系统可能忽略 - 测试是否生效：本地执行
ssh -i key user@host，应该直接退出并报错，而不是进 shell
备份脚本里必须检查 rsync 退出码，不能只看 stdout
rsync 成功完成但部分文件跳过（比如权限不足、文件被占用），退出码仍是 0；只有严重错误（连接中断、目标不可写）才返回非 0。靠 echo "done" 判断成功，等于埋雷。
性能影响：加 --itemize-changes 会多输出一行每文件变更摘要，对大目录略拖慢，但比事后人工排查强得多。
- 关键判断逻辑应为：
if [ $? -gt 24 ]; then echo "rsync warning or error"; exit 1; fi—— rsync 规定 0–23 是正常状态码，24+ 才表示问题 - 加
--out-format='%n %t %M %l %o'可记录文件名、修改时间、权限、大小、操作类型，便于审计 - 避免用
set -e简单兜底，因为 rsync 本身常返回 23（部分文件未更新），不该触发脚本中止
增量备份需配合硬链接快照，否则空间失控
每天全量 rsync 到同一目录，等于每天存一份完整副本，磁盘几天就满。真正的“增量”不是靠 rsync 自身实现的，而是用 cp -al 创建硬链接快照，再让 rsync 更新最新一份。
兼容性注意：硬链接只在同文件系统内有效，跨分区或挂载 NFS 不适用；ext4/xfs 都支持，但 btrfs/zfs 应优先用原生命令（btrfs subvolume snapshot）。
- 典型结构：
/backup/2024-06-01（当前）、/backup/2024-05-31（上一版），新备份前先cp -al 2024-06-01 2024-06-02 - rsync 命令末尾加
--link-dest=/backup/2024-06-01，相同文件自动硬链接过去，不占新空间 - 删除旧快照用
rm -rf即可，内核自动回收无引用的块，无需额外清理 - 监控可用空间建议用
df -i查 inode，硬链接多时 inode 比磁盘空间先耗尽
硬链接快照看着简单，但 --link-dest 路径必须是目标机上的绝对路径，且 rsync 运行用户要有读取权限——这两点最容易在跨用户或容器化部署时出错。
