做运维这些年rsync 是我最常用也最放心的同步工具。只要涉及定期备份、往备用节点分发文件、或者把代码同步到生产目录我脑子里第一反应都是 rsync。不过命令行 rsync 容易被记成长长一串手动输很容易漏参数于是我把它封装成了一个带配置文件、日志、单实例锁和异常告警的 shell 脚本。今天整理出来给需要的朋友参考。这个脚本主要解决三个问题一是把同步规则从命令里抽出来用配置文件维护改规则不需要改脚本二是执行过程要有日志出问题能查三是定时任务执行时万一失败要能第一时间通知到人而不是等到磁盘满了才发现备份早就断了。对于有 Linux 基础、想把备份工作做得稍微规范一些的运维人员这套脚本可以直接拿去改着用。1. 这个脚本要解决的几个实际问题1.1 从 cp 到 rsync我为什么切换很多刚开始做备份的人会问直接用 cp -r 不就行了吗其实 cp 在大量文件面前有几个痛点无法增量同步每次都是全量复制文件多的时候效率非常低复制完还得自己对比文件数量和时间戳更麻烦的是 cp 对软链接、属主、属组、ACL 这些文件属性的保留能力有限跨服务器备份时问题尤其明显。rsync 的优势在于它通过“快速检查”机制默认对比文件大小和修改时间只有变化的文件才会被传输。这样第一次做全量后后续每次同步只需要传增量部分速度提升非常明显。更重要的是 rsync 支持 ssh 管道、daemon 模式、排除规则、带宽限制还能保留软链接、权限、属主、时间戳等元数据备份出来的目录跟源目录基本一致。1.2 脚本功能清单与使用场景我当时设计这个脚本时给自己列了几条硬性需求支持多个同步规则不同源目录可以对应不同的排除规则和目标位置执行过程中有完整日志日志按日期滚动保留脚本加单实例锁防止 crontab 上一次任务没跑完、下一次任务又启动两个 rsync 进程互相干扰支持 dry-run 模式跑真实任务前可以先预览会被同步和删除的文件同步失败时能通过 webhook 发通知第一时间知道哪条规则出了问题配置和脚本分离日常只改配置不动脚本这套脚本比较适合这些场景web 站点目录每天增量备份、配置文件定期同步到备份服务器、图片或附件目录从线上同步到归档盘、以及同机不同磁盘之间的冷备。实际用下来数据量大的目录也能稳定跑。2. 脚本的关键参数和设计取舍2.1 rsync 常用参数怎么选rsync 的参数看着多核心组合就那么几套。我这个脚本里默认的参数是-avz --delete --timeout60 --exclude-from$EXCLUDE_FILE每个参数拆开讲一下。-a是归档模式等于 -rlptgoD也就是递归、保留软链接、保留权限、保留时间戳、保留属主和属组、保留设备文件。这个参数基本是备份必选唯一要注意的是它不保留 ACL 和高亮标签属性需要的话得额外加-A和-X。-v是输出详细信息。如果完全不想看输出可以用-q但我建议日志里至少保留-v排查问题时能看到传了哪些文件、哪些文件失败。-z是传输时压缩。这个参数要看场景跨公网传输网络带宽小压缩能显著减少流量但同一台机器或内网千兆环境压缩反而消耗两端 CPU速度不一定更快。我自己在内网同步时会把 z 去掉脚本里作为变量开关注释掉了。--delete会让目标目录中源目录不存在的文件被删除保证两边目录完全一致。这个参数很关键但也最危险后面常见问题部分我会专门说。--timeout60是设置 I/O 超时时间。之前遇到过网络中断后 rsync 进程一直挂着不动测试卡在某个文件上半天不退出。加上超时参数会在没有数据传输超过 60 秒时主动报错退出crontab 才能继续走告警逻辑。2.2 单实例锁和配置文件设计crontab 执行脚本时有一个容易被忽略的问题上一个同步任务还没结束下一个任务又到了两个 rsync 同时读写同一目录会导致数据不一致和资源抢占。我参考了很多做法最终用了 flock 文件锁而不是 mkdir 锁。早期常用的 mkdir 锁是创建一个目录作为锁标识退出时再删除问题在于进程如果被 kill -9锁目录残留脚本下次就无法启动必须手动清理。flock 是内核级别的文件锁进程退出时锁自动释放不会出现“僵尸锁”。脚本里这样写exec 9$LOCK_FILE if ! flock -n 9; then log 已有同步任务在执行本次运行跳过 exit 0 fi-n表示拿不到锁就立刻失败而不是阻塞等待。这样即使任务是每 5 分钟跑一次上次任务还在执行新任务也不会排队堆叠直接退出即可。配置文件的格式我选择了最简单的竖线分隔# rsync_sync.conf # 格式: 源路径|目标路径|排除文件路径(可省略) /webdata|/backup/webdata|/etc/rsync_exclude_web.conf /home/upload|/backup/upload|脚本读取时用while IFS| read -r SRC DST EXCLUDE逐行解析。之所以不用 json 或 yaml是因为脚本本身是 bash引入 jq 解析 json 会增加依赖。竖线分隔足够直观人眼扫一遍就知道规则内容。2.3 告警逻辑同步失败不能靠肉眼发现备份这种事情最怕的是“看起来在跑其实已经失败很多天”。rsync 如果不检查退出码即使目标磁盘满了、网络断了crontab 也只会默默把日志写进文件没人看就相当于没有备份。脚本里对每条同步规则做了退出码判断if [ $? -eq 0 ]; then log 同步完成: $SRC - $DST else log 同步失败: $SRC - $DST退出码 $EXIT_CODE send_notify rsync 同步失败: $SRC - $DST退出码 $EXIT_CODE fisend_notify 实现的是一个通用的 webhook 推送只要给一个 POST 接口地址把消息体组装成 json 发过去即可兼容常见的机器人通知服务。如果不想用 webhook也可以在这个函数里替换成邮件发送命令。3. 完整脚本代码与实现细节3.1 完整脚本代码下面是我在用的完整版本没有贴复杂的依赖直接复制到一个文件里就能跑。#!/bin/bash # # rsync_sync.sh - 多规则 rsync 增量同步脚本 # 用法: # ./rsync_sync.sh 执行同步 # ./rsync_sync.sh --dry-run 只预览不真实同步 # set -u set -o pipefail # 配置区 CONF_FILE${CONF_FILE:-/etc/rsync_sync.conf} LOG_DIR${LOG_DIR:-/var/log/rsync_sync} LOCK_FILE/tmp/rsync_sync.lock NOTIFY_URL${NOTIFY_URL:-} KEEP_LOG_DAYS30 # 基础环境 export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin mkdir -p $LOG_DIR TODAY$(date %F) LOG_FILE$LOG_DIR/rsync_sync_${TODAY}.log log() { echo [$(date %F %T)] $* $LOG_FILE echo [$(date %F %T)] $* } send_notify() { local msg$1 if [ -n $NOTIFY_URL ]; then curl -fsSL --connect-timeout 10 --max-time 15 \ -X POST -H Content-Type: application/json \ -d $(printf {text:%s} $msg) \ $NOTIFY_URL /dev/null 21 fi } # 锁处理 exec 9$LOCK_FILE if ! flock -n 9; then log 已有同步任务在执行本次运行跳过 exit 0 fi RSYNC_OPTS(-avz --delete --timeout60) if [ ${1:-} --dry-run ]; then RSYNC_OPTS(--dry-run) log 当前为 dry-run 预览模式不会真实修改目标目录 fi # 检查配置文件 if [ ! -f $CONF_FILE ]; then log 配置文件不存在: $CONF_FILE send_notify rsync 脚本启动失败: 配置文件不存在 exit 1 fi # 清理过期日志 find $LOG_DIR -type f -name rsync_sync_*.log -mtime $KEEP_LOG_DAYS -delete 2/dev/null FAILED0 while IFS| read -r SRC DST EXCLUDE; do # 跳过注释和空行 case $SRC in |\#*) continue ;; esac [ -z $DST ] continue # 保证目标父目录存在 DST_DIR$(dirname $DST) mkdir -p $DST_DIR || { log 创建目标目录失败: $DST_DIR; FAILED1; continue; } EXCLUDE_ARGS() if [ -n ${EXCLUDE:-} ] [ -f $EXCLUDE ]; then EXCLUDE_ARGS(--exclude-from$EXCLUDE) fi log 开始同步: $SRC - $DST rsync ${RSYNC_OPTS[]} ${EXCLUDE_ARGS[]} $SRC $DST $LOG_FILE 21 EXIT_CODE$? if [ $EXIT_CODE -eq 0 ]; then log 同步完成: $SRC - $DST else FAILED1 log 同步失败: $SRC - $DST退出码 $EXIT_CODE send_notify rsync 同步失败: $SRC - $DST退出码 $EXIT_CODE fi done $CONF_FILE if [ $FAILED -eq 1 ]; then log 本次运行存在失败规则整体退出码置为 1 exit 1 fi log 所有同步规则执行完成 exit 03.2 核心函数说明脚本里相对关键的是log和send_notify两个函数。log同时输出到控制台和日志文件。crontab 场景下控制台输出最终会被重定向到 cron 的日志管道但平时手动执行时看到实时输出会更放心。日志文件名按日期滚动单个日志文件不会无限变大每天自动取当天的文件。send_notify用 curl 发送 webhook。如果NOTIFY_URL为空自动跳过适合纯本地备份的场景。消息体用了最简单的{text:...}格式方便接到通用机器人上。如果后续需求复杂也可以改成包含 host、时间、错误码的 json 结构不过代码量会多一些。还有一点值得留意读取多规则配置时用的是while ... done $CONF_FILE循环。这种写法有个隐藏的坑循环里的log函数调用没有问题但如果循环内部用了管道比如把 rsync 输出接tee就会导致循环体整体产生子进程某些环境变量的修改就失效了。我遇到过这个问题所以脚本里统一处理为追加写日志文件不在循环里套管道规避这类 shell 行为差异。3.3 配合系统定时任务运行脚本本身不负责定时调度这部分交给 crontab 是最常见的做法。比如每天凌晨两点半执行一次30 2 * * * /usr/local/bin/rsync_sync.sh /var/log/rsync_sync_cron.log 21需要注意 crontab 环境变量很少。脚本里我显式 export 了 PATH就是为了避免找不到 rsync 或者 curl。如果你的 rsync 装在非标准路径比如/usr/local/bin/rsync一定要把 PATH 里加上对应目录。用 systemd timer 也可以好处是能记录上次执行结果、管理启动依赖。如果对 systemd 不熟crontab 已经足够稳定。我目前的线上环境用的就是 crontab跑了很久没有出过任务漏跑的问题关键是把日志和告警做好。4. 实操中的常见问题与排查记录4.1 权限、时间戳、文件属性类报错rsync 最常出现的不是网络错误而是文件属性无法设置。比如rsync: failed to set times on /backup/webdata: Operation not permitted这类问题的根源大多不是 rsync 的 bug而是运行用户对目标目录没有足够的权限或者目标文件系统的挂载参数限制。比如 NFS 默认的挂载参数不允许修改时间戳可以用--modify-window1忽略几秒内的时差但这只能缓解精度问题最彻底的还是确认运行用户对目标目录有写权限和属主权限。还有一类情况是同步源包含了 ACL 和 xattr 属性而目标文件系统不支持。解决方法是去掉参数里的-A -X只保留基础归档模式或者改用文件系统本身支持这些属性的目录。之前我在旧的存储设备上就遇到过目标系统升级前不支持 user_xattr结果大量文件提示属性传输失败最后是重新格式化文件系统解决的。4.2 网络中断与进程残留问题rsync 默认遇到网络中断不会主动退出尤其是在 ssh 管道连接已经断掉的情况下进程可能一直卡着。之前我遇到过一次备份目录文件特别多任务跑了两个多小时后日志突然不再更新ps 一看 rsync 进程还在状态是 D 或者 S但网络连接已经断了最后只能 kill 掉进程重新跑。从那以后我所有脚本里都带了--timeout60。这个参数的意思是如果有 60 秒没有任何数据传输就判定连接异常并退出。注意它并不是限制总同步时长所以不用担心大目录同步到一半被杀。对于跨网络环境这个参数基本是必需品。另外有些管理员觉得 kill 掉 rsync 进程就完事了其实还要注意 ssh 隧道子进程也可能残留。脚本里没有专门处理 ssh 进程清理实际操作中如果发现 ssh 进程占用 CPU 居高不下可以用 pkill 精确匹配同步目标路径来清理不要直接 pkill ssh 把所有连接都干掉那样影响面太大。4.3 验证同步结果的几种方法同步完成后怎么确认两边目录一致是很多人容易忽略的步骤。我常用三种方式。第一种是看 rsync 的日志统计。正常完成的日志末尾会有类似 “Number of files transferred” 的统计。如果传输文件数比上一次少很多要留意是不是源目录被误清理了。第二种是手动跑一次rsync -av --delete --dry-run对比两边差异。dry-run 模式不做真实修改只输出会变化的文件。如果输出的文件列表为空说明两边已经完全一致。第三种是文件数量抽查find /webdata -type f | wc -l find /backup/webdata -type f | wc -l数量差距特别大的时候优先检查是不是排除规则写错了导致一部分目录没被同步过去。我遇到过排除规则把*/cache/*写成了*cache/*结果含 cache 子路径的目录全部被跳过数量对不上排查了很久。5. 进阶改造从“能跑”到“好维护”5.1 多规则并行与带宽限制配置文件支持多规则后脚本默认是逐条串行同步的。串行的好处是资源和日志都清晰缺点是如果两条规则的目录之间没有依赖关系串行会让整体时间变长。数据量大、网络也够宽的机器上可以考虑按目录拆分多个实例跑。比如把配置分成两个文件crontab 里分别调用30 2 * * * /usr/local/bin/rsync_sync.sh -c /etc/rsync_sync_web.conf 40 2 * * * /usr/local/bin/rsync_sync.sh -c /etc/rsync_sync_db.conf这样两个实例同时跑前提是目标路径不能重叠否则 flock 锁相互之间没有感知同时写同一目录会乱。我目前的习惯是同一条链路单任务跨链路才并行稳妥第一。跨公网同步时要关注带宽占用。rsync 可以在命令里加--bwlimit限制传输速度比如--bwlimit10000表示限制在 10MB/s 左右。这个限制是按传输速率算的适合业务高峰期不想被备份流量占满带宽的场景。我一般白天不跑大任务只会对不重要的目录加 bwlimit。5.2 用硬链接做历史版本快照rsync 有一个非常实用的扩展玩法结合--link-dest做快照。原理是把上一次同步的结果作为参考目录新一次的同步先把引用目录里的相同文件硬链接到新快照目录真正变化的文件才会被复制。效果上就是每个时间点都有一个完整目录结构但没变化的文件不占额外空间磁盘占用只跟两次同步之间的差异有关。用法大致是PREV$(ls -t /backup/snapshots | head -1) rsync -av --delete \ --link-dest/backup/snapshots/$PREV \ /webdata/ /backup/snapshots/$(date %F_%H%M)/这样配合脚本里的配置文件规则就能把原本的“单份增量同步”升级成“带历史版本的增量同步”。如果哪天线上文件被误删或者被加密病毒破坏可以从快照目录找回上一个版本这种事遇到一次就值得。5.3 远程同步和异地容灾场景脚本里目标路径写的是本地路径但 rsync 本身天然支持远程目标。只要把配置里的目标项写成userremote:/backup/webdata并且提前配置好 SSH 免密登录脚本逻辑完全不用改。我之前就在本地备份之外加了一条远程规则把数据库备份目录同步到另一台存储服务器上。这种方式比本机双硬盘更加安全因为本机两台磁盘同时损坏的概率虽然低但机房断电、系统崩溃这些情况仍然可能一起报销分开存放能显著降低单点风险。远程同步的配置细节主要是 ssh 免密。用用户执行 crontab需要把这个用户主目录下的公钥加到对端的 authorized_keys 里并且建议用ssh-keyscan提前写入 known_hosts否则首次连接会出现交互确认脚本卡住。另外远程同步建议在配置里启用压缩和超时因为跨网络的不确定因素比本地多很多。还要注意对端磁盘空间监控rsync 不会因为对端空间不足自动暂停日志里只会留下空间不足的写错误没有提前告警可能会一直浪费带宽重试。结尾说点实在的。我一开始用 rsync 也只是简单的命令行记录后来踩了几个坑才开始认真设计脚本。第一个坑就是第一次全量同步没加 dry-run把目标目录里积累了半年的历史文件全部清了好在那次目标目录是新建的损失不大但让我记住了必须预览差异。第二个坑是没有锁crontab 同时起了三个 rsync 进程把存储扛崩了。后来才逐步把脚本完善成现在的样子。如果你准备把这个脚本接到 crontab 里我建议先跑一周 dry-run每天看日志确认变化量符合预期再切换为真实模式。同步工具再强也得跑一段时间验证过才放心。