1. 为什么增量拷贝是运维场景里的刚需干运维这行十来年文件同步这件事几乎贯穿了每一天的工作。不管是每天凌晨的数据库备份归档、跨机房静态资源分发还是本地开发目录往测试服务器推代码只要涉及“把一批文件从A搬到B”就绕不开一个核心诉求只传变化的部分别傻乎乎地全量重来。我第一次接触rsync是在一个图片站点的迁移项目里。当时有将近800GB的用户上传文件分布在十几台机器上如果按传统scp或者cp的方式全量拷贝光是网络传输就得跑一整天而且中途断了还得从头再来。后来换成rsync做增量同步第一次全量跑完之后后续每天只传新增和修改的那部分平均每次同步不到2GB几分钟就完事。这个差距用过一次就再也回不去了。rsync这个工具名字里的“rsync”其实是“remote sync”的缩写但它的能力远不止远程同步。它本质上是一个差异传输引擎核心算法能快速比对源端和目标端的文件差异只传输有变化的数据块。这个特性让它在备份、镜像、部署、迁移等场景里几乎成了标配工具。不管你是刚入行的运维新人还是写了十几年代码的老手只要涉及文件同步rsync都值得你花时间吃透。这篇文章我会从实际使用角度出发把rsync的核心机制、参数选择、实操流程、常见坑点全部拆开讲清楚。不会只列参数表而是告诉你每个参数背后的逻辑是什么、什么场景该用什么组合、踩过哪些坑。看完之后你应该能独立设计出一套靠谱的增量同步方案。2. rsync增量同步的核心机制拆解2.1 增量算法到底“增”在哪里很多人以为rsync的增量就是“对比文件修改时间变了就传”。这个理解只对了一半。rsync的增量算法业内叫rsync算法其实分两个层面第一个层面是文件级增量。rsync默认会检查文件的大小和修改时间mtime如果两者都没变就直接跳过这个文件。这是最粗粒度的增量速度快但不够精确。比如你只是用touch改了文件的mtime但内容没变rsync还是会认为它变了。第二个层面是块级增量。当rsync判定一个文件需要同步时它不会直接传整个文件而是把目标端已有的文件切成固定大小的块默认块大小根据文件大小动态计算对每个块计算弱校验和rolling checksum和强校验和MD5或xxhash。源端拿到这些校验和后在自己的文件里滑动窗口比对只把目标端缺失的块传过去。这就是为什么rsync在同步大文件的小改动时特别高效——比如一个1GB的日志文件只追加了几行rsync可能只传几十KB。注意块级增量只在目标端文件已存在且源端目标端都支持校验和比对时生效。如果目标文件不存在那就是全量传输。2.2 为什么rsync比scp和cp更适合日常同步我做过一个简单的对比测试在同一局域网内同步一个包含5万个文件的目录其中只有200个文件有改动工具传输方式耗时网络流量cp -r全量复制约4分钟全部文件scp -r全量传输约6分钟全部文件rsync -a增量同步约12秒仅变化文件rsync -a --delete增量删除约14秒仅变化文件差距非常明显。cp和scp每次都是全量操作文件越多越慢。rsync先做快速比对只处理有差异的部分。而且rsync支持断点续传、压缩传输、排除规则、带宽限制这些在实际运维里都是刚需。还有一个容易被忽略的点rsync在传输过程中如果中断重新执行时会从上次中断的地方继续比对而不是从头再来。这对于跨广域网的同步任务来说能省下大量时间和流量。2.3 守护进程模式与SSH模式的选择逻辑rsync有两种主要的工作模式选哪种直接决定了你的配置复杂度和使用体验。SSH模式是最简单的直接通过SSH通道传输不需要在目标端跑任何额外服务。命令形式就是rsync -avz /local/path userhost:/remote/path。适合临时同步、个人使用、少量机器之间的场景。缺点是每次都要走SSH认证大批量机器管理时比较麻烦。守护进程模式需要在目标端启动rsync服务默认端口873通过配置文件定义模块module源端用rsync -avz /local/path rsync://host/module/的方式连接。适合多台机器集中备份、需要精细权限控制的场景。可以配置只读、只写、指定用户、IP白名单等。我个人的选择逻辑是如果只是两三台机器之间偶尔同步SSH模式足够了如果是十几台以上的集群做定期备份或者需要给不同团队分配不同目录的访问权限那就上守护进程模式。守护进程模式虽然配置麻烦一点但后续管理成本低很多。3. 核心参数与实操配置详解3.1 必须掌握的八个核心参数rsync的参数有上百个但日常用得最多的就那么几个。我把它们分成三组方便记忆。第一组基础同步行为-a归档模式等价于-rlptgoD保留符号链接、权限、时间戳、属主、属组、设备文件。这是最常用的组合几乎每次都会带上。-v详细输出显示同步了哪些文件。调试时必带生产脚本里可以换成-q减少日志量。-z传输时压缩。对于文本类文件效果明显但压缩本身消耗CPU。如果是在内网千兆环境传大量小文件压缩反而可能拖慢速度。第二组增量控制-u跳过目标端比源端新的文件。防止用旧文件覆盖新文件做单向同步时建议加上。--delete删除目标端有但源端没有的文件。做镜像同步时必须加但用之前一定要确认方向删错了就麻烦了。--exclude和--include排除和包含规则。支持通配符可以写多个。规则顺序很重要先匹配到的先生效。第三组传输控制-P等价于--partial --progress支持断点续传并显示进度。大文件传输时强烈建议加上。--bwlimit限制带宽单位是KB/s。比如--bwlimit5000就是限制在5MB/s左右。避免同步任务把带宽跑满影响其他服务。3.2 一个完整的增量备份脚本拆解下面这个脚本是我在一个日志归档项目里实际用过的简化版每天凌晨3点执行把应用服务器的日志目录同步到备份服务器。#!/bin/bash # 定义变量 SOURCE_DIR/data/app/logs/ TARGET_HOSTbackup-server TARGET_DIR/backup/logs/ LOG_FILE/var/log/rsync_backup.log DATE$(date %Y%m%d) # 执行同步 rsync -avz --delete \ --exclude*.tmp \ --excludecache/ \ --bwlimit10000 \ -e ssh -p 22 -o StrictHostKeyCheckingno \ $SOURCE_DIR \ $TARGET_HOST:$TARGET_DIR \ $LOG_FILE 21 # 检查执行结果 if [ $? -eq 0 ]; then echo [$DATE] Sync completed successfully $LOG_FILE else echo [$DATE] Sync failed with exit code $? $LOG_FILE fi这个脚本里有几个细节值得说SOURCE_DIR末尾的斜杠很关键。带斜杠表示同步目录里的内容不带斜杠表示同步目录本身。比如/data/app/logs/同步的是logs下面的所有文件而/data/app/logs会在目标端创建logs目录再放文件。这个区别在第一次配置时特别容易搞混。--exclude规则我加了两个一个是排除临时文件一个是排除缓存目录。实际使用中排除规则能大幅减少无效传输。比如Java应用的logs目录里经常有大量.tmp和.gz文件如果不需要归档压缩文件也可以加一条--exclude*.gz。-e参数用来指定SSH选项。StrictHostKeyCheckingno在脚本自动化场景里很有用避免首次连接时交互式确认主机指纹。但要注意这会降低安全性内网可信环境可以用公网环境建议提前把主机密钥加到known_hosts里。3.3 守护进程模式的配置文件写法如果机器数量多建议在目标端配置rsync守护进程。配置文件默认在/etc/rsyncd.conf一个典型的配置如下uid nobody gid nobody use chroot yes max connections 10 pid file /var/run/rsyncd.pid log file /var/log/rsyncd.log [backup] path /backup/data comment Backup module read only no list yes auth users backupuser secrets file /etc/rsyncd.secrets hosts allow 192.168.1.0/24 hosts deny *几个关键配置项的解释use chroot yes把rsync进程限制在指定目录内防止路径穿越。read only no允许写入如果只做拉取备份可以设为yes。auth users和secrets file配合使用做认证密码文件权限要设为600。hosts allow做IP白名单只允许内网网段访问。对应的密码文件/etc/rsyncd.secrets格式是用户名:密码一行一个用户。源端连接时需要提供密码可以用--password-file指定密码文件避免交互式输入。启动命令是rsync --daemon或者用systemd管理。记得在防火墙里放行873端口但只对可信网段开放。4. 实操流程与典型场景实现4.1 首次全量同步的准备工作第一次做rsync同步时不管配置多好本质上都是全量传输。这时候有几个准备工作能帮你省不少事。评估数据量和网络带宽。先统计源目录的总大小和文件数量估算传输时间。比如500GB数据在千兆内网理论最快约70分钟但实际受磁盘IO和小文件影响可能要2-3小时。如果时间窗口不够考虑先做本地拷贝再增量同步。检查目标端磁盘空间。用df -h确认目标分区剩余空间大于源数据量留出至少20%余量。rsync在传输过程中会创建临时文件空间不足会导致同步中断。确认文件权限和属主。如果目标端没有对应的用户和组-a参数会报错。可以先用--dry-run试跑一遍看看有没有权限问题。--dry-run加上-av可以模拟同步过程只显示会做什么但不实际执行非常适合首次配置时验证。rsync -av --dry-run /source/ userhost:/target/这个命令跑完会列出所有会被同步的文件以及任何权限或路径问题。确认无误后再去掉--dry-run正式执行。4.2 大文件传输的断点续传配置传大文件最怕中断。我之前传一个200GB的数据库备份文件跑了两个小时断了如果没有断点续传就得从头再来。rsync的--partial参数会把已传输的部分保留下来下次执行时从断点继续。完整的大文件传输命令建议这样写rsync -avzP --bwlimit20000 \ --timeout600 \ /data/backup/db_full.tar.gz \ backup-server:/backup/db/-P包含了--partial和--progress既支持断点续传又显示进度条。--timeout600设置IO超时时间为600秒避免网络卡死时进程一直挂着。--bwlimit20000限制在20MB/s给其他业务留出带宽。如果传输过程中断了重新执行同样的命令即可。rsync会检查目标端已有的部分文件从断点继续。实测下来200GB的文件断三次续三次最终完整传完没有出现校验错误。4.3 定时增量同步的完整落地方案生产环境里rsync通常是配合定时任务跑的。我以“每天凌晨2点同步Web静态资源”为例把完整流程走一遍。第一步配置SSH免密登录。在源端生成密钥对把公钥放到目标端的~/.ssh/authorized_keys里。这样定时任务执行时不需要交互输入密码。ssh-keygen -t ed25519 -N -f ~/.ssh/rsync_key ssh-copy-id -i ~/.ssh/rsync_key.pub usertarget-host第二步编写同步脚本。放在/opt/scripts/rsync_web.sh内容如下#!/bin/bash SOURCE/data/www/static/ TARGETusertarget-host:/data/www/static/ KEY/root/.ssh/rsync_key LOG/var/log/rsync_web_$(date %Y%m).log rsync -avz --delete \ --exclude.git/ \ --excludenode_modules/ \ -e ssh -i $KEY -o StrictHostKeyCheckingno \ $SOURCE $TARGET $LOG 21 echo $(date %Y-%m-%d %H:%M:%S) exit$? $LOG第三步配置crontab。执行crontab -e添加一行0 2 * * * /bin/bash /opt/scripts/rsync_web.sh第四步验证和监控。第一次跑完后检查日志文件确认没有报错。后续可以加一个简单的监控比如每天检查日志里是否有exit0没有就发告警。这个方案跑了大半年每天同步时间从最初的几分钟逐渐稳定在30秒以内因为大部分文件都没变rsync只处理新增和修改的部分。5. 常见问题排查与避坑经验5.1 同步速度慢的六个排查方向rsync速度慢是最常见的问题原因可能有很多。我整理了一个排查顺序从最可能的原因开始查。排查项检查方法优化建议小文件过多find /path -type f | wc -l打包成大文件再传或调大--block-size压缩开销大去掉-z测试对比内网传输建议去掉-z磁盘IO瓶颈iostat -x 1看%util错开高峰时段或换SSD网络带宽限制iftop或nload观察调整--bwlimit或升级带宽校验和计算慢换--checksum-choicexxh128用更快的哈希算法SSH加密开销换-e ssh -c aes128-gcmopenssh.com用更快的加密算法其中小文件过多是最隐蔽的。rsync对每个文件都要做一次比对和可能的传输文件数量多的时候元数据操作的开销远大于数据传输本身。我遇到过同步10万个1KB文件比同步10个1GB文件还慢的情况。这种场景建议先用tar打包再传到目标端解包。5.2 --delete参数误删的预防措施--delete是双刃剑用好了能保持两端完全一致用错了就是灾难。我踩过一次坑源端目录挂载失败变成了空目录rsync执行后把目标端的所有备份文件全删了。预防措施有三条第一永远先用--dry-run验证。加上--dry-run和-v看看会删除哪些文件。确认无误再正式执行。第二加--max-delete限制。比如--max-delete100一次最多删100个文件超过就中止。这样即使出问题也不会全删光。第三源端加保护判断。在脚本里先检查源目录是否存在且非空不满足条件就退出。if [ ! -d $SOURCE ] || [ -z $(ls -A $SOURCE) ]; then echo Source directory is empty or missing, aborting. exit 1 fi这三条加上之后再也没出过误删事故。5.3 权限和属主同步的常见报错用-a参数时rsync会尝试保留文件的属主和属组。如果目标端没有对应的用户或组会报rsync: chown failed: Invalid argument之类的错误。文件内容其实传过去了但权限不对。解决方法有两种一是目标端提前创建好对应的用户和组二是如果不需要保留属主把-a换成-rlptD去掉-o和-g。或者加--no-owner --no-group显式禁用。还有一种情况是SELinux导致的权限问题。目标端如果开了SELinuxrsync写入的文件可能没有正确的安全上下文。可以加--chmod参数调整权限或者同步后用restorecon修复上下文。5.4 断点续传失效的原因分析有时候加了-P参数断点续传还是不生效。常见原因有三个一是目标端文件被删了。--partial依赖目标端已有的部分文件如果被清理掉了就只能从头传。二是用了--inplace参数。--inplace是直接写入目标文件不创建临时文件和--partial有冲突。大文件传输建议用默认的临时文件方式。三是文件在传输过程中被修改了。如果源端文件在传输期间发生了变化rsync会认为校验和不匹配重新传输。这种情况只能等文件稳定后再传。6. 进阶技巧与性能调优6.1 用--files-from做精确文件列表同步有时候不需要同步整个目录而是根据一个文件列表来同步。比如只同步最近修改过的文件或者只同步某个清单里的文件。--files-from就是干这个的。# 生成文件列表 find /data -type f -mtime -7 /tmp/recent_files.txt # 按列表同步 rsync -avz --files-from/tmp/recent_files.txt / userhost:/backup/注意--files-from里的路径是相对于源目录的。如果列表里是绝对路径源目录参数要用/。这个技巧在做选择性备份时特别有用比如只备份最近一周的日志或者只备份特定类型的文件。6.2 多线程并行同步的思路rsync本身是单线程的同步大量文件时CPU和网络可能跑不满。一个常用的优化思路是按目录拆分起多个rsync进程并行跑。# 按子目录并行同步 for dir in /data/project/*/; do rsync -avz $dir userhost:/backup/project/ done wait这样每个子目录一个进程能充分利用多核和带宽。但要注意控制并发数太多进程反而会互相抢IO。一般建议并发数不超过CPU核数或者用xargs -P来控制。6.3 校验和算法的选择与性能影响rsync默认用MD5做块校验MD5虽然安全但速度一般。在信任的内网环境里可以换成更快的xxhash算法。rsync -avz --checksum-choicexxh128 /source/ userhost:/target/实测下来xxh128比MD5快30%到50%特别是在大文件同步时差距明显。如果两端rsync版本都支持3.2.0以上建议默认用xxh128。如果版本较老可以用--checksum-choicexxh64或者保持默认。还有一个相关参数是--checksum它会强制对所有文件做完整校验而不是只比对大小和时间。这个参数会让同步变慢很多只在需要绝对确认文件一致性的场景下使用比如金融数据的备份校验。6.4 日志分析与同步质量监控rsync的日志默认输出到stdout重定向到文件后可以分析。我一般关注几个指标传输的文件数、总字节数、耗时、是否有错误。# 从日志中提取统计信息 grep sent.*received.*bytes /var/log/rsync.log | tail -1输出类似sent 123456 bytes received 7890 bytes 26292.00 bytes/sec可以算出实际传输速率。如果发现某天的传输量突然增大可能是源端有异常改动值得排查。更完善的监控可以结合--stats参数它会输出详细的统计信息包括文件数量、匹配数量、传输数量等。把这些数据采集到监控系统里能提前发现同步异常。7. 个人实操心得与建议rsync这个工具参数多、组合灵活刚开始用容易懵。我的建议是先掌握-avz和--delete这四个最核心的把基本同步跑通再逐步加其他参数。不要一上来就堆一堆参数出了问题都不知道是哪个引起的。另外任何涉及--delete的操作不管多熟练都先跑一遍--dry-run。这个习惯帮我避免了好几次事故。还有生产环境的同步脚本一定要加日志和退出码检查不然出了问题都不知道。最后说一个容易被忽略的点rsync的版本兼容性。源端和目标端的rsync版本最好一致至少大版本相同。我遇到过老版本不支持新参数导致同步失败的情况排查了半天才发现是版本问题。用之前先rsync --version确认一下两端的版本能省不少事。