1. 文件同步这件事为什么值得用脚本认真对待手里管着几台Linux机器的人迟早都会碰到同一个问题某份数据在这台机器上改了那台机器上还是旧的。可能是备份目录、可能是发布产物、可能是日志归档也可能是几台机器之间需要保持一致的一批配置文件。图形化工具不是没有但服务器上通常没有桌面环境装一个带界面的同步工具既重又没必要。这时候最朴素也最可靠的做法就是写一个Bash脚本把同步逻辑固化下来丢进crontab或者systemd timer里定时跑。我这些年经手的同步场景大概分三类。第一类是本机目录到目录的同步比如把某个工作目录镜像到备份盘第二类是本机到远程主机的同步走SSH通道把数据推过去或者拉回来第三类是多台机器之间的准实时对齐靠定时任务轮询。这三类的底层工具选择、参数调优、异常处理思路都不一样但都可以用Bash脚本串起来。这篇文章就把我实际在用的几套方案拆开讲清楚包括为什么选某个工具、参数怎么算、踩过哪些坑、出问题怎么排查。需要先说明一点文件同步和文件备份不是一回事。备份关注的是历史版本可回溯同步关注的是两边状态一致。很多人拿同步工具当备份用结果源端一删目标端跟着删数据直接没了。这个认知必须先建立起来后面所有参数设计都围绕这个前提展开。脚本能帮你把同步做得又稳又省心但它不会替你判断这次删除到底该不该同步过去。适合读这篇内容的人有一定Linux基础能看懂命令行写过简单脚本但还没把同步这件事做成一套可靠流程的运维或开发人员。如果你完全没碰过Bash建议先把变量、条件判断、循环、函数这四样过一遍再来看具体实现会顺畅很多。2. 同步方案的整体设计与工具选型2.1 先想清楚同步的语义镜像、增量还是双向动手写脚本之前必须先回答一个问题你要的是哪种同步语义。这个决定直接决定了工具选型和参数配置选错了后面全是坑。镜像同步mirror的目标是让目标端和源端完全一致源端删了什么目标端也要删。典型场景是把一台机器的发布目录完整复制到另一台。这种同步用rsync加--delete参数就能实现但风险也最高源端误删会直接传导到目标端。增量同步incremental只把新增和修改的文件传过去不处理删除。适合日志归档、数据累积这类场景目标端只会越来越多不会变少。这种最安全rsync默认行为就是增量不加--delete即可。双向同步bidirectional要求两边互相补齐A有B没有的传给BB有A没有的传给A。这个用rsync单条命令做不到需要unison这类工具或者自己写逻辑判断。双向同步的冲突处理非常麻烦两个方向同时改了同一个文件怎么办必须有明确的策略。我的建议是除非业务真的需要否则尽量把双向拆成两个单向任务用不同的时间窗口错开跑。下面这张表是我总结的语义与工具对应关系选型时直接对照同步语义推荐工具关键参数适用场景风险等级镜像同步rsync--delete发布目录、配置分发高增量同步rsync默认不加--delete日志归档、数据累积低双向同步unison-batch -auto协作目录、多端编辑中实时同步inotifyrsync事件触发准实时要求场景中2.2 为什么主力选rsync而不是cp或scp很多人第一反应是cp -r或者scp -r简单直接。但这两个工具在同步场景下有硬伤。cp是全量复制每次跑都把整个目录重来一遍文件多了慢得离谱而且它不判断文件是否真的变了。scp走SSH传文件同样不判断差异传完就完事断点续传和增量都不支持。rsync的核心优势在于它的差异算法。它默认采用quick check策略先比较文件大小和修改时间两者都一致就跳过不一致才进一步算校验和。这意味着第二次同步时绝大部分没变的文件会被瞬间跳过只处理真正变化的文件。对于几万个文件的大目录这个差距是数量级的。rsync还有一个杀手锏是断点续传和部分传输。传大文件时如果网络断了--partial参数能让它保留已传部分下次接着传不用从头来。scp做不到这一点断了就得重传。至于unison它是双向同步的专用工具底层其实也调用rsync的算法但增加了双向比对和冲突处理逻辑。它的缺点是两端都要装而且版本要匹配跨版本经常出兼容问题。所以我的策略是单向同步一律用rsync只有确实需要双向时才上unison。2.3 脚本的骨架应该长什么样一个能长期稳定运行的同步脚本不能只是把rsync命令包一层就完事。它至少要包含这几个部分配置区源、目标、排除规则、日志路径、前置检查源是否存在、目标是否可写、依赖工具是否安装、锁机制防止上一次没跑完下一次又启动、执行主体rsync调用、结果判断与告警根据退出码决定是否发通知、日志记录每次运行留痕。我见过太多脚本只写了执行主体跑起来看着没问题但一旦源目录被误删脚本照样执行把目标端也清空了。前置检查里加一条源目录必须存在且非空就能挡住大部分这类事故。锁机制也很关键如果同步任务耗时超过定时间隔两个实例同时跑会互相干扰甚至把目标端搞乱。脚本的退出码设计也要讲究。rsync的退出码有明确含义0表示成功23表示部分文件传输有警告24表示源文件在传输中消失30和31是超时。脚本应该把这些码区分对待0和24可以视为正常23要告警其他要重点处理。不能简单地用if [ $? -eq 0 ]一刀切。3. 核心细节解析与实操要点3.1 rsync参数里最容易配错的几个rsync的参数有上百个但真正影响同步行为的就那么几个配错了后果很严重。我逐个说清楚。-aarchive是组合参数等价于-rlptgoD意思是递归、保留符号链接、保留权限、保留时间戳、保留属组、保留属主、保留设备文件。这个参数几乎每次都要加但要注意-o保留属主和-g保留属组在非root用户下会报错因为普通用户没权限改文件属主。如果脚本以普通用户运行应该用-rlptD手动组合去掉-o -g。-zcompress在传输时压缩数据。局域网内带宽充足时反而增加CPU开销不建议开。跨公网传输时开启能明显减少流量。判断标准很简单内网千兆以上不开公网或带宽紧张就开。--delete是镜像同步的关键也是最危险的参数。它会让目标端删除源端已经不存在的文件。用之前必须确认三件事源端路径没写错、目标端路径没写错、排除规则里保护了不该删的目录。我习惯在正式跑之前先用--dry-run空跑一遍看看它打算删哪些文件确认无误再去掉这个参数。--exclude和--exclude-from用来排除不需要同步的文件。临时文件、缓存、日志、.git目录通常都要排除。排除规则支持通配符但要注意路径匹配的细节--exclude *.log会排除所有层级的log文件而--exclude /logs/只排除根目录下的logs目录。规则写错会导致该同步的没同步或者该排除的没排除。--bwlimit限制带宽单位是KB/s。在共享带宽的环境里不限速的同步可能把带宽占满影响其他服务。我一般会设成可用带宽的70%左右留出余量。3.2 排除规则的设计原则排除规则不是随便写几条就完事它需要和同步语义配合。镜像同步时排除规则相当于保护名单被排除的路径在目标端不会被删除。增量同步时排除规则只是不传输名单目标端已有的不受影响。我的经验是把排除规则单独写成一个文件用--exclude-from引用。这样规则集中管理改起来方便也便于版本控制。文件内容大概长这样# 版本控制目录 .git/ .svn/ # 临时文件 *.tmp *.swp *~ # 日志和缓存 *.log cache/ tmp/ # 特定大目录 node_modules/要注意node_modules这类目录如果两端环境一致排除掉能省大量传输时间如果两端需要独立安装依赖那更应该排除。但排除之后目标端就没有这个目录如果业务依赖它存在得在同步后单独处理。还有一个容易忽略的点排除规则里的路径是相对于源目录的。如果源目录是/data/app/那么--exclude /logs/排除的是/data/app/logs/而不是系统根目录的/logs/。这个相对性一定要搞清楚。3.3 锁机制怎么实现才可靠防止同步任务重叠运行锁是必须的。最简单的做法是用flock命令它是Linux自带的文件锁工具比手写PID文件判断可靠得多。exec 200/var/lock/sync.lock flock -n 200 || { echo 上一次同步还在运行退出; exit 1; }这段代码打开一个文件描述符200指向锁文件flock -n尝试非阻塞获取锁拿不到就说明有实例在跑直接退出。锁会在脚本结束时自动释放即使脚本被kill也不会残留死锁这是它比PID文件方案强的地方。注意锁文件路径要放在所有实例都能访问的位置且不要放在会被同步的目录里否则可能被同步操作影响。如果用PID文件方案必须处理进程已死但PID文件还在的情况判断逻辑会复杂很多。所以能用flock就用flock省心。3.4 日志记录该记什么日志不是记给自己看的是出问题时用来追溯的。我要求日志里至少有这几样时间戳、本次同步的源和目标、传输的文件数量和总大小、删除的文件列表、退出码、耗时。rsync的--log-file参数能记录详细的传输日志但格式比较原始。更好的做法是用--itemize-changes简写-i输出每个文件的变化类型然后在脚本里解析。变化类型码的含义f表示文件被传输cd表示目录被创建*deleting表示文件被删除。把这些记下来出问题时一眼就能看出哪次同步删了什么。日志要轮转不然跑几个月就把磁盘塞满了。可以用logrotate管理也可以在脚本里自己判断日志大小超过阈值就归档。我一般保留最近30天的日志更早的压缩存档。3.5 退出码的精细处理前面提过rsync的退出码有明确含义脚本里应该区别对待。下面是我实际用的处理逻辑退出码含义处理策略0成功正常记录23部分文件传输警告记录警告不告警24源文件传输中消失视为正常记录30/31超时告警下次重试其他错误立即告警23这个码特别常见通常是因为某些文件权限不足或者被占用。如果每次都是同样的文件报23说明排除规则没写全应该把那些文件加进排除列表。24是文件在传输过程中被删了属于正常竞争不用管。脚本里可以这样处理rsync ... rc$? case $rc in 0|24) log 同步成功 ;; 23) log 同步完成但有警告 ;; *) log 同步失败退出码 $rc; send_alert ;; esac4. 完整实操流程与关键环节实现4.1 本机目录镜像同步脚本先从一个最基础的本机镜像同步脚本开始把骨架搭起来后面再扩展。#!/bin/bash set -euo pipefail # 配置区 SRC/data/source/ DST/backup/mirror/ EXCLUDE_FILE/etc/sync/exclude.txt LOG_DIR/var/log/sync LOCK_FILE/var/lock/sync_mirror.lock LOG_FILE${LOG_DIR}/mirror_$(date %Y%m%d).log # 前置检查 mkdir -p $LOG_DIR if [ ! -d $SRC ]; then echo $(date %F %T) 源目录不存在: $SRC $LOG_FILE exit 1 fi if [ ! -d $DST ]; then echo $(date %F %T) 目标目录不存在: $DST $LOG_FILE exit 1 fi # 源目录非空检查防止误删后同步清空目标 if [ -z $(ls -A $SRC) ]; then echo $(date %F %T) 源目录为空拒绝执行镜像同步 $LOG_FILE exit 1 fi # 锁机制 exec 200$LOCK_FILE flock -n 200 || { echo $(date %F %T) 上一次同步未结束本次跳过 $LOG_FILE exit 1 } # 执行同步 START_TIME$(date %s) rsync -rlptD --delete \ --exclude-from$EXCLUDE_FILE \ --itemize-changes \ --log-file$LOG_FILE \ $SRC $DST RC$? END_TIME$(date %s) DURATION$((END_TIME - START_TIME)) # 结果处理 case $RC in 0|24) echo $(date %F %T) 同步成功耗时 ${DURATION}s $LOG_FILE ;; 23) echo $(date %F %T) 同步完成但有警告耗时 ${DURATION}s $LOG_FILE ;; *) echo $(date %F %T) 同步失败退出码 $RC耗时 ${DURATION}s $LOG_FILE exit $RC ;; esac这个脚本有几个设计点值得说明。set -euo pipefail让脚本在遇到未定义变量、命令失败、管道错误时立即退出避免错误被吞掉。源目录非空检查是防呆的关键很多人栽在这上面。-rlptD而不是-a是因为脚本可能以普通用户运行去掉属主属组保留避免报错。4.2 跨主机同步的SSH配置本机同步跑通后扩展到跨主机。跨主机同步走SSH通道核心是免密登录和连接稳定性。免密登录用密钥对实现。生成密钥时建议用ed25519算法比RSA更短更安全ssh-keygen -t ed25519 -f ~/.ssh/sync_key -N ssh-copy-id -i ~/.ssh/sync_key.pub userremote_host-N 表示密钥不设密码因为脚本里没法交互输入。这带来一个安全问题密钥泄露就等于目标主机被攻破。所以密钥文件权限必须设成600而且这个密钥只用于同步不要复用到其他地方。跨主机同步的rsync命令要指定SSH密钥和连接参数rsync -rlptD --delete \ -e ssh -i ~/.ssh/sync_key -o StrictHostKeyCheckingyes -o ConnectTimeout10 \ --exclude-from$EXCLUDE_FILE \ $SRC userremote_host:$DSTStrictHostKeyCheckingyes强制校验主机密钥防止中间人攻击。ConnectTimeout10设置连接超时避免网络不通时脚本卡死。这两个参数在自动化脚本里很重要不加的话可能一直挂着。4.3 带宽限制与传输窗口设计跨公网同步时带宽是稀缺资源。--bwlimit参数限制传输速率单位KB/s。假设你的出口带宽是100Mbps换算成字节是12.5MB/s留出余量后设成8000约8MB/s比较合适。rsync -rlptD --delete --bwlimit8000 ...但限速只是手段更重要的是传输窗口的设计。如果同步的数据量大白天跑会影响业务应该放到夜间低峰期。用crontab配置# 每天凌晨2点执行避开业务高峰 0 2 * * * /usr/local/bin/sync_mirror.sh /var/log/sync/cron.log 21如果数据量特别大一次跑不完可以考虑分批同步或者用--partial支持断点续传把大任务拆成多次小任务。4.4 双向同步的unison方案确实需要双向同步时unison是更合适的选择。它的配置文件放在~/.unison/下一个profile对应一个同步任务。# ~/.unison/webapp.prf root /data/webapp root ssh://userremote_host//data/webapp batch true auto true confirmbigdel true ignore Name *.tmp ignore Name .git log true logfile /var/log/sync/unison.logbatch true和auto true让unison非交互运行自动处理能自动处理的冲突。confirmbigdel true是关键保护当检测到大量删除时会要求确认防止误删。ignore规则和rsync的exclude类似。unison的冲突处理策略要提前想清楚。默认情况下如果两边都改了同一个文件它会保留两个版本文件名带时间戳后缀。这个行为可以通过prefer参数调整比如prefer newer表示保留较新的版本。但较新的判断依赖时间戳如果两端时钟不同步就会出错所以两端的时间同步NTP必须做好。4.5 用inotify实现准实时同步定时同步的粒度最细到分钟级如果需要秒级响应可以用inotify监听文件变化触发即时同步。#!/bin/bash WATCH_DIR/data/source REMOTEuserremote_host:/data/target inotifywait -m -r -e modify,create,delete,move \ --format %w%f $WATCH_DIR | while read FILE; do rsync -rlptD --delete $WATCH_DIR/ $REMOTE/ done这个方案简单但有个问题短时间内大量文件变化会触发多次rsync造成资源浪费。改进做法是加一个延迟合并用--delay或者自己写个缓冲逻辑把短时间内的多次变化合并成一次同步。inotify还有监听数量限制默认的max_user_watches可能不够用大目录需要调大sysctl fs.inotify.max_user_watches524288这个值要写进/etc/sysctl.conf才能持久化。5. 常见问题与排查技巧实录5.1 同步后文件时间戳不对这是最常见的问题之一。现象是同步过去的文件修改时间变成了同步执行的时间而不是源文件的原始时间。原因通常是没用-t参数或者用了--no-times。-a和-rlptD里都包含t正常不会出问题。但如果目标文件系统不支持保留时间戳比如某些FAT格式的移动盘也会出现这个现象。排查方法在源端和目标端分别执行stat 文件名对比Modify时间。如果源端正确目标端不对检查rsync参数里有没有t。如果参数没问题检查目标文件系统类型df -T可以看。5.2 权限报错导致同步中断普通用户跑rsync时遇到属主属组保留会报chown failed: Operation not permitted。解决办法是去掉-o -g用-rlptD代替-a。如果确实需要保留属主属组就得用root跑或者配置sudo免密。还有一种权限问题是目标目录不可写。rsync需要目标目录有写权限才能创建文件。检查目标目录的权限和属主确保执行同步的用户有写权限。5.3 同步速度慢得离谱速度慢的原因可能有很多按这个顺序排查是否走了公网内网同步应该走内网地址如果DNS解析到了公网IP速度会差很多。用--ipv4强制IPv4或者直接在命令里写内网IP。是否开了压缩内网带宽充足时-z反而拖慢速度去掉试试。是否在做全量校验如果文件时间戳频繁变化比如被touch过rsync会认为文件变了重新算校验和。用--size-only只比大小能加速但有风险。磁盘IO瓶颈源端或目标端磁盘慢iostat看一下IO利用率。文件数量太多几十万个小文件时rsync的扫描阶段就很慢。这种情况考虑用--delete-before或者分批同步。5.4 同步过程中断如何续传网络不稳定导致同步中断重新跑一遍会从头开始。加--partial参数让rsync保留已传输的部分文件下次接着传rsync -rlptD --partial --append-verify ...--append-verify会在续传时校验已传部分确保数据正确。但要注意如果源文件在中断期间被修改了续传会导致文件损坏。所以续传适合大文件且源文件稳定的场景。5.5 目标端文件被误删的恢复如果--delete误删了目标端文件恢复的难度取决于有没有备份。这也是为什么我一直强调同步不等于备份。镜像同步的目标端应该再有一层备份保护。一个实用的做法是在目标端用快照文件系统如btrfs、zfs同步前打快照出问题可以回滚。或者用--backup --backup-dir参数让rsync在删除文件前先备份到指定目录rsync -rlptD --delete \ --backup --backup-dir/backup/deleted/$(date %Y%m%d) \ ...这样被删除的文件会保留在备份目录里相当于一个回收站。定期清理这个目录即可。5.6 常见问题速查表现象可能原因排查命令解决方向时间戳不对缺-t参数或文件系统不支持stat 文件加-t或换文件系统权限报错普通用户保留属主属组id去掉-o -g速度慢走公网/开了压缩/全量校验ping、iostat走内网、去-z、--size-only中断无法续传缺--partial查看日志加--partial误删无法恢复无备份机制检查备份目录加--backup-dir任务重叠无锁机制ps aux加flock日志爆盘无轮转du -sh 日志目录配logrotate5.7 几个我踩过的坑坑一路径末尾的斜杠。rsync src dst和rsync src/ dst行为完全不同。前者会在dst下创建src目录后者直接把src的内容同步到dst。这个差异害过我好几次现在写脚本时路径末尾的斜杠我都反复确认。坑二排除规则里的空格。--exclude my file.txt和--exclude my file.txt不一样后者会被解析成两个参数。排除文件名带空格时一定要加引号。坑三crontab的环境变量。crontab里的PATH和登录shell不一样脚本里用到的命令可能找不到。解决办法是在脚本开头显式设置PATH或者用命令的绝对路径。坑四SSH密钥的权限。密钥文件权限必须是600.ssh目录必须是700否则SSH会拒绝使用。这个报错信息不明显容易忽略。坑五大文件传输时的内存占用。rsync默认的块大小对超大文件可能不够高效可以用--block-size调整。但一般不用动默认值已经适配大多数场景。6. 让脚本长期稳定运行的几个习惯脚本写完能跑只是第一步能稳定跑一年不出事才是目标。我总结了几条实际经验。第一所有同步任务都要有监控。脚本执行失败要能通知到人不能默默失败。最简单的做法是脚本退出码非0时发邮件或者写进一个状态文件由外部监控系统读取。没有监控的定时任务等于没有。第二定期做恢复演练。同步做得好不好不是看同步成功了多少次而是看真需要恢复时能不能恢复。每隔一段时间从目标端随机抽几个文件和源端比对校验和确认数据一致。这个动作能发现很多隐藏问题。第三配置变更要记录。排除规则改了、参数调了、路径换了都要记下来。出问题时能快速定位是哪次变更引入的。我习惯在脚本头部用注释维护一个变更日志。第四不要在同步目录里放锁文件和日志。这些文件会被同步操作影响可能导致锁失效或者日志被覆盖。锁文件和日志都应该放在同步范围之外。第五源端和目标端的时钟要同步。rsync的quick check依赖时间戳两端时钟差太多会导致误判。NTP服务要确保正常运行。这套东西看起来繁琐但每一条都是实际事故换来的。同步脚本本身不复杂复杂的是让它在你睡觉的时候也可靠地工作。把上面这些细节都照顾到你就能放心地把同步这件事交给脚本腾出精力做别的。
