搞运维的人迟早都会撞上“数据同步”这道坎。不管是把代码推到多台机器上还是把日志定期归档到备份机甚至是给客户做异地灾备这几个场景里最常被拉出来干活的工具就是rsync。rsync这名字乍看像“远程同步”的缩写实际它的本事远不止同步两台机器它可以在本地、可以通过远程Shell、也可以用专门的同步协议把数据从一处搬到另一处而且只搬“有变化的部分”。这正是它能在众多复制工具里站稳脚跟的核心原因。这篇文章就围绕“rsync远程同步”这件事先把原理层面讲透再用一套模拟实验环境从最基础的命令到免密配置、定时任务再到用daemon模式搭一个可对内服务的同步节点一步一步带你把整个体系搭起来。最后我还会把这几年来在线上环境里踩过的坑、常用的排查姿势和一句顶一万句的注意点都撂出来。不管你是刚学Linux的小白还是已经写过不少脚本的运维新人这篇都可以当成一份能直接抄作业的实践手册。1. rsync 到底是什么它凭什么成为同步首选1.1 一个工具解决三类同步需求rsync 能火这么多年不是因为它参数多、看着高级而是它把“同步”这件事分得很清楚。常见的同步需求无非三类第一类是全量复制就是把整个目录原封不动搬到目标位置第二类是增量同步只把源端新增或改动的文件传过去第三类是镜像同步也就是在增量同步的基础上把目标端那些源端已经没有的“多余文件”删掉让两边保持一致。rsync 对这三种场景都能应对核心命令是同一个区别只在参数和模式选择上。举一个很直观的例子。假设源端有一个 10G 的数据库备份文件第一次用 rsync 传到备份机它会老老实实传 10G第二次改动了其中几百K的内容再跑一次同一命令rsync 不会傻到把整个 10G 再传一遍而是通过文件分块对比只把有差异的小块数据和重建指令传过去。这个特性在跨机房、带宽金贵、文件动不动几个G的场景里简直就是救命稻草。1.2 rsync 与 scp、cp、tar 等工具的分工区别很多初学者会问scp 不是也能远程传文件吗cp 不是也能复制吗tar 加管道也可以做远程备份为什么非要 rsync这个问题我认真对比过多次。scp 是加密通道上传输文件的“搬运工”它不考虑目标目录里已经有什么每次都从头传文件一大了就很吃亏。cp 则完全只在本地做事跨机器还得靠 NFS 或 sshfs 这种方式间接实现绕来绕去还容易出权限问题。tar 加 ssh 管道可以把多个小文件打包传输对小文件多的目录有些优势但断点续传、增量比较、目标端清理这些能力基本没有。所以实际选型时可以这么看只是偶尔传两个文件用 scp 图个简单要天天执行、还要自动清理目标端、每次只传差异数据那就老老实实用 rsync。下面这张表是我自己整理的对比方便快速决策。工具是否支持增量是否支持删除同步是否加密传输适合场景cp部分-u按时间否不涉及本地复制scp否否是少量文件远程传输tarssh否否是大量小文件打包搬运rsync是是依赖远程Shell持续同步、镜像、备份2. rsync 的同步原理与核心选项拆解2.1 增量传输算法到底做了什么rsync 最值钱的算法是它在传输文件时先判断“目标端这个文件是否已经有了”。如果目标端已经有同名文件rsync 会先把目标文件、源文件各自切成若干固定大小的数据块对每个块计算弱校验码和强校验码。先拿弱校验码在两边比对碰撞了再用强校验码二次确认。比对完之后源端只把目标端缺失的块以及如何重新拼装这些块的结构信息发过去目标端收到后自己动手重组文件。这个机制说起来抽象其实可以类比成两个人各拿一本书要核对哪些地方不一样不可能把整本书重新抄一遍。两个人都先把书按每行拆开报出每一行的“指纹”一比对就知道第几行变了、第几行没变最终只需要把变化的那几行和页码信息传过去就够了。rsync 传大文件时干的就是这个活。不过有两点要特别注意。一是文件太小的时候比如几百字节的文件分成若干块再对比反而浪费rsync 会自动按整文件处理。二是如果两边文件内容差异巨大分块对比的优势会被削弱最坏情况下传输量接近整文件。所以在设计同步策略时不要以为有个 rsync 就可以完全忽略带宽消耗关键场景还是得靠实际测试数据说话。2.2 模式与地址格式别搞混了再传错rsync 支持两种典型模式。第一种是远程Shell模式走的是 ssh 通道语法形如rsync -avz /源目录/ user目标主机:/目标目录/好处是天然加密只要目标主机能 ssh 登录就能用不需要额外启动专门服务。第二种是 daemon 模式由目标主机跑一个 rsyncd 服务监听 873 端口语法上使用两个冒号形如rsync -avz /源目录/ rsync://user目标主机/模块名/或者user目标主机::模块名/。daemon 模式的配置可控性强可以做只读模块、访问白名单、独立账号体系适合搭建面向多台客户端的同步中心。这里最容易翻车的地方就是地址里单冒号和双冒号到底用哪个、源路径末尾加不加斜杠以及 daemon 模式下模块名和真实路径的映射关系。我见过不止一次因为源路径少写了一个尾斜杠结果整个目录被多套了一层或者因为地址写错了报错半天找不到原因。记住了单冒号用的是远程Shell双冒号是 daemon这个一眼就能分辨。2.3 常用参数的功能与选择逻辑rsync 的参数很多但常用的就那二三十个绝大多数场景根本用不到冷门参数。我先把最常用的整理成一张表并标注清楚每个参数的作用和典型用法。参数作用典型用法-a归档模式等于递归加保留权限、时间、软链接等rsync -a 源/ 目标/-v显示传输过程rsync -av 源/ 目标/-z传输时压缩数据跨公网时建议加--delete删除目标端多余文件镜像同步必备--exclude排除指定文件或目录--exclude*.log--exclude-from从文件读取排除规则规则多时用--partial保留部分传输的文件便于断点续传大文件同步时加--bwlimit限制带宽单位KB/s避免占满业务带宽-n空跑演练不实际传输配合-v使用可预览效果--stats显示传输统计信息事后排查有价值-e指定远程Shell可用于非默认端口-e ssh -p 22022参数选择背后是有逻辑的。比如做“镜像”场景--delete是必须的不然目标端会越积越满但如果是“备份”场景目标端需要保留历史旧的删除文件盲目加--delete反而会误删这时候可能要改成--backup把被覆盖的文件另存一份。再说--bwlimit在业务高峰期跑全量同步不加限速会把网络出口塞满影响线上服务加了之后虽然慢一点但稳定得多。这些参数不是背出来的是结合场景选出来的。2.4 传输校验与一些容易被忽略的行为rsync 的每个文件默认都有完整性和校验机制传输完成后会确认文件内容是否正确。它还会在传输时尽量保留源文件的权限、时间戳、属主等属性配合-a基本上就是一种“原样复制”的效果。同步完成后再查看两边文件的 md5通常是一致的这让人比较放心。但也有几个容易被忽略的行为。比如 rsync 判断文件是否变化默认是通过文件大小和修改时间如果只改了文件内容但故意保留原修改时间rsync 可能会认为文件没变而跳过传输。再比如对软链接的处理默认它传的是链接本身而不是链接指向的内容这对某些业务可能产生问题。还有符号链接如果指向绝对路径在目标端可能失去意义这也是需要留意的地方。3. 实验部署从零搭建一套远程同步体系3.1 实验环境准备这里我模拟一个典型的双机环境一台作为源端主要负责业务数据的产生和存储另一台作为目标端用于接收同步数据充当备份或分发节点。源端主机名随意系统是 Linux目标端同网段两者能够互相 ping 通。我们可以不用考虑太复杂的组网直接在同一局域网里做实验最直观。首先确保两端都安装了 rsync。多数 Linux 发行版默认没有安装 rsync需要手动安装。云上的 CentOS 系用yum install -y rsyncDebian 系用apt install -y rsync。安装好之后可以用rsync --version确认版本。目标端如果是走远程Shell模式还必须有 sshd 服务在运行并且源端有可登录的账号如果走 daemon 模式目标端就需要额外配置并启动 rsyncd 服务。为了实验更贴近真实我建议在源端建一个模拟业务目录比如/data/www里面放一些文本文件、一个子目录、一张图片甚至故意放一个超过 100M 的临时文件。这样我们后面既能直观看到增量传输过程也能验证大文件断点续传这一类问题。3.2 最基本的远程Shell同步命令进入源端执行下面这条命令把/data/www目录的内容推送到目标端的/data/backup目录下rsync -avz /data/www/ root目标主机IP:/data/backup/先别急着跑注意看源路径末尾有一个斜杠。这个斜杠意味深远带斜杠表示把/data/www目录里的内容同步到目标目录中注意这里要求服务端存在特性和往期数据堆叠但放在不同的语境里行为也不一样。不带斜杠则会创建一个名为www的子目录放到/data/backup/下面。新手最大的坑就在这建议每次写命令前默念一遍源路径尾部带斜杠内容是“里面的”不带斜杠内容是“目录本身”。命令执行后正常会输出一串文件列表。第一次跑会看到所有文件都列出来说明全部传输过去了。第二次再跑同一条命令如果源端没有任何改动输出就会很简洁只有sent 微小字节 received 微小字节这类统计信息表示没有新增变化。这时候再在源目录里新建一个文件再跑一次就会发现只有新文件被传过去这就是增量同步的实际效果。3.3 免密登录与同步脚本化生产环境不能每次手动输密码。远程Shell模式基于 ssh配置免密登录是标准操作。在源端生成密钥对ssh-keygen -t ed25519 -N 然后执行ssh-copy-id root目标主机IP这个命令会把自己的公钥安装到目标主机对应账号的~/.ssh/authorized_keys文件里。完成后我们可以直接执行一条 rsync 命令测试如果没有再提示输入密码说明免密配置成功。免密通了之后同步才真正有资格进脚本。比如我写一个简单的同步脚本放到源端某目录下#!/bin/bash source_dir/data/www/ target_host目标主机IP target_dir/data/backup/ log_file/var/log/www_sync.log rsync -avz --delete --bwlimit2048 \ ${source_dir} root${target_host}:${target_dir} ${log_file} 21 if [ $? -eq 0 ]; then echo $(date %Y-%m-%d %H:%M:%S) sync ok ${log_file} else echo $(date %Y-%m-%d %H:%M:%S) sync failed ${log_file} fi注意脚本里我用到了--bwlimit2048限制带宽在 2MB/s 左右防止同步把业务带宽占满。日志重定向有两种流向命令本身的输出都写到日志文件里方便事后排查。脚本开头#!/bin/bash和变量定义是常规动作但就算不写变量、直接长命令也没问题只是脚本化之后更利于维护。3.4 用 crontab 实现定时自动同步脚本写好后需要交给定时任务来驱动。执行crontab -e新增一行*/5 * * * * /usr/local/bin/sync_www.sh这里的意思就是每五分钟跑一次同步脚本。同步频率取决于业务对数据时效性的要求。如果只是备份一般每几分钟到每小时跑一次都行如果是对外提供服务的代码分发实时性要求高光靠 cron 可能不够后面我还会提到结合事件触发的方案。定时任务里有个容易忽略的坑cron 的环境变量和手动执行终端的环境不一样脚本最好使用绝对路径rsync 也建议写成/usr/bin/rsync。脚本本身还要赋可执行权限chmod x /usr/local/bin/sync_www.sh为了避免脚本重复执行时彼此打架可以考虑加一个锁。最简单的做法是if [ -f /tmp/sync.lock ]; then exit 1 fi touch /tmp/sync.lock ... 同步逻辑 ... rm -f /tmp/sync.lock虽然这个锁不完美以防万一进程被 kill 留下残留锁还需要额外处理但对于多数同步场景已经够了。3.5 使用 daemon 模式搭建同步服务节点远程Shell模式虽然方便但也有不足每台客户端都要有系统账号同步比较频繁时 ssh 连接建立和销毁也有开销。面向多客户端的集中同步服务更适合 daemon 模式。目标端先编辑/etc/rsyncd.confuid rsync gid rsync use chroot no max connections 10 pid file /var/run/rsyncd.pid log file /var/log/rsyncd.log [backup] path /data/backup/ comment backup module read only yes list yes hosts allow 192.168.1.0/24 hosts deny *然后准备一个rsync系统账号并赋予备份目录合适的权限。启动服务systemctl enable rsyncd systemctl start rsyncd任何允许网段的源端机器都可以用类似下面这条命令推送数据rsync -avz --delete /data/www/ rsync://目标主机IP/backup/注意这里地址里是“模块名”不是实际路径。模块名backup映射到服务端真实目录/data/backup/。访问控制、只读属性、独立账号全靠这份配置文件来约束。这种方式在局域网里给多台机器做统一备份入口非常清爽。生产环境要注意daemon 模式默认端口是 873。如果中间有防火墙必须放行对应端口否则客户端连接会直接超时。很多人在实验环境里能通一上云就被安全组拦掉排查来排查去最后发现是端口没放。4. 典型问题排查与避坑实录4.1 “文件显示传了但两边内容对不上”怎么办先说排查思路。rsync 同步完成以后如果怀疑数据不一致第一步不是重新跑命令而是先用--dry-run看两边差异。加-n跑一遍空跑rsync 会列出它认为“还需要更新”的文件。如果空跑结果为空基本可以确定两端确实一致。如果有差异再看差在属性还是内容上。常见原因是修改时间不同步。前面说过 rsync 默认靠文件大小和时间戳判断是否需要更新如果只是属性变化或者时间戳差一点会在空跑里显示出来。此时如果确实想两边完全一致可以加上-I参数忽略时间差异并强制校验但一般不建议长期这么搞因为会丧失增量优势。真正常见的差异原因反而是同步过程被中断文件没传完整这种情况加上--partial再重新同步能有效续传。4.2 权限和属主问题远程Shell与daemon模式的不同表现远程Shell模式下rsync 使用登录系统账号的身份来写目标目录所以“权限不足”一类错误往往和目标目录的属主、sudo 策略有关。如果登录的是普通用户想要写入只有 root 能写的目录要么改用 root 登录要么调整目标目录的权限要么配合 sudo 使用。daemon 模式下则不一样文件写入身份由配置文件里的uid和gid决定默认是 rsync 账号。如果这个账号对存储目录没有写权限同步就会报错。更隐蔽的问题在属主本身。跨机器同步时两边相同 uid 不一定代表同一个用户因为不同系统上用户 id 可能不同。如果是数据备份到另一台机器目标端不关心属主是谁那就无所谓如果目标是重建一个完全一致的环境就需要设计好 uid 映射策略必要时用--numeric-ids保持 id 不变避免误把不同用户当同一个人。4.3 排除规则没生效通配符踩了坑用--exclude排除文件是比较常见的需求比如不想同步日志目录、缓存目录、临时文件。我见过的问题是写了个--exclude*.log结果发现日志文件还是被传过去了。原因多半是通配符作用在文件名的后缀组件上但目录名也包含.log时行为会跟直觉不一致。还有一种是规则写错了位置--exclude放在rsync后面、源路径前面这没问题如果放在源路径后面而且和目标路径之间rsync 会解析为这是要同步的路径直接报错。规则很多时推荐用--exclude-from从文件加载排除规则一行一条清晰可维护--exclude-from/etc/rsync_exclude.txt排除文件里写*.log cache/ *.tmp需要注意排除规则中的目录名是否带斜杠会影响它匹配的深度。比如cache会匹配任意层级的同名目录而/cache只会匹配源端顶层的该目录。这个细节不实验几次很容易搞混。4.4 大量小文件的同步性能问题与优化手段同步一个包含几十万个文件的目录rsync 再强也会慢。因为它要先遍历文件列表、计算校验、建立传输任务这个索引和比对过程本身就耗时。真正传输文件本身可能只占一部分时间。几个有效的优化手段一是尽量只同步需要的目录用排除规则切掉无关文件二是源端数据变化不大的场景可以考虑用--fuzzy让 rsync 通过近似文件名发挥一些作用三是传输链路的压缩要按需开启-z对小文本文件有用但压缩过的视频、图片等文件再压反而消耗 CPU四是如果机器内存充足加大内核文件缓存往往比调 rsync 参数更有用。极端情况下如果每次变化的只是少数几个大文件那 rsync 流式读取文件再对比的效率不会差真正怕的是“全是小文件且全变化”。4.5 连接超时与端口不通常见的排查思路遇到 rsync 连不上目标主机先分清楚是哪种模式。远程Shell模式看的是 22 端口daemon 模式看的是 873 端口。最简单的判断方式是先在源端测试端口连通性telnet 目标主机IP 873不通的话就是网络层或防火墙问题检查本机防火墙、云厂商安全组、目标主机监听状态。通了的话再看具体报错。比如rsync: connection unexpectedly closed如果系统日志或 rsyncd 日志里有address in deny list或权限信息就要检查配置文件的hosts allow/deny设置、uid 权限、模块路径是否存在。一个容易踩的情况是 daemon 模式下模块路径写成相对路径导致服务找不到目录。配置里的path必须写绝对路径目录本身存在且对uid有读权限。启动服务后建议先在目标端本地用rsync rsync://目标主机IP或rsync 目标主机IP::看模块列表是否正常能列出模块再让客户端去连有些问题一下就能暴露。4.6 同步结果异常时的日志与数据核对方法用 cron 跑定时同步最怕的是同步失败但没人发现。脚本里写日志是一个好习惯日志要能反映上次同步是否成功、传输了多少数据、是否有错误输出。再进一步可以在脚本里加上邮件或告警通知当然前提是环境里已经有了告警通道。针对重要备份还可以在同步完成后额外执行一次校验比如对指定目录生成文件清单和上次比对。形成“同步之后再校验”的闭环才能算是一个合格的备份体系。日志里建议关心的字段有被排除的文件数、损坏文件数、总传输字节数、耗时。--stats参数能打印这些信息脚本里把它开启会让问题定位轻松很多。不要只在失败时才看日志平时也可以固定频率抽查同步记录知道了正常的字节数和耗时基线异常出现时一眼就能盯出来。5. 方案扩展实时同步、多机分发与产品化思考5.1 rsync 能否做双向同步严格来说rsync 的设计目标不是双向同步。双向同步会出现“源删除了一个文件目标端也想删除但对方不知道”“两边同时修改同一个文件”这种复杂冲突单靠 rsync 和调度脚本很难处理干净。如果业务需求确实是两个节点双向保持一致建议改用专门的双向同步工具或者分布式文件系统用 rsync 硬做的话需要在删除和冲突规则上做大量保护复杂度会陡增。做“单向镜像”倒是 rsync 的主场。源端为主、目标端做副本使用--delete、--ignore-errors配合好日志就能稳定维持镜像关系。多台目标端的场景可以用 rsync 把数据依次推到各台机器或者在一台源端上跑多个并发任务。并发数要注意控制否则大量进程同时读源磁盘I/O 会先成为瓶颈。5.2 结合事件触发机制做准实时同步cron 的定时同步有固定间隔但间隔再短也有延迟。对一些即时性要求更高的业务比如配置变更、前端代码发布可以采用“目录事件触发 rsync 增量推送”的思路。典型做法是源端部署一个监控进程监听某个目录的 create、modify、delete 事件事件发生后延迟几秒触发一次 rsync。这样既保留 rsync 的增量传输能力又能让同步延迟缩短到秒级。这里涉及一个重要设计事件触发的同步如果修改很频繁会产生大量连续任务容易导致重复同步或资源抢占。通常需要做去重和节流比如事件发生后等 5 秒再跑5 秒内又有新事件就重置等待时间也可以用一个简单的队列只保底最近一次状态变化。生产上不少工具已经封装了这类行为甚至可以在同步后自动执行远程命令完成缓存更新之类的联动操作。5.3 从传数据到建备份体系的延伸思考单点执行 rsync 命令只是“传数据”要把它变成可靠的备份体系还需要考虑几件事。首先是版本保留没有历史版本的备份等于没有备份因为误删、被篡改这类灾难发生时一个和源端一模一样的副本并没有意义。解决思路可以是在 rsync 同步之前用快照或硬链接手段保留上一版本或者定期对目标目录做归档压缩形成恢复点。其次是灾备演练。备份体系要定期做恢复演练不能只在灾难发生时才发现备份不可用。你可以在实验环境里把目标端数据恢复到一台临时机器上确认数据完整、服务能起来这个动作比任何参数调整都重要。同步任务跑得再正常没有验证过恢复路径风险就依然存在。再次是监控与告警。rsync 是高效工具但它是命令级的不会主动告诉你“昨天的同步失败了”。把同步结果接入监控体系以后任务才算真正纳管起来。这里面的投入产出比很高值得认真设计。结尾一些来自实战的体会东西讲到这我发现 rsync 这个工具最妙的地方是它看起来命令简单但真正用好靠的是对数据一致性、权限模型、网络边界和定时调度的整体理解。我在实际项目中见过不少事故不是因为 rsync 本身有问题而是使用的人没想清楚到底要“备份”还是要“镜像”也没提前验证目标端权限和防火墙结果同步脚本上线第一天就把目标目录搞乱了。如果你准备开始搭建属于自己的 rsync 同步体系我建议先在小范围模拟环境里把命令跑通再逐步加上--delete、--bwlimit、定时任务和日志告警每一步变更都验证过再加下一步。最后再分享一个小技巧先养成本地数据目录和同步目标目录命名规范的习惯把所有 rsync 命令封装成脚本而不是裸敲命令行这会让你日后排查问题省下大量时间。经验都是踩坑攒出来的但有些坑别人写出来帮你避开了何乐而不为。