黄小秋如果你最初接触 rsync，是在某个运维群里复制到一条命令，十有八九是这条：rsync -avz。小文件同步时一切安好，觉得它不过就是个高级版 cp。直到某天你把几百 G 的日志目录从服务器 A 同步到服务器 B，同步完却发现目标目录里堆满了早该消失的旧文件；或者同步中断后你决定从头再来，白白等了三个小时。那一刻你才会承认，rsync 里几乎每个参数都有脾气，而"会用"和"用得明白"之间，隔着一层实在的运维经验。
这篇内容适合什么人看？正在给服务器做数据迁移的新手运维、经常要在本地和远端之间同步代码和资源的开发，以及所有想把"复制文件"这件事做出版本感的人。rsync 不是唯一能传文件的工具，却是 Linux 生态里少有的"传完还能讲清楚增量逻辑"的同步工具。这篇我不讲命令手册上能查到的照搬内容，重点说清楚那些真正影响你判断的参数、组合和踩坑经验。
1. rsync 到底比 cp 和 scp 强在哪：增量同步的真实逻辑
1.1 从"重复传了整天才发现根本没增量"说起
很多人一开始没有直观感受，觉得 scp 也能传目录，rsync 不过多了一个压缩选项。直到你面对这样的场景：一台服务器上有 200 万个小图片，总共 30GB，每天新增 20%，你需要把它们同步到另一台机器做备份。
用 scp 的话，每天都要从头到尾把 30GB 全部传一遍，因为 scp 没有"上次传过什么"的记忆。用 cp -r 在本地拷贝，同样会把所有文件完整写一遍，即使目标位置已经存在同名同内容的文件。
rsync 不一样。它的增量逻辑不是靠"名字在不在"来判断，而是先判断两个文件的**"大小+修改时间"**是否一致。如果大小和 mtime 都相同，rsync 默认认为文件内容没有变化，直接跳过。
这就是你不加任何额外参数时它快的根本原因：它不是传输工具，而是"比较工具 + 传输工具"的结合。理解这一层，你就不会再疑惑"为什么同样的目录，第一次跑很慢，第二次跑只需要几秒"。
1.2 快速跳过与真正的块级校验：--checksum 的取舍
但是这里有个坑：如果文件内容变了，但大小恰好没变，而 mtime 又被人为改过，rsync 的默认快速判断就会漏掉这个文件。
比如最常见的场景：程序在服务器上把某个日志文件改名、复制、再重置时间戳；或者从 Git 仓库 checkout 出来的文件，mtime 是固定的 commit 时间，但内容在两个分支间可能不同。
此时你需要 -c / --checksum 参数。它会强制 rsync 对每个候选文件做内容校验，而不只看 mtime。注意我用的词是"候选文件"——rsync 不会真的把所有文件逐字节读取，它会先比较大小，如果大小不同就必定传输，只有大小相同才进入校验阶段。所以 -c 并不会像很多人想的那样让速度慢到不可用，在大文件数量多、但单个文件体积小的场景下开销可以接受。
实际选择：
| 场景 | 是否加 -c | 理由 |
|---|---|---|
| 常规代码部署、日志同步 | 否 | 依赖 mtime+size 足够可靠，速度快 |
| 双机热备中的关键数据目录 | 是 | 必须保证任何文件变化都被识别 |
| 文件数量极大、单文件很小（几十万文件量） | 否 | 全量校验的开销可能在扫描阶段就拖垮性能 |
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三种 rsync 使用形态与它们的边界：本地、SSH、daemon
2.1 本地目录同步：最简单也最容易忘掉 / 的场景
很多教程会把本地同步一笔带过，但它其实是理解 rsync 路径语义最好的入门例子。最典型的错误，是分不清这两条命令的区别：
bash复制rsync -av /data/project/ /backup/project/
rsync -av /data/project /backup/
第一条命令里的源路径以 / 结尾，rsync 会把 /data/project/ 这个目录的内容拷贝到 /backup/project/ 之下。第二条命令源路径不以 / 结尾，rsync 会把整个 project 目录本身拷贝过去，最终你会得到 /backup/project/project/。
我见过很多新人在写 crontab 备份脚本时踩这个坑：想备份目录内容，结果每一轮备份都在目标目录里多套一层。所以最简单的记忆方式是：源路径末尾有没有斜杠，决定了你是"搬整个盒子"还是"搬盒子里的东西"。 目标路径末尾的斜杠则更多地是一个"必须配合目录存在性"的细节。
本地同步还有一个很实用的场景：跨磁盘移动目录，比如把 /var/lib/docker 迁到数据盘 /data/docker。直接 mv 在同一文件系统内是元数据操作，一瞬间完成；跨文件系统时 mv 本质也是先复制后删除，此时如果中途断电你可能会面临部分文件已复制、部分未复制的烂摊子。rsync 的好处不只是能断点续传，它还有一个天然优势：传输完成前会写临时文件，完成后再 rename 到目标位置，数据完整性更可控。
执行迁移时建议带上 --remove-source-files 吗？我不太推荐。文件迁移用的妥当做法是先用不带删除的普通同步，确认目标目录完整无误后，再手动校验文件数量，最后用 --remove-source-files 二次清理源端空文件，或者干脆手动删除源目录。上来就加这个参数，一旦中途出差错，源文件清理了一批，目标又没完整，恢复就麻烦了。
2.2 走 SSH 通道的远程同步：单双向、自定义端口与免密
远程同步里最常见的形态是通过 SSH 隧道传输，好处是无需额外启动任何服务，只要两端都有 rsync 和 SSH 权限即可工作。
bash复制rsync -avz /data/web/ user@192.168.1.20:/data/web/
从本地推送到远端。反向则是从远端拉取：
bash复制rsync -avz user@192.168.1.20:/data/web/ /data/backup/
这两条命令方向性的理解非常重要。rsync 习惯把同步的发起端写在前面，也就是源路径在前。很多从 Windows 同步工具转过来的用户，会下意识地写出"目标路径空格源路径"，结果执行后本地目录反而被清空。
推送和拉取不只是方向区别，还涉及一个常见运维场景：发起端永远比接收端活得累。在推模式下，rsync 客户端（发起端）需要扫描本地源目录、比对并发送差异数据；在拉模式下，客户端扫描的是远程源目录、接收数据。如果你的服务器 CPU 不强、磁盘 IO 已经吃紧，尽量从负载较低的一侧发起同步，把扫描/比较的开销留给负载轻的机器。
自定义 SSH 端口时不能像 scp 那样直接用 -P 2222，而是：
bash复制rsync -avz -e "ssh -p 2222 -i /home/user/.ssh/id_ed25519" /data/ user@10.0.0.8:/data/
-e 参数指定远程 shell，这给了你很大的灵活性。如果你所在内网有跳板机，也可以用：
bash复制rsync -avz -e "ssh -o ProxyJump=gateway" /data/ user@target:/data/
2.3 daemon 模式与双冒号语法：什么时候值得用 873 端口
rsync 的第三种形态是 daemon 模式，用 :: 分隔路径。它不再走 SSH，而是基于 rsync 自己内置的协议，两端共同访问一个 rsync 进程，默认端口 873。
bash复制rsync -avz /data/ rsync://backup.example.com/backup/
# 或者简写
rsync -avz rsync://backup.example.com/backup/ /data/restore/
daemon 模式最大的价值是给"目标机不开放 SSH 登录"的场景准备的。比如你有一个备份服务器，只希望接收特定几个目录的备份内容，不想给备份机开 SFTP 权限，更不想给它一个 shell 账号。此时在接收端配一个 /etc/rsyncd.conf，开放模块、限定 IP 白名单，就能做到最小权限的文件投递。
一个最小可用的 /etc/rsyncd.conf 示例：
ini复制uid = nobody
gid = nobody
use chroot = yes
max connections = 4
pid file = /var/run/rsyncd.pid
log file = /var/log/rsync.log
[backup]
path = /data/backup/
comment = Backup Server Module
read only = no
timeout = 300
auth users = rsyncuser
secrets file = /etc/rsyncd.secrets
hosts allow = 192.168.10.0/24
注意 secrets 文件内容格式是“用户名:密码”，且文件权限必须是 600：
bash复制echo "rsyncuser:YourPasswd" > /etc/rsyncd.secrets
chmod 600 /etc/rsyncd.secrets
daemon 模式我建议你在三种情况下才考虑：不想开放 SSH、想接收端能多个客户端同时写入、想结合 rsync 协议做限速和白名单控制。否则默认走 SSH 就够用，额外起一个常驻进程就意味着要多维护一个暴露面，注意将 rsyncd 的监听地址绑定在内网而不是 0.0.0.0，防火墙里也不要轻易把 873 暴露到公网。
3. 参数拆解的真正重心：-a、-v、-z 之外的那些关键选项
3.1 -a 并不等于"全量复制所有特性"
几乎每一篇 rsync 教程都会告诉你，-a 代表 archive 模式，等同于 -rlptgoD。但很少有人逐个解释这些字母。
拆解来看：
-r：递归进入子目录-l：保留符号链接，注意是保留符号链接本身，不是把链接指向的内容复制过去-p：保留权限位-t：保留修改时间-g：保留属组-o：保留属主（此项通常只有 root 用户才有权限执行）-D：保留设备文件和特殊文件
这里最容易被忽略的是 -o。普通用户在两台机器间同步时，如果加了 -a 但没有 sudo 权限，rsync 会在执行时尝试设置属主失败，此时不是静默跳过，而是可能会打印 chown failed 之类的错误，甚至直接中断同步。很多人在"为什么普通用户用 -avz 同步总是报错"这个问题上卡住，就是没有意识到 -a 里面带着属主保留。
实际使用建议：
- 普通用户之间传文件：
rsync -avz --no-o（去掉属主保留）更安全 - root 用户做系统级备份：
-avz没问题 - 跨系统（Windows SMB 挂载目录 与 Linux 间）同步时：
--no-perms --no-owner --no-group避免无意义的权限报错
3.2 -z 压缩的代价：什么时候压缩反而拖慢速度
-z 选项开启传输压缩，但它压缩的不是整个文件流，而是每一段数据块的组合。在广域网传输纯文本日志、JSON 配置、未压缩的数据库导出文件时，-z 的效果确实非常明显，可能能减少 80% 以上的传输量。
但很多人没有想过，-z 需要消耗两端 CPU。如果你的源文件是已压缩过的资产，比如 JPEG、MP4、Gzip 包、SQL 导出后再次 gzip，再对它们做 rsync 压缩，几乎不会有任何体积缩减，却白白浪费大量 CPU 做无意义的压缩运算。
更隐蔽的问题是：在千兆内网环境里，磁盘 IO 往往比网络带宽更慢。此时压缩节省的传输时间难以抵消压缩算法的 CPU 开销，实测下来同步几个 GB 的混合文件，开 -z 甚至比不开还慢一些。
所以我的经验是：
- 跨机房、跨地域低带宽传输：开
-z，并把压缩级别控制在默认即可 - 同内网千兆/万兆同步：关掉
-z，只留-av - 文件已是压缩格式的库目录：建议关
-z
3.3 --delete 家族：保持镜像一致，但也容易误删
--delete 是让目标端删掉源端已经不存在的文件，这使目标目录变成源目录的精确镜像。默认不带它时，rsync 只负责"添加和覆盖"，不负责"删除"。
用 --delete 之前，你要先想清楚：目标端有没有可能比源端多出一些"不能碰"的文件？比如备份目录里有一些源端不存在的归档文件，你希望留在目标端，此时如果带 --delete 就会把它们清掉。
还有更隐蔽的坑：当源目录路径写错或者盘掉了，源端变成一个空目录，rsync --delete 会直接清空目标目录。所以带 --delete 的同步，强烈建议你先把源端路径用 ls 或 du -sh 确认存在且不空，再执行。
还可以使用更精细的变体：
bash复制rsync -av --delete --delete-excluded /data/ user@host:/backup/
--delete-excluded 的含义是，不仅删除源端不存在的文件，还要删除目标端"被排除规则命中"的文件。这个选项很容易造成误删，比如你排除掉了 *.log，结果目标端原有的旧日志文件全被移走。用不用，取决于你是否真的希望目标端完全干净。
3.4 进度、中断续传与限速：长时间同步必须掌握的三个参数
长时间同步最怕两件事：一是传输中网络断了，前面传的全都作废；二是跑着跑着影响了线上业务带宽。
先说断点。rsync 默认对每个文件先写到目标路径下的临时文件，完成后 rename 成正式文件。如果同步中断，临时文件通常会被清理或残留成 .filename.xxxxxx。再次执行时，rsync 会重新比对文件，已经完成的文件会被跳过，但正在传输的那个文件通常要从头传。
--partial 的作用就是保留已传输的部分临时文件。配合 --append-verify 使用时，rsync 会尝试从上一个断点位置继续追加并验证。这在传输一个 20GB 的大文件、网络不稳定时是救命良药：
bash复制rsync -av --partial --append-verify user@source:/data/bigfile.sql /data/
注意 --append-verify 只适合"文件只会从尾部追加或保持不变"的场景。如果源文件可能在中断期间被修改过且不是从尾部追加的，使用它会造成数据错乱，这时去掉 --append-verify 让 rsync 对改动过的文件全量重传更安全。
再说限速，--bwlimit 默认单位是 KB/s：
bash复制rsync -av --bwlimit=1024 /var/log/ user@backup:/var/log/
同步日志类任务，我一般限到 1MB/s 上下能显著降低对线上 IO 的干扰。如果带宽非常紧张，可以考虑 --bwlimit=100 再配 --min-size 只传大文件或只传规定后缀的文件。
最后是进度查看，-P 等价于 --partial --progress，多数在线同步脚本里会用 -avP。如果你希望在脚本里留一个自动产出的状态记录，就额外加 --stats 看传输的字节数、文件数与加速比。
4. 过滤规则与硬链接快照：让 rsync 从"传文件"升级成"做资产版本管理"
4.1 exclude 规则的核心优先级：为什么 --exclude '*.log' 并不总是生效
rsync 的过滤规则与 tar 类似，规则会按顺序匹配，后写的规则可能覆盖前一条规则。最简单也最常用的方式：
bash复制rsync -av --exclude '*.log' --exclude '.git/' /data/project/ user@host:/data/project/
但如果你有多条规则，且需要排除一个目录但保留其中某种文件，顺序就是决定性的。rsync 按"最先匹配的规则生效"处理，所以：
bash复制rsync -av \
--include '*/' \
--include '*.conf' \
--exclude '*' \
/etc/ user@host:/etc/
这组规则的含义是：先让所有目录进入，再保留所有 conf 文件，最后排除其他文件。注意，如果第一行 --include '*/' 漏掉，rsync 完全不会进入子目录，那么后面的 conf 规则只会命中根目录下的文件。
规则多的时候，我建议把它们写到独立文件里而不是全部堆在命令行，命令会干净很多：
bash复制rsync -av --exclude-from=/path/exclude.txt /data/ user@host:/backup/
exclude.txt 里每行写一条排除规则，支持通配符。常见配置：
code复制*.log
*.tmp
.cache/
.editorconfig
4.2 --link-dest：把每次备份变成一份"低成本完整快照"
这是 rsync 里最具性价比的功能，也是最容易被新手错过的高级用法。--link-dest 的意义在于，你可以把当前备份与上一次备份作比较，当文件没有变化时，系统不会真正复制文件，而是在目标目录中创建一个硬链接，链接到上一次备份中的同一 inode。最终效果是：每次备份完成后，从目录结构上看，你拥有了一份完整独立的快照，但磁盘上只存储了文件内容的第一个副本，以及之后新增/修改文件的增量。
bash复制LAST=$(ls -1d /backup/website-* | tail -n1)
DATE=$(date +%Y%m%d%H%M)
rsync -av --delete \
--link-dest="$LAST" \
/data/www/ /backup/website-$DATE/
第一次执行时 $LAST 变量为空，rsync 会做全量备份；之后每次备份都引用上一次的目录。所有未变化的文件都变成指向上次备份的硬链接，看起来每个备份目录文件都齐全，但磁盘占用只增加几次备份间的差异。
这就是很多备份系统如 rsnapshot、BorgBackup 的底层思想。你不需要引入这些重工具，用 rsync 就能手工搭一套不错的版本轮转方案。注意这套方案只适用于文件内容不变、文件名不变的情况。如果文件被重命名了，它会按照旧文件删除、新文件写入来处理，和内容级去重是两码事。
还有一个细节：硬链接在跨文件系统时无法建立。/backup 目录必须保证在同一块挂载分区内轮转，你不能让每次备份都写到不同的挂载盘，否则文件会被完整复制而不是硬链接。检查方式：
bash复制df -h /backup
df -h /backup/website-20250101
确认两个目录使用同一设备。
4.3 符号链接该不该穿透：-l、-L 与 --copy-unsafe-links
使用 rsync 同步站点目录时，符号链接是个容易纠结的点。默认 -a 保留符号链接本身，即同传过去一个指向某目标路径的链接，不会把链接指向的内容复制走。
这在多数场景是对的：比如网站 application 目录里有一个 link-to-tmp -> /var/tmp/shared，同步到服务器 B 后，链接依然指向 /var/tmp/shared。但问题来了，如果服务器 B 上根本没有 /var/tmp/shared 这个目录，或里面内容不同，你的"站点文件同步"其实是不完整的。
如果希望把符号链接指向的目标内容一并传输，使用：
bash复制rsync -avL /data/www/ user@host:/data/www/
-L 的副作用是，它会把链接语义抹掉，目标端不再是符号链接，而是一份实体拷贝。如果未来源端链接换了目标，再次同步并不会自动感知这个链接触点的变化，容易让两端渐渐走样。
更折中的方案是 --copy-unsafe-links：它只对"指向源目录树之外的链接"进行实体拷贝，源树内部的链接维持符号链接形式。这个选项我个人的使用场景是：在同步裸机网站目录时，确保不会残留指向本机其他路径的失效链接。
5. 必须提前摸清的坑：权限、防火墙、中文文件名与"同步后静默缺失"
5.1 权限报错的完整排查链路
如果你用普通用户执行 rsync -av 同步数据到远端，中途偶尔会看到这样一串报错：rsync: failed to set permissions on ... 或 chown ... failed。此时目录里文件其实大多已经传过去了，rsync 最终却可能返回非 0 退出码，很多脚本因此误判同步失败。
遇到这个报错，我建议按这个顺序排查：
- 先缩小范围：
rsync -av --no-o --no-g重试，去掉属主和属组保留，通常就能顺利通过。 - 如果还报权限问题，检查目标目录的父级是否有写入及执行权限：
ls -ld /data /data/backup。rsync 写入文件时使用的是临时文件加 rename，但父目录需要执行权限才能创建临时文件。 - 如果同步中用到
--delete，目标目录本身必须对执行同步的用户开放写权限，否则删除动作会失败。 - 检查接收端用户对已存在目录的属主是否有写权限，而不是只检查父目录。
要知道 rsync 的退出码本身就很有信息量。0 表示成功，23 表示部分文件传输失败（比如某些文件被占用或权限不足），24 表示源文件在扫描过程中消失（日志轮转时导致的文件被移除），11 表示文件 IO 错误。写脚本时如果你只是 if [ $? -eq 0 ] 粗鲁判断，很可能丢掉这些中间状态，建议把退出码记录到日志后重试而非立即发送告警。
5.2 防火墙与 aliyun 等云安全组对 873 端口的拦截
使用 daemon 模式同步时，常见的"连不上"案例并不都是 rsyncd.conf 写错，而是安全组层面屏蔽了 873 端口。云服务器上除了本机 iptables/firewalld，还要检查控制台安全组是否放行。排查顺序：
bash复制# 先看本地端口监听
ss -lntp | grep 873
# 再在客户端测试远端端口通不通
telnet 192.168.1.20 873
# 或
nc -vz 192.168.1.20 873
如果本地监听正常但外部 telnet 不通，那么拦住你的基本就是安全组或防火墙，而不是 rsync 本身。在不需要对外网提供服务的情况下，安全组里只允许内网 IP 网段访问 873 即可。
如果用 SSH 模式且改了 SSH 端口，则需要确认 -e "ssh -p 2222" 中的端口放行情况，否则会报 Connection refused。
5.3 中文文件名的编码问题与不同步现象
在国产 Linux 生态和 Windows 之间同步文件越来越常见，中文文件名遇到的默认问题其实是旧版 rsync 的 iconv 转换。跨不同编码系统（比如从 Windows 复制到 Linux）时，你可能会发现同步完后目标端文件名出现乱码。
rsync 3.x 的支持方案是：
bash复制rsync -av --iconv=UTF-8,GBK /mnt/windows/ /data/linux/
含义是把本地的 UTF-8 文件名转成 GBK 写入目标端。注意 --iconv 的两个编码参数是"本地、目标端"的顺序，反了会造成乱码雪上加霜。跨系统同步前，先在两个目录里各放一个中文名测试文件跑一遍，确认目标端落在你的预期中，再操作正式目录。
至于"同步后静默缺失"，还有一种常见原因是 rsync 默认不传输以 . 开头的隐藏文件以外的某些临时文件吗？其实不是，rsync 默认处理隐藏文件是正常的。真正让它"看不见"的往往是权限读取失败但你没开 --verbose，或者你写的 exclude 规则误伤了。遇到"总觉得少了点什么"时，建议分两步确认：
bash复制# 先看两端文件总数
rsync -avn --stats /data/ user@host:/data/ | grep "Number of files"
# 再去看两端各自 du -sh 是否接近
du -sh /data/ user@host:/data/
如果数量一致但体积差异很大，大概率是稀疏文件或硬链接导致的，需要根据形态加 -S 或 -H 去处理。
6. 一个可直接落地的 Web 站点定时增量同步方案
6.1 目录与数据库分开回源的设计
把 rsync 放进需要长期运行的备份体系时，不能只写一条裸命令，需要规划目录结构、日志轮转与拉取方向。这里分享一个我在多个项目里用过的基础方案，兼顾代码目录与 MySQL 数据。
假设目标是：每天 02:30 从生产服务器的 /data/www/ 同步站点目录到备份服务器 /backup/www/，每天保留 7 份快照，数据库则通过 mysqldump 生成 SQL 文件后再做增量同步。
目录结构：
text复制/backup/
├── www-20250605/
├── www-20250606/
└── mysql/
└── site-20250606.sql.gz
推荐从备份服务器发起拉取而非推模式，这样生产服务器只需要开 SSH 白名单给备份服务器，生产端无需主动向外连接。备份脚本写在备份服务器上即可。
6.2 完整的备份脚本示例
bash复制#!/bin/bash
# /usr/local/bin/site_backup.sh
set -u
# 基础变量
DATE=$(date +%Y%m%d%H%M)
BACKUP_BASE=/backup
HOST=10.0.0.8
REMOTE_DIR=/data/www
SSH_KEY=/home/backupuser/.ssh/id_ed25519
SSH_PORT=22
# 昨天的快照目录作为 --link-dest 参照
LAST_WWW=$(ls -1d ${BACKUP_BASE}/www-* 2>/dev/null | tail -n 1)
mkdir -p ${BACKUP_BASE}/www-${DATE}
/usr/bin/rsync -a --delete \
-e "ssh -i ${SSH_KEY} -p ${SSH_PORT}" \
--link-dest="${LAST_WWW}" \
--exclude-from=/usr/local/etc/backup_exclude.txt \
backupuser@${HOST}:${REMOTE_DIR}/ ${BACKUP_BASE}/www-${DATE}/
RC=$?
if [ ${RC} -eq 0 ]; then
echo "[OK] www sync success at $(date '+%F %T')" >> /var/log/site_backup.log
else
echo "[FAIL] www sync failed rc=${RC} at $(date '+%F %T')" >> /var/log/site_backup.log
fi
# 数据库导出：在生产端已配置好 mysqldump，这里只同步导出文件
/usr/bin/rsync -a -e "ssh -i ${SSH_KEY} -p ${SSH_PORT}" \
backupuser@${HOST}:/var/backup/mysql/ ${BACKUP_BASE}/mysql/
脚本中几个细节值得留意：
LAST_WWW变量取最近一次备份目录，如果为空字符串，--link-dest=""不会报错只会做全量备份，但要确认ls -1d /backup/www-*找不到任何目录时不会把奇怪文件名传进去。- 排除文件
/usr/local/etc/backup_exclude.txt中至少应该有*.log、tmp/、.git/。 - 数据库备份的做法是在生产端写另一个 crontab 任务负责 mysqldump，完成后传到
/var/backup/mysql/。备份服务器只负责拉取该目录，不直接连生产 MySQL，避免额外暴露数据库端口。
crontab 写入：
bash复制30 2 * * * /usr/local/bin/site_backup.sh >> /var/log/site_backup_cron.log 2>&1
6.3 恢复演练与日常巡检
同步脚本跑通不是结束，任何备份方案没有经过恢复演练都不能算数。我建议每半个月至少做一次"从最近快照恢复目录"的演练：在备份服务器上把 www-最新日期 目录软链到一个切换目录，让测试环境域名指向它，然后对比页面关键资源是否齐全。
巡检时可以用 --stats 分析最近的同步记录：
bash复制rsync -avn --stats /data/www/ /backup/www-20250605/ | tail -n 20
-n 表示 dry run，不会真正执行写入，只会模拟输出将要复制或删除的文件。如果输出中意外出现大量文件，说明当前目录结构与上次快照差异过大，要及时看是哪一侧更新异常。
另外注意磁盘容量的水位。硬链接快照虽省空间，但如果站点每天都在产生非常大的差异文件，多轮快照的磁盘涨幅会很明显。建议定期用 df -h /backup 和 du -sh /backup/www-* 观察趋势，保留最近 7 份的老快照可按需手动清理，或搭配 find /backup -maxdepth 1 -name 'www-*' -mtime +7 -exec rm -rf {} \; 做简单轮转。
这套方案做完之后，你的备份不再是一个"25G 的完整目录每夜重复拷贝"，而是一组"每次 30 秒内完成增量合并、每天保留完整快照"的低成本资产，这本质上就是 rsync 参数与备份设计彼此配合产生的效果。
我在多次生产环境的迁移和容灾演练中形成的习惯是：任何第一次上 rsync 的任务，都会先用 -a --dry-run --stats 跑一遍预览，确认两端预计算的差异符合预期再正式同步。像 --delete、--remove-source-files 这类带破坏性的参数，只会在明确确认目录内容后才加入。rsync 可以让你在一分钟内写出高效的同步命令，也可以让你在一秒钟内因为一个多余的 / 或一个误输入的 --delete 丢掉重要数据。这份谨慎，恰恰是工具用得够久以后才会沉淀下来的东西。