在Linux圈子里混久了rsync这个命令几乎没有人不认识。但大多数人只是把它当作一条命令敲几下真正把它变成一段能定时跑、带日志、能断点续传、误删还能兜底的文件同步脚本能讲清楚的人其实不多。这篇文章想跟你聊聊我这些年基于rsync写文件同步脚本的完整经验从参数选型到脚本骨架从快照增量备份到问题排查尽量把每一个为什么都讲透。如果你刚接触Linux运维或者一直想用脚本替代手工备份、手工发布的开发同学这篇应该能帮你少踩不少坑。rsync能解决的痛点一句话就能说清本地和远程文件保持一致但每次只传输变化的那部分而不是推倒重来。这个增量特性在数据量大、网络带宽有限、定时任务频繁的场景下价值是碾压级的。下文所有经验都是我在真实服务器环境里验证过的可以直接抄作业。1. 同步场景梳理与方案选型1.1 认识rsync增量同步解决什么问题rsync这名字拆开就是remote sync远程同步。但它的本事远不只是同步两个字核心杀手锏是增量传输算法。它会先把文件切成固定大小的数据块对每一块计算弱校验和与强校验和目标端拿这些校验值跟自己这边的文件分块做比对只把存在差异的块传过去整个文件不用重新传一遍。这个机制在备份大文件、跨服务器同步频繁变动的日志、发布代码包时效果立竿见影。拿生活打比方这就好比你搬家到同一个小区的另一栋楼你不可能把全部家具重新买一遍而是先列个清单到新家一看哪些是好的可以直接搬哪些坏了必须换哪些缺了需要补最后只对有问题的部分下手。rsync的比对逻辑就是那个清单而且它连清单都是分块做的文件越大、改动越小效率差距就越夸张。1.2 三种典型同步场景从我经手的实际需求看Linux下的文件同步基本逃不出下面三种场景。第一种是本机目录到目录的备份例如把业务目录复制到另一块数据盘。这种场景没有网络开销最简单但仍然要处理权限保留、增量备份、历史版本这些问题。第二种是服务器之间的远程同步常见于代码发布、日志汇聚、数据库备份文件拉取。它额外引入网络不确定性需要考虑SSH认证、断线重传、带宽限速、超时处理。第三种是快照式多版本备份。同一个目录每天同步一次既要保留每一天的完整状态又不能把磁盘撑爆。这种场景靠普通rsync命令根本做不了必须用--link-dest做硬链接增量。写脚本之前我强烈建议先把需求归类到这三种之一。因为不同场景的参数选择、脚本结构、容错策略完全不同混着写很容易搞出个又长又难维护的怪物。1.3 为什么是rsync而不是cp或scp很多人会问备份目录用cp -r远程传文件用scp不行吗小场景确实够用规模一上来就露馅了。cp不支持断点续传。传输到一半机器重启或网络断了从头再来。一个几十GB的大文件半夜备份卡在99%第二天起来发现白跑一整晚这种事遇到一次就再也不想用cp做备份了。scp更直接它压根不做增量比较每次都是整文件全量传输。一个持续增长的日志目录每天新增几百MBscp会把历史几天甚至几周的日志也重新传一遍。rsync则只挑新增和变化的字节块第一天全量是20GB第二天可能就只有几百MB。另外rsync自带校验机制可以识别远端文件跟本地是否真的完全一致。代码发布到多台机器时这个确定性非常重要而scp没有这种双向校验能力。所以我的结论很明确rsync不是更好用的cp而是为同步而生的协议加工具做脚本化、自动化几乎是唯一选择。2. 核心参数拆解把每个rsync选项吃透2.1 最经典的参数组合rsync参数非常多但日常用到的核心也就十几个。我先把最常用、最容易踩坑的整理成一张表然后挑重点细讲。参数作用常见陷阱-a归档模式等价于-rlptgoD保留权限、属主、时间戳等单独使用时看不出子项各自影响什么-v输出同步过程详情日志量大时占空间-z传输时压缩对jpg、mp4等已压缩格式几乎无收益-P等价于--progress加--partial显示进度且支持断点续传很多人不知道断点续传靠它--delete删除目标端多余文件让目标严格镜像源端最危险参数误删灾难源头--exclude / --exclude-from排除指定文件或目录匹配模式相对路径加斜杠的坑很多-e指定远程shell常用-e ssh -p 2222端口参数放错位置会连不上--link-dest做快照式增量备份的关键跨文件系统时硬链接会失效--bwlimit限制传输带宽单位是KB/s单位理解错会导致限速效果不符合预期--timeout无数据流动时超时断开不设可能任务永久挂起最基础也最实用的一条命令长这样rsync -avzP /data /backup这条命令的含义是归档模式加详细输出加压缩加进度显示和断点续传非常万能。但这里马上引出一个关键坑/data和/data/结尾有没有斜杠语义完全不同。rsync -avzP /data /backup会把data目录本身拷到backup下面结果路径是/backup/data而rsync -avzP /data/ /backup是把data目录里面的所有内容直接放进 /backup结果路径是 /backup/xxx。这个我后面第5章会单独展开。2.2 --delete一把双刃剑--delete参数的效果是让目标目录严格镜像源目录源端没有的文件目标端一律删除。做代码发布、精确镜像时非常爽同步完两边绝对一致。但它是数据安全领域的头号杀手。我见过不止一次事故源目录由于挂载异常变成空的或者脚本里路径写错rsync一执行--delete瞬间把目标目录清得干干净净。这可不是开玩笑人在工位坐锅从天上来。所以我的铁律有三条第一首次同步、脚本改动后第一次真跑永远不要加--delete先用干跑模式确认到底会删什么文件。第二非要用--delete时目标目录必须留一份独立的历史备份不要把唯一的宝押在这一个目录上。第三脚本里对源目录做非空校验源目录被判断为空或小于某个阈值时直接中止执行不让rsync有机会执行删除。这个方案我用了很久稳稳当当。后面第3章的脚本示例里就有对应的实现。2.3 --exclude排除规则不是所有文件都要同步缓存目录、临时文件、编辑器锁文件这些在同步时通常不需要。--exclude参数后面跟匹配模式可以把它们滤掉。推荐把排除规则集中写到一个独立文件里用--exclude-from引用比如rsync -avzP --exclude-from/etc/rsync_exclude.txt /data /backup规则文件每行一个模式。这里有个很容易翻车的点--exclude cache/ 和 --exclude /cache/ 看起来差不多效果完全不同。前者匹配任意层级下的cache目录后者只匹配源目录根下的cache目录。写规则时想清楚相对路径的基准否则你会看到日志里明明写了排除目标目录里却还是冒出了cache。还有一个进阶玩法用--include配合--exclude做白名单式同步。比如只同步源码和配置不要node_modules和build目录可以这样写rsync -avzP --include*/ --include*.js --include*.json --exclude* /data/ /backup/注意这里必须先include再exclude顺序就是rsync逐条匹配的优先级。这个技巧在精准同步时非常有用。2.4 远程同步必须掌握-e ssh远程同步最常用的形态是把本地目录推到远端服务器rsync -avzP -e ssh -p 2222 /data/ user192.168.1.100:/backup/这里的-e参数指定使用ssh作为远程传输通道并可以携带端口号。如果端口就是默认22可以不写-e ssh但写上更清晰。生产环境我强烈建议把SSH配置写进~/.ssh/config比如给目标主机定义一个别名脚本里直接rsync -avzP /data/ backup-server:/backup/这样脚本干净密钥、端口、超时配置都收拢在ssh config里统一维护。远程同步一个关键前提是两端都要装rsync如果走ssh方式目标端必须有rsync命令可用。另外脚本扔到cron里定时执行时绝对不会有人工输入密码的机会所以一定要提前配好SSH密钥免密登录否则半夜任务卡在密码输入上第二天一看白跑。3. 脚本编写实战从零搭建一个生产级同步脚本3.1 写脚本之前先想清楚需求边界很多人的同步脚本是写到哪儿算哪儿先写rsync一行命令再慢慢拼凑。我自己的习惯是先列出它必须满足什么源目录、目标目录、排除规则、日志路径、阈值全部抽成变量或配置文件不能写死在命令里。日志必须能追溯每轮同步执行了多久、传了多少文件、成功还是失败要有据可查。出错必须能报警不能静默失败。同一时间只能有一个同步任务运行防止上一轮还没跑完下一轮又启动两边同时写文件造成数据错乱。关键同步操作必须能安全演练也就是dry-run模式先看出效果再执行。这五条缺一不可。把这些边界定清楚脚本骨架自然就出来了。3.2 脚本骨架、配置区与执行区解析我给出一个可以直接拿去改的生产级脚本骨架。它支持配置区、源目录非空保护、flock防重入、完整退出码处理和dry-run开关#!/usr/bin/env bash # # 通用文件同步脚本 # 依赖: rsync, flock (util-linux) # 用法: ./sync_data.sh [--dry-run] # set -euo pipefail # ---------- 配置区 ---------- SRC_DIR/data/project DEST_DIR/backup/project EXCLUDE_FILE/etc/rsync_exclude.txt LOG_BASE/var/log/rsync-sync LOG_FILE${LOG_BASE}/sync_$(date %Y%m%d).log LOCK_FILE${LOG_BASE}/.sync_project.lock MIN_SRC_SIZE104857600 # 100MB按实际场景调整 # ---------- 参数解析 ---------- DRY_RUNfalse if [[ ${1:-} --dry-run ]]; then DRY_RUNtrue fi # ---------- 准备区 ---------- mkdir -p $LOG_BASE # 防重入锁 exec 9$LOCK_FILE if ! flock -n 9; then echo [ERROR] $(date %F %T) 已有同步任务运行本次退出。 $LOG_FILE exit 1 fi # 源目录存在性校验 if [[ ! -d $SRC_DIR ]]; then echo [ERROR] $(date %F %T) 源目录不存在: $SRC_DIR $LOG_FILE exit 1 fi # 源目录非空校验防止误删目标 SRC_SIZE$(du -sb $SRC_DIR | awk {print $1}) if [[ $SRC_SIZE -lt $MIN_SRC_SIZE ]]; then echo [ERROR] $(date %F %T) 源目录异常小于阈值拒绝执行 $LOG_FILE exit 1 fi mkdir -p $DEST_DIR # ---------- 执行区 ---------- RSYNC_ARGS(-avzP --delete --exclude-from$EXCLUDE_FILE --timeout60 --log-file$LOG_FILE) if [[ $DRY_RUN true ]]; then RSYNC_ARGS(--dry-run) fi rsync ${RSYNC_ARGS[]} $SRC_DIR $DEST_DIR RESULT$? # ---------- 结果区 ---------- if [[ $RESULT -eq 0 ]]; then echo [INFO] $(date %F %T) 同步成功 $LOG_FILE else echo [ERROR] $(date %F %T) 同步失败rsync退出码$RESULT $LOG_FILE # 这里调用你自己的告警函数比如 webhook 或邮件 fi exit $RESULT注意两点。第一rsync参数我用数组而不是字符串拼接这是刻意为之如果路径含有空格或特殊字符只有数组方式才能保证参数不被错误切开任何字符串拼命令的做法都算偷懒。第二源目录非空校验阈值我放在了变量里如果业务本身源目录很小就把MIN_SRC_SIZE调小不要删除这个校验逻辑。脚本里set -euo pipefail是bash安全三板斧遇到未定义变量、管道错误都会退出避免脚本在错误状态继续跑。db备份场景、发布场景我都见过因为没有set -e导致rsync失败后脚本依然执行后续逻辑的惨案这个开头三行务必带上。3.3 定时任务与告警通知脚本写好后用cron调度。编辑crontabcrontab -e加入一行0 2 * * * /usr/local/bin/sync_data.sh /dev/null 21这表示每天凌晨2点整执行。注意脚本内部已经写了自己的日志cron这里就不需要再重定向到文件否则会跟脚本里的日志混在一起。如果你想让cron自己留一份就重定向到另一个独立文件避免下次排查时翻出两份半截日志犯迷糊。告警这块最小可用方案是加一个函数function send_alert() { local msg$1 curl -s -X POST https://example.com/notify \ -H Content-Type: application/json \ -d {\text\:\$msg\} }把example.com换成你们内部的消息通道地址即可。我习惯只把失败情况发通知成功不发否则每天一封同步成功邮件会让人逐渐麻木等到真正失败那封也会被当成垃圾邮件忽略。告警要稀缺才有价值。3.4 快照式增量备份--link-dest的正确玩法这是rsync最容易被低估的功能之一。普通增量备份只保留最新状态历史版本一覆盖就没了快照式增量备份则每天生成一个看起来完整的目录但内部未变化的文件全部通过硬链接指向前一天的物理文件实际磁盘占用只有每天真正变化的数据量。命令核心是这样的SNAP_BASE/backup/project_snapshot LAST_SNAP$(ls -d ${SNAP_BASE}/snapshot_* 2/dev/null | tail -n 1) TODAY${SNAP_BASE}/snapshot_$(date %Y%m%d) mkdir -p $TODAY if [[ -z $LAST_SNAP || $LAST_SNAP $TODAY ]]; then rsync -avP --delete $SRC_DIR $TODAY/ else rsync -avP --delete --link-dest$LAST_SNAP/ $SRC_DIR $TODAY/ fi逻辑很简单第一轮没有历史快照做全量之后每一轮都把上一个快照作为--link-dest基准。rsync比对时发现某个文件跟基准文件一致就会在今天的目录里创建一个指向该文件的硬链接不再重新传输和写盘。只有真正变化的文件才会占用新的磁盘空间。这背后有个硬性前提硬链接必须在同一个文件系统内--link-dest和今天的新目录必须落在同一块分区下。如果你把snapshot_base放在NFS或者另一块挂载盘上会看到rsync报错或退化成整文件复制那这个方案就失去意义了。清理旧快照用find配合-mtime即可保留30天就写find $SNAP_BASE -maxdepth 1 -name snapshot_* -mtime 30 -exec rm -rf {} 。4. 进阶玩法增量原理、限速与性能调优4.1 rsync为什么快增量同步背后的算法直觉理解了增量算法你就明白rsync设计上的精妙之处。它把要传输的文件在源端切成固定大小的数据块每块算两个校验值一个弱校验和一个强校验。目标端同样把自己的已有文件切成对应的块并计算校验值先拿弱校验快速比对弱校验一样的再拿强校验确认只有两边不一致的块才进入真正的网络传输。更有意思的是目标端扫描时用的是滚动校验窗口意味着它在文件里滑动扫描不需要为了比对某一块而重新读整个文件。打个比方你写作文被老师改了一句话改完后你只需要把那句话所在的段落重新誊一遍而不是整篇作文重新抄一次。rsync做的事情就是精准定位到哪个段落变化了而且段落改得越小省下的传输量越夸张。这个原理还能解释一个常见现象一个大文件哪怕只是中间改了几个字节rsync也能识别出只有附近的小块需要重传整个文件几十GB也只传几十KB。很多第一次用rsync的人看到这个结果会觉得不可思议其实算法早就铺好了路。4.2 带宽限制、超时与断点续传生产环境的网络带宽往往不是专线白天跑任务不能影响线上业务。--bwlimit参数就是干这个的用法rsync -avzP --bwlimit5000 /data/ user192.168.1.100:/backup/这里的5000单位是KB/s也就是大约5MB/s。注意Linux命令里习惯把大K写成小k没有那么多讲究但很多人会把--bwlimit当成MB/s用结果限速效果跟预期差一千倍半夜把公司出口带宽打满。这个单位务必记住单位是KB/s写--bwlimit1024就是1MB/s左右。--timeout参数也很关键。它设置的是多少秒内没有数据流动就断开不是总超时时间。不加这个参数一旦对端网络卡死rsync进程会一直挂着不退出脚本里flock锁被占住后续轮次全部卡死。设个--timeout60加上脚本里的锁机制任务卡死也能被下一轮识别并跳过然后再告警让运维介入。断点续传靠-P参数里的--partial。如果没有--partialrsync传输中途中断时会删掉那个不完整的半成品文件下次运行从头开始传。加上它中断后的文件会被保留下一次执行rsync时从断点继续配合--append-verify还能对只增长的日志文件做更激进的追加传输。日志文件这种只追加不修改的场景用--append能省掉大量的文件头比对开销但要注意如果文件中间被截断或改写--append会直接造成数据错位这块我只能说慎用常规场景老老实实用-P就好。4.3 大量小文件同步太慢怎么办代码库、图片目录、静态资源目录动辄几万个甚至几十万个几KB的小文件。普通同步命令在这种场景下会奇慢无比因为rsync需要逐个文件建立列表、比较mtime和size、逐个建立连接网络往返次数多到让人崩溃。第一步建议加-z压缩。小文件即使内容本身压缩收益不大减少网络传输次数也是实打实的好处。如果源端和目标端都是Linux且文件格式是源码、文本、JSON这种压缩率会很可观。第二步如果小文件数量实在太大、内容也频繁全量变化换个思路先在源端打包成一个tar归档再同步这个归档文件。tar包是单个大文件rsync传输它时效率极高还能享受增量传输的收益。脚本里加一句tar -cf /tmp/project.tar -C /data project再同步tar包最后在目标端解包。这个方法在小文件几乎每次全变的场景下比rsync跑几万个小文件快一个数量级。第三步如果同步的是稳定目录里只有少量文件变化可以考虑用--files-from参数把要同步的文件清单提前生成让rsync不再全量扫描目录树。配合find和mtime条件find /data/project -type f -mtime -1 /tmp/filelist.txt rsync -avzP --files-from/tmp/filelist.txt /data/project/ user192.168.1.100:/backup/project/这种方式对每天只变化少量文件但要精准同步的场景特别有效。缺点是要先有清单适合对业务数据变更规律明确的环境不适合首次全量建立基线。5. 常见问题与排查技巧实录5.1 排除规则为什么没生效最常见的原因是路径基准理解错误。--exclude cache 匹配的是任意路径层级下的cache而 --exclude /cache 只匹配源目录根下的cache。如果你在规则文件里写了cache却发现目标目录每个子目录里的cache都被排掉了恭喜你这其实是符合预期执行的只是你没料到。另一个坑是排除规则和--delete叠加时的行为。普通--delete不会删除被排除的文件但如果加了--delete-excluded被排除的文件照样会被从目标端删除哪怕它们根本不是同步的产物。这个参数如果你的同步方案里没有明确理由不要碰。排查方法很简单先用--dry-run加--itemize-changes跑一遍看输出里每个文件的类型标记f和d代表文件和目录小写表示传输大写表示删除或更新。看到不预期的行为对照规则文件逐行检查基本都能找到问题。5.2 权限、属主属组和硬链接属性的坑归档模式-a默认会保留属主、属组、时间戳和权限。但如果你是普通用户身份运行rsync目标端文件的属主可能无法改成源端属主就会出现rsync: chown failed之类的报错。生产环境建议用具有sudo权限或root身份的定时任务来跑同步这个最省心。如果出于安全考虑只能用普通用户可以在-a后面追加--no-owner加--no-group来放弃属主属组同步只保留权限和时间戳。还有一个选择是--chownuser:group让目标端文件统一归属到指定用户适合多来源归集的备份目录。硬链接属性也值得注意。如果源目录里有硬链接文件默认rsync会把它们当作多个独立文件逐个复制白白浪费空间和时间。加-H参数才能保留硬链接结构。这个参数很小众但数据目录里硬链接多的时候不加-H目标端磁盘占用可能膨胀好几倍。5.3 中文文件名乱码问题Linux下正常使用UTF-8编码时rsync同步中文文件名没有任何问题。出现乱码往往发生在跨系统的场景比如从Linux同步到旧版rsync daemon或者目标端是Windows通过rsync兼容工具在做中转。排查时先看源端文件名的编码格式用ls | file -或者ls加cat -v怎么查都行确认是UTF-8。再看目标端挂载的文件系统、locale环境确保两边都支持UTF-8。老掉牙的解决方案里有个--iconv参数可以在同步时做编码转换比如从GBK转到UTF-8但那个参数涉及编码映射表配置错了反而会出现更诡异的错乱。我的建议是能不用就不用先统一两端系统编码为UTF-8这是治本的路子。5.4 结尾斜杠和多一层目录这是rsync新手最容易掉进去的坑也是排查别人脚本时一眼能看出功力的点。rsync -avzP /data /backup结果是 /backup/datarsync -avzP /data/ /backup结果是 /backup/下的内容就是/data下的内容rsync -avzP /data /backup/结果还是 /backup/datarsync -avzP /data/ /backup/结果还是内容直接进 /backup两头斜杠的作用完全不同源的斜杠决定传目录本身还是传目录内的东西目标的斜杠基本没有实质影响。脚本里统一建议把源和目标都写成目录加斜杠的形式语义更一致。如果某个脚本报多了一层目录或者文件全部铺开了第一反应先检查源路径结尾的斜杠。5.5 远程同步时SSH连接问题速查远程同步最容易失败的就是SSH连接环节。排查有一个固定顺序先手动SSH连接目标机器确认能通再看rsync命令里的端口参数有没有写对最后看远程目标端的rsync是否安装。有个内网环境特别容易翻车双方都在防火墙后面rsync基于ssh默认走22端口只要防火墙封了非标准端口或做了端口转发必须在-e参数里显式指定比如-e ssh -p 2222。如果SSH连接超时也可以直接用ssh config里设置的ConnectTimeout参数来控制这个对cron任务尤为重要否则ssh卡在认证阶段不放行rsync一直pendingflock又被占住整个链路都冻住了。远程端rsync缺失的表现是本地报rsync: connection unexpectedly closed而异步调试时手动ssh敲rsync命令提示command not found。解决方法是优先在目标机器上补装rsync或者改用挂载远端目录再本地同步的方案但后者不如直接rsync数据通路干净。5.6 误删数据之后的应急与预防真遇到--delete误删最忌讳的是慌张乱操作。第一件事立即停掉所有自动化任务包括cron里跟这个目录有关的任何脚本因为下一个周期任务很可能继续清空残余数据。第二件事检查有没有另一份独立备份或快照如果有按备份恢复。第三件事如果连备份都没有立刻把目标盘做成只读或镜像用数据恢复工具尝试找回文件这个成功率完全看运气的。但真正正确的做法是让误删根本没有机会发生。我的习惯是所有带--delete的同步脚本上线前先连续三天用--dry-run观察日志确认每次会删哪些文件每天自动同步后看一眼删除列表统计如果哪天删除文件数异常多立刻告警。加上脚本里那个源目录非空校验三管齐下误删事故基本可以被拦在发生之前。写在最后写了这么多年rsync脚本我最大的体会是rsync本身再强大也只是个命令真正决定数据安全的永远是包裹它的那一层脚本逻辑。工具可以出错脚本可以把错误挡在门外。最后分享一个沿用多年的小习惯每次改完同步脚本宁可多花三天时间跑dry-run也绝不直接上生产真跑。删除清单看得清清楚楚确认没有意外再放开执行这一步帮我避掉的灾比任何优化技巧都值钱。