rsync核心用法实战：从增量备份到远程同步的完整指南

rsync 这个命令说实话我用了快十年了但每次项目里需要同步文件、做备份我第一个想到的还是它。它不是最花哨的工具但绝对是 Linux 服务器上最可靠、最值得依赖的那一类。很多人知道 rsync 能做增量同步但真正用好的却没几个。最常见的就是一条rsync -av走天下同步完了也不检查出问题才开始怀疑参数是不是写错了。这篇文章我就用真实项目中的案例来拆解从最常用的参数组合到镜像目录、远程备份、快照保留、异常排查把这些场景一个个过一遍。不管你是刚接触 rsync 的新手还是已经用了很久但一直没认真琢磨过的老手这篇内容都能给你一点“原来还能这么用”的启发。我会尽量按实际工作中踩过的坑来讲不只是把命令抄出来还会解释每个参数为什么这么选每种场景下哪些选项不能乱加。我们直接开始。1. rsync 的核心机制与常用参数定位1.1 增量同步的原理其实不用背文档理解 rsync 之前先搞清楚它和 scp、cp 这类全量复制工具的本质区别。普通的复制命令不管目标文件是否和源文件一致都会把整个文件重新传一遍。而 rsync 默认会先对比源端和目标端的文件检查文件大小、修改时间这些属性发现文件有差异时只传输有变化的部分。它真正厉害的地方在于“差量传输”也就是 rsync 的 delta transfer 算法。这个算法会把文件切成一块一块的接收端先算出每一块的校验和发给发送端发送端根据校验和找出源文件中和目标文件一致的块只传输那些不相同的块然后在接收端拼装出完整的新文件。所以当你同步一个 500M 的数据库备份文件时如果只修改了其中 10M 的内容rsync 不会重新传输整个 500M而是把变化的块传过去再把未变化的块拼接回来。这就是它在备份场景下特别受欢迎的根本原因。我在实际项目里见过很多人误以为-av就是增量同步的全部其实增量同步是 rsync 的默认行为-a和-v只是控制同步属性与输出。理解这一点后再看后面那些更复杂的参数就不容易混乱。1.2 最经典的 rsync -av 组合不能乱用rsync -av是网上出现频率最高的一组参数。它的作用拆开来看很简单a是 archive 归档模式等价于-rlptgoD也就是递归同步、保留软链接、保留权限、保留修改时间、保留属主和属组、保留设备文件和特殊文件。v是 verbose输出同步的文件列表。这组参数做日常目录备份确实很实用但有个默认行为要注意-a并不会帮你删除源端已经不存在、目标端仍残留的旧文件。所以如果你用rsync -av做站点发布会发现旧的静态资源文件一直堆积在目标服务器上。这就引出了后面要重点说的--delete参数。在实际同步中我通常还会根据场景额外加两个常用选项-z传输时启用压缩适合带宽有限的跨公网同步但对局域网和本机同步反而会消耗 CPU不建议加。-h以人类可读格式显示传输大小同 M、G 这种单位避免看到一串数字还得自己数位数。一个我常推荐的本地基础同步命令是rsync -avh /data/source/ /data/backup/注意目录尾部斜杠的有无这个细节特别容易把人坑了。/data/source/加上斜杠表示要同步的是目录里的内容如果不加斜杠/data/source表示要同步这个目录本身。连目标端的写法也有讲究因为目标端是否带斜杠会决定目录的层级结构。很多新手在这里栽过跟头我会在后面的案例里详细展开。2. 场景一本地目录镜像与增量备份2.1 用 --delete 实现真正的目录镜像有一次我帮朋友处理一个发布服务器他每次更新程序都需要手动清空旧的 dist 目录再上传新构建出来的打包文件。这样确实能保证线上文件干净但每次都全量上传几百兆文件速度慢还容易漏文件。我建议他把发布流程改成 rsync 同步关键就是加--delete参数。--delete的作用是删除目标端多余的文件让目标端完全同步源端的文件列表。它的威力很大如果误加或者源目录本身是空的可能会清空目标目录的数据。所以使用这个参数的基本原则是先不加--delete跑一遍确认文件列表无误。或者加--dry-run参数也就是-n先演练一次只显示会被同步和删除的文件不实际执行。镜像目录的完整命令一般写成rsync -avh --delete /data/prod/dist/ /data/backup/dist/我从实际使用中总结出一个经验把--delete和--backup配合使用能进一步降低误删风险。--backup会在覆盖或删除文件前把目标端的旧文件重命名保存默认会在文件后面加上~后缀也可以用--backup-dir把旧文件统一放到指定目录里。rsync -avh --delete --backup --backup-dir/data/backup/trash/ /data/prod/dist/ /data/backup/dist/这样即使同步后发现某个文件不该删也能从 trash 目录里找回不会尴尬到要找备份服务商恢复。对生产环境来说这种“删除但不丢数据”的机制真的很重要。2.2 实战全量初始化加每日增量备份备份场景是我使用 rsync 最多的领域。备份分为两个阶段第一个阶段是全量备份第二个阶段是增量备份。刚开始做备份服务器时我直接用了一条最简单的增量同步命令rsync -av /data/ /backup/第一次同步时因为目标端没有文件rsync 会把源端所有文件全部传过去实际效果等同于全量复制。之后再次执行时它才会真正发挥增量能力只同步源端有变化的新增和修改文件。所以 rsync 不需要提前区分“全量”和“增量”第一次执行天然就是全量后面都是增量。但这个方案有一个隐患如果源端在两次备份之间删除了某个重要文件rsync 默认不会把删除动作同步过去所以目标端会一直保留着旧文件。这个特性对“备份”来说其实是优点但对“镜像”来说是缺点。如果想保留历史删除文件可以把 sync 操作封装到一个脚本里配合日期目录或快照工具。我常给新手推荐的做法是备份目录下按日期建子目录先软链接到最新备份再用--link-dest指向上一份备份这样既保留了历史版本又不会重复消耗磁盘空间。具体做法在下一节详细展开。2.3 用 --link-dest 做时间点快照省心又省盘--link-dest是我个人最喜欢的 rsync 参数之一它能实现“看起来像完整备份实际是增量存储”的效果。原理是如果目标端要写入的文件与--link-dest指定的目录中对应文件完全一致rsync 不会复制文件内容而是直接在目标端创建一个硬链接指向 link-dest 里的同一份数据。硬链接的好处是文件系统层面不会占用额外空间文件看起来就像是真实存在于两个目录里。对一个 200G 的文件只做少量修改时新快照里只是复制了原文件对应的数据块或直接建立硬链接存储开销非常小。我实际用的备份脚本结构大概是这样的#!/bin/bash BACKUP_BASE/backup/project SNAPSHOT_DATE$(date %Y%m%d_%H%M%S) LAST_BACKUP$(ls -1 $BACKUP_BASE | grep backup_ | tail -n 1) if [ -n $LAST_BACKUP ]; then LINK_DEST--link-dest$BACKUP_BASE/$LAST_BACKUP else LINK_DEST fi rsync -ah $LINK_DEST /data/project/ $BACKUP_BASE/backup_$SNAPSHOT_DATE/这段脚本的逻辑是每次创建一个带时间戳的新目录然后用上一次的备份目录作为--link-dest参考。某文件没变化时新目录里的文件只是硬链接到旧目录有变化时则实际写入新数据。用这种方式做出来的备份目录从用户视角看每个时间点都是完整快照可以随时直接访问、恢复任意历史版本。而磁盘实际占用只比最初全量备份多出每次变化的数据量。所以我一直认为--link-dest应该是所有用 rsync 做备份的人都该掌握的参数。3. 场景二跨服务器远程同步3.1 SSH 远程同步的正确姿势远程同步是 rsync 最典型的应用场景之一。把一个 web 服务打包同步到另一台服务器或者把数据库备份拉到本地都可以直接用 rsync 加 ssh 完成。最简单的远程同步命令是rsync -av /data/webroot/ root192.168.1.101:/data/webroot/这个命令会通过 SSH 登录目标服务器然后把源目录的内容同步过去。目标路径在远程主机上格式是用户名主机名:路径。为了让远程同步更可靠我有几个建议给 rsync 配置 SSH key避免每次输入密码更方便配合 cron 定时任务。用ssh -p指定非默认端口时rsync 需要写成-e ssh -p 2222这种格式而不是直接在 rsync 命令里传端口。远程服务器上的 rsync 版本尽量保持和本地一致或更新避免某些参数在旧版本上不支持。举个例子使用非标准 SSH 端口同步的命令是rsync -av -e ssh -p 2222 /data/webroot/ root192.168.1.101:/data/webroot/如果你不想用 root 登录也可以指定普通用户但需要确保该用户对目标目录有写权限。实际生产环境里我一般会单独建一个用于备份的系统用户然后在 sudoers 或目录权限上做限制而不是直接把 root 密码暴露给脚本。3.2 断点续传和带宽限速跨公网同步必备在局域网里同步通常很快几 GB 文件也就一两分钟的事。但跨公网同步时网络不稳定、带宽有限、中途断连都是常态。这时有四个参数特别值得记住--partial保留已传输的部分文件。rsync 默认会在同步中断时删除临时文件下次重来加上--partial后已传完的块会被保留下次同步时基于已有内容继续而不是从头传输。--progress显示传输进度能直观看到完成了多少网络是否卡住。--bwlimit设置带宽上限单位是 KB/s。生产环境里如果不限速rsync 很可能把出口带宽占满影响线上业务。--timeout设置超时时间同步长时间卡住时自动断开。一条典型的长距离同步命令是rsync -avz --partial --progress --bwlimit2048 --timeout600 /data/db_backup/ backupbackup-server:/backup/db/这里的--bwlimit2048表示限速 2MB/s实际项目中要根据业务情况估算可用的空闲带宽。比如带宽是 100Mb 的服务器理论峰值在 12MB/s 左右那么留给 rsync 的带宽可以设置成 5000 或 8000避免占满资源。有一个隐藏点容易被忽略--timeout是空闲超时不是总超时。它会检查一段时间内是否没有任何数据交互如果长时间没动静就断开连接防止 rsync 在断网情况下一直挂着不退出。只设置--timeout而不设置--partial断线后重跑还是会从零开始所以这两个参数通常成对出现。3.3 用 rsync daemon 模式做无 SSH 同步rsync 除了走 SSH 通道还支持以 daemon 模式运行也就是在服务器上跑一个 rsync 服务客户端通过 rsync:// 协议连接。这种模式在早期文件分发、镜像同步场景中很常见比如镜像源、内网文件发布等。daemon 模式的配置文件通常位于/etc/rsyncd.conf最简单的配置长这样[backup] path /data/backup comment Backup Directory read only no auth users backupuser secrets file /etc/rsyncd.secrets配置好后在服务器上启动 rsync daemon。客户端同步数据时使用rsync -av rsync://backupuser192.168.1.101/backup/ /data/local_backup/daemon 模式的好处是不依赖 SSH 对账户开放比较可控坏处是要多维护一套认证和权限配置。现在很多服务器都直接走 SSHdaemon 用得少了。但在 NAS、嵌入式设备这类难以开启 SSH 的环境里它仍然是实用的同步方案。我之前在几个 NAS 品牌上配置数据备份时就遇到过设备只提供 rsync daemon 服务的情况配置文件写法不复杂反而比各种 GUI 同步插件更稳定可靠。4. 场景三典型应用案例拓展4.1 exclude 排除规则控制同步范围同步整个目录时有时候只需要排除缓存、日志、临时文件等不需要备份的内容。rsync 提供了--exclude和--exclude-from两种方式。单条命令可以直接写rsync -av --exclude*.log --excludecache/ /data/app/ /backup/app/这种方式适合规则较少的场景。如果规则很多就把排除规则写进一个文件里用--exclude-from引用rsync -av --exclude-from/etc/rsync_exclude.txt /data/app/ /backup/app/排除规则文件内容示例*.log *.tmp cache/ runtime/ .git/这里有个容易踩坑的细节路径的写法会影响匹配范围。比如你写cache/带斜杠表示匹配目录不带斜杠的cache会同时匹配文件和目录。如果你只想排除顶层cache目录应该写/cache/前面的斜杠表示从根开始的相对路径避免把二级目录里那些同名 cache 目录也排除掉。如果在做镜像同步时使用了--delete特别注意排除规则和删除规则是叠加生效的。被排除的文件不会被同步也不会被删除所以目标端会一直保留第一次同步时留下的旧文件。如果目标端已经存在一个目录node_modules你在排除规则里写了它那么本地删掉它时目标端的旧副本不会消失因为它们根本没有进入同步流程。这在清理发布目录时会让旧文件一直残留需要定期手动处理。4.2 大文件同步和高性能调优同步大文件时rsync 默认的行为可能不够高效。大文件常用调优思路是加大--block-size配合--whole-file或调整 checksum 方式。当源端和目标端是同一台机器上的本地目录同步时rsync 默认会使用--whole-file也就是直接把整个文件复制过去不做差量校验。这通常更快因为磁盘 IO 比网络 IO 更便宜不用花费 CPU 去计算校验块。但如果你的目标是保留目标端的块并通过 delta transfer 减少写入量就得手动关闭这个默认行为。同步跨网络的大文件时-z压缩对已经压缩过的文件比如.zip、.mp4、.gz基本无效反而白白消耗 CPU。经验是数据库备份、日志文本这类文件适合开启压缩多媒体文件、压缩包等不适合。我在同步服务器上的数据库定期备份文件时一般在源端先用 gzip 压缩成.sql.gz然后 rsync 直接传输压缩后的文件传输时不再开启-z。这样能显著减少传输时间也减少了 CPU 的额外开销。如果源端没有压缩跨公网传输时开启-z反而能省不少带宽一压一传到目标端再解压即可。如果文件特别多、单个文件又比较小比如一个包含几万个头像图片的目录rsync 的启动和扫描开销会很明显。可以尝试增加--no-whole-file来启用差量传输以减少网络传输量或者直接用-W强制全量传输跳过文件块的 checksum 计算适合不需要做增量的小文件场景。这个取舍因场景而异没有银弹得实测对比。4.3 配合 cron 做定时同步避免人肉备份把 rsync 和 cron 结合是所有备份方案里最基础也最推荐的做法。写一个简单的脚本然后用 crontab 定时执行就能形成一套基本的自动备份机制。假设我们在/opt/scripts/backup_project.sh里放了备份脚本内容大致如下#!/bin/bash rsync -av --delete --backup --backup-dir/backup/trash/ /data/project/ /backup/project/然后设置 crontab30 2 * * * /bin/bash /opt/scripts/backup_project.sh /var/log/rsync_project.log 21这段配置表示每天凌晨 2 点 30 分执行同步并把日志写入文件。定时任务里有个容易被忽视的问题脚本执行时的环境变量和当前目录可能与手动执行时不一样。所以脚本里最好用绝对路径rsync 命令也要写全路径或者确保 PATH 环境变量里包含 rsync 的安装目录。在我看来定时同步的关键不是把命令放到 cron 里就完事而是需要监控“同步是否真的成功”。我见过很多 cron 任务是安静的公司 API 同步失败了几个月没人发现直到要恢复数据时才发现备份服务器上的数据早就停留在很久以前。比较合理的做法是脚本里加一个返回值判断if rsync -av /data/project/ /backup/project/; then echo $(date) OK /var/log/rsync.log else echo $(date) FAIL /var/log/rsync.log fi还可以配合邮件或其他通知工具在失败时报警。日志文件建议保留一段时间方便事后排查。5. 常见问题与排查技巧实录5.1 rsync 同步后文件丢失多半是 --delete 惹的祸很多用户第一次使用--delete后会出现“目标端文件被清空”的情况。最常见的错误是源路径的写法把目录结构和删除目标搞混。比如你想同步/data/project/到/backup/project/源端如果写成了/data/project没有尾部斜杠rsync 会把整个 project 目录同步过去在目标端生成/backup/project/project这样的嵌套结构。此时再加--delete就会删除目标端/backup/project/下所有与源目录列表无关的文件。如果目标端之前就是备份目录那备份中的很多文件可能被误删。排查这类问题时我第一步是用-n加--delete演练一遍rsync -avn --delete /data/project/ /backup/project/-n是--dry-run的简写只会显示将要执行的动作不会真正改变文件。这个命令的输出会列出将要删除的文件如果发现删除列表里出现了不该删除的东西立即停止先检查源路径写法和目标路径结构必要时把源端和目标端换成绝对路径再试。还有一个实用技巧首次使用带--delete的同步命令前给目标目录做一个快照或者压缩存档。这样即使执行过程中出现误删也能快速恢复不会造成不可逆转的损失。5.2 rsync 传输中断时临时文件残留的问题rsync 中断后如果目标端残留了.rsync-partial之类的临时文件很多人的第一反应是恐慌以为数据损坏了。其实这是 rsync 的机制中断时未完成的文件会以临时文件形式留在目标端配合--partial选项下次运行时可以基于这些残留块继续传。但如果你没有加--partial参数rsync 默认会在中断后清除临时文件这是一种保护机制防止文件半残状态污染目标目录。所以你看到临时文件说明要么是用了--partial要么是 rsync 进程被强制终止导致清理没来得及执行。处理方式是检查临时文件是否可以安全删除。如果确定传输失败并且不需要断点续传可以手动清理find /backup -name *.partial -type f -delete要避免临时文件继续堆积可以在脚本里先清理再同步find /backup -name *.partial* -type f -delete rsync -av --partial /data/ /backup/不过如果同步的目录很大每次都先全盘 find 也会增加额外开销。我建议把临时文件的下场纳入备份策略设计里而不是单纯依赖 find 清理。5.3 rsync 慢的排查思路rsync 同步慢可能有几个原因我按常见程度排一下网络上没有限速或者源端向目标端传输时带宽不够。文件数量特别多导致 rsync 扫描文件列表的时间很长。开启了-z压缩但是文件本身是压缩过的CPU 白白消耗。没有使用--partial网络抖动导致多次重传整个文件。排查步骤一般是先看网络流量情况iftop或nload看实时带宽确认传输是否达到了带宽上限。再测试一个单文件的裸传速度确认是网络问题还是 rsync 配置问题scp 一个大文件到目标端看看耗时。用--stats参数查看传输详情能看出文件列表扫描、文件传输各占多少时间。--stats这个参数非常好用它在同步结束后输出统计信息比如实际传输的字节数、总字节数、文件数、速度等。我之前发现一个 rsync 慢的案例就是通过--stats看到实际传输的文件数远大于预期后来才发现--exclude规则写错了把大量不需要备份的缓存文件也带了进去。5.4 特殊文件与权限问题rsync 在同步时使用-a参数会保留权限和属主属组但前提是两端对应用户的 UID/GID 一致。如果目标端和源端的用户 ID 不一致很容易出现“文件所有者错乱”的情况。跨平台同步Linux 到 macOS 或 Windows 的某些环境时尤其常见。解决方式有几个思路不要用-a改用-rt只保留基本属性和递归权限由目标端自行处理。在命令里追加--chownuser:group强制指定目标端文件的属主属组。用--no-owner和--no-group仅跳过属主和属组同时保留其他归档特性。举一个实际例子我在把 Linux 服务器数据同步到一台 NAS 时目标端用户的 UID 和源端不一样导致同步后的文件全部变成了 nobody。加一行--chownbackupuser:backupgroup就解决了。另外符号链接和权限的同步也有坑。默认-a会保留符号链接本身但如果链接指向的绝对路径在目标端不存在链接仍然会保留只是指向无效目标。用-L可以跟随符号链接直接复制链接指向的内容而不是链接本身。是做镜像同步还是做内容同步决定了选哪个参数。6. 我对 rsync 使用场景的最终体会rsync 最强大的地方不仅在于它能同步而在于它给了你足够多的可控参数让你能定义一套完全适合自己的同步策略。有人只需要一条最简单的rsync -av有人需要组合--delete、--link-dest、--bwlimit才能满足复杂的备份和发布需求。我个人的体会是每个新项目首次使用 rsync 前先别急着把命令写进定时任务里。先跑几次dry-run确认文件列表、删除列表、排除范围都符合预期再落地到生产环境。这个习惯救了我太多次了尤其是面对海量目录结构和多个环境不一致的情况。如果你刚开始接触 rsync建议从本地目录同步开始练习把-a各个子选项的含义搞清楚再尝试远程同步和定时备份。等你理解了--link-dest和--delete的搭配技巧你基本上就能在 Linux 世界里“一套 rsync 走天下”了。最后再分享一个小技巧任何重要的同步命令第一次执行时给目标端做一个 tar 快照。这一步多花几分钟但永远不嫌多。