主机到备机的tar同步脚本：轻量冷备方案与实战经验

没有哪个运维能逃过“主机传备机”这件事我在这件事上折腾了好几轮之后最终的即时方案竟然是一套tar同步脚本。倒不是说rsync不好而是在某些存量环境里tar配合ssh管道反而更轻、更直接尤其是备机常年不开机、只做周期性冷备的场景。这里把我在实际生产环境里敲定的思路、脚本、以及踩过的坑完整梳理一遍给同样需要“主机到备机的tar文件同步”的朋友一个可以直接抄作业的版本。1. 为什么绕了半圈最后选了tar而不是rsync或SCP先聊聊选型问题。很多人一听到同步条件反射就是rsync。但我的场景比较特殊主机是一台跑着老旧业务系统的服务器备机平时完全离线只有每周做一次快照式同步。这种“主机主动往外推冷备”的操作用rsync虽然也能做但会有两个让我不太舒服的地方一是rsync在备机上需要确保daemon或远端shell环境稳定如果备机系统很旧、权限限制又多配置成本不低二是rsync是面向“差异同步”设计的它会逐文件比对在文件数量很大但实际变化不多时扫描阶段会吃掉不少主机CPU和磁盘IO。tar的命令行工具几乎是所有类Unix系统的标配不需要备机额外装服务也不需要远端开rsyncd。我只需要一条管道把本地打包后的数据流直接灌给备机的“解包端”整个过程不落中间文件。说白了tar同步脚本的核心不是“同步”而是“打包-传输-解包”的流水线这个模式在备机处于冷备状态时天然合适。再看SCP。SCP适合传单个文件如果我要传一堆散文件要么先tar再scp要么scp -r递归整个目录。但scp -r有个问题它不保留所有元数据例如硬链接关系、部分文件时间戳、ACL这类信息在跨主机同步备份时很容易丢。tar打包后传输至少能在归档层面把权限、时间戳、属主信息尽量保留下来再用root身份解包基本能做到原样还原。另外SCP没有恢复中断的能力传输一半断了就得重来tar管道配合ssh也没法断点续传但我可以在脚本层面做包完整性校验和重试这个后面细说。还有一个很实际的原因备机的磁盘空间通常有限SCP传一堆未压缩的散文件会占用大量inode和空间tar打包后如果走压缩管道在备机上落地的就是一个压缩包或者一个待解包的数据流文件粒度小空间利用率更高。备机上要的是一个干净的归档文件集合不是一堆散落各处的目录。所以最终结论是当同步目标是一台冷备机、同步方向是单向、主机不希望安装额外依赖时tar ssh是比rsync更省事且更可控的方案。如果你的场景是双机热备、需要实时增量双向同步那肯定还是要上rsync或专用工具这套tar脚本只解决“周期性把主机状态推到备机”这一件事。1.1 我实际要解决的业务形态具体到我这边的场景主机每天产生一批业务数据文件目录结构大概是 /data/app/logs和 /data/app/files日志按日期组织业务数据文件有部分是软链接指到共享存储上。备机的角色是“七天冷备”也就是每周同步一次保留最近四周四个完整快照超过四周边清理边覆盖。同步时主机处于业务运行中所以不能停服务tar打包时要用--ignore-failed-read和--warningno-file-changed之类的参数避免因为文件正在写入而报警或中断。1.2 备机和主机之间的网络环境我的主机和备机之间使用专网互通没有走公网所以安全性主要靠内网隔离SSH密钥。ssh密钥我单独建了一个同步用户公钥放在备机的authorized_keys里私钥只在主机脚本中使用并且用ssh_options限制了这个key只能执行特定命令防止被滥用。这些细节不复杂但很多入门阶段的朋友会忽略一旦同步用户被攻破备机就等于裸奔。我这个脚本里用到的ssh命令都会显式指定密钥文件和禁用密码登录。2. 一条管道打通主机和备机tar与ssh的三种组合姿势tar同步脚本最核心的传输思路是“不落本地文件直接走管道”。本地tar打出来的数据流通过stdout交给sshssh在远端再交给备机上的命令去消费。同一个想法有三种不同的写法适用场景各不相同。2.1 远程直接落盘成tar包tar -czf - /data/app/files | ssh syncuserbackup-host cat /backup/files-$(date %F).tar.gz这条命令会把主机上的 /data/app/files 打包压缩然后以stdout数据流方式发送到备机备机把流原样写入 /backup 下的tar包文件。这样做的好处是备机上保留一份完整的压缩归档方便后续拉取历史包。我最早用的就是这个姿势简单直接但有个明显问题如果主机文件特别大数据流在网络上传输期间备机端磁盘没有任何文件元信息一旦中间断开备机上只会留下一个半截压缩包无法读取。2.2 远程直接解包还原目录结构tar -czf - --exclude*.log.tmp /data/app/files | ssh syncuserbackup-host cd /backup/restore tar -xzpf -这个姿势更接近“同步”的语义备机端不是保留包而是直接还原目录结构。它在备机上进入/backup/restore目录后把管道传过来的数据流解包到当前目录。好处是不需要再手写解压步骤适合备机需要“即时可用的副本”的场景。注意这里用了 -p 参数解包时保留权限默认普通用户执行tar解包会丢失属主信息只有root或者同名用户才能完整还原。2.3 先传后解包备机同时保留包和目录tar -czf - /data/app/files | ssh syncuserbackup-host cat /backup/tmp.tar.gz tar -xzpf /backup/tmp.tar.gz -C /backup/restore这个方案是在备机上先落一个临时tar包然后立刻把它解压到还原目录。好处是既有归档备份又有副本坏处是备机磁盘需要双倍空间。如果备份目录很大我不建议这么干容易把备机磁盘打满。我在生产脚本里改成了“先写入临时文件、校验通过后再改名”兼顾了两种思路具体在后面的脚本章节展开。2.4 管道传输的注意事项管道传输虽然有“不进本地盘”的优势但也意味着tar的退出码无法直接影响ssh链路的另一端。本地tar如果因为文件被并发写入而报错退出数据流可能已经发了一半备机端会收到一个不完整的包。所以只靠管道裸传我很难判断备机上的结果是否完整。解决办法有两个一是在tar命令里加--warningno-file-changed让文件发生变化时只警告不退二是在备机端对接收到的tar包做退出码判定和大小记录回到主机端做交叉核对。更稳妥的做法是配合后面的sha256校验而不是只看tar的返回值。3. 全量同步之外tar增量备份的落地细节如果每次都全量打包几TB数据备机磁盘和主机IO都扛不住。tar其实自带增量能力通过 --listed-incremental 或 -g 参数记录快照状态本质上是一种基于“上次打包后文件是否变化”的增量归档。这个功能很多人用过但了解不够深我用实际经验把关键点拆开讲。3.1 快照文件-g是怎么回事tar -g /backup/snapshot.snap -zcf /backup/incr-$(date %F).tar.gz /data/app第一次执行时/backup/snapshot.snap 不存在tar会做一次全量归档同时把每个文件的元数据记录到snapshot.snap中。第二次执行时tar会读取snapshot只把新增和变化过的文件放进归档包并更新snapshot。也就是说snapshot文件是“上次状态”的数据库多个增量包之间必须依赖同一个snapshot文件才能正确恢复。要特别注意的是snapshot文件本身不是增量包内容的索引它记录的是归档时点的目录树状态。tar判断文件是否变化靠的是mtime、大小、inode等信息。如果你在两次增量之间用touch命令重写了某个文件的mtime即便内容没变它也会被打进增量包。3.2 恢复时的顺序问题增量备份恢复时不能只解包最后一个增量包必须从首次全量包开始按顺序叠加解包。比如周一是全量full.tar.gz周二是incr-1.tar.gz周三是incr-2.tar.gz恢复顺序就是full - incr-1 - incr-2。tar对同名文件默认后面覆盖前面所以顺序错乱会导致数据停留在错误版本。增量恢复的操作示例mkdir -p /backup/restore cd /backup/restore tar -xzpf /backup/full.tar.gz tar -xzpf /backup/incr-1.tar.gz tar -xzpf /backup/incr-2.tar.gz如果你用的是 -g snapshot.snap 模式恢复时并不需要snapshot文件参与snapshot只负责生成增量包。所以备份机上的归档策略最好是“定期把全量和所有增量包一起打包封存”不要只留增量包否则首次全量的包一旦丢了后面所有增量包都变成废数据。3.3 增量频率设计我自己的经验是一周一次全量到备机每天一次增量到主机本地临时目录等周末全量时再统一推过去。如果你的数据变化不大也可以不做每日增量直接在备机上保留多个全量慢照。快照越多备机占用的磁盘越大通常保留四周全量就够了。增量包的文件名里必须带完整日期时间例如incr-2025-05-17-23-30.tar.gz不然脚本在展示归档列表时会一团糟。4. 主机到备机同步脚本的完整落地命令行能跑通只是第一步能交给crontab连续跑半年不出事的脚本才算数。下面这个脚本是我目前在用的简化版去掉了部分业务敏感路径保留核心骨架。它的特点是预先定义好主机目录、备机目录、保留份数、日志路径使用ssh密钥指定连接利用临时文件落库避免半截包直接混入归档区每次同步完自动做gzip完整性检测和大小记录。#!/usr/bin/env bash set -euo pipefail # 主机侧配置 SOURCE_DIRS( /data/app/files /data/app/logs ) BACKUP_DB/backup/snapshot.snap BACKUP_TMP/backup/.tmp # 备机侧配置 BACKUP_USERsyncuser BACKUP_HOSTbackup-host BACKUP_TARGET/backup/archive # 保留备份份数 KEEP_DAYS30 # 日志 LOG_FILE/var/log/tar_sync.log log() { echo $(date %Y-%m-%d %H:%M:%S) $* ${LOG_FILE} } create_full_backup() { local stamp stamp$(date %F_%H-%M-%S) local pkg_namefull-${stamp}.tar.gz log 开始全量备份${pkg_name} tar -g ${BACKUP_DB} -zcf ${BACKUP_TMP}/${pkg_name} \ --exclude*.log.tmp \ --ignore-failed-read \ --warningno-file-changed \ ${SOURCE_DIRS[]} # 校验包完整性 if ! gzip -t ${BACKUP_TMP}/${pkg_name}; then log 全量包完整性校验失败中止 return 1 fi # 推送到备机保留归档路径 cat ${BACKUP_TMP}/${pkg_name} | ssh -i /root/.ssh/id_backup_rsa \ ${BACKUP_USER}${BACKUP_HOST} \ cat ${BACKUP_TARGET}/${pkg_name} log 全量备份推送完成${pkg_name} } create_incr_backup() { local stamp stamp$(date %F_%H-%M-%S) local pkg_nameincr-${stamp}.tar.gz log 开始增量备份${pkg_name} tar -g ${BACKUP_DB} -zcf ${BACKUP_TMP}/${pkg_name} \ --exclude*.log.tmp \ --ignore-failed-read \ --warningno-file-changed \ ${SOURCE_DIRS[]} if ! gzip -t ${BACKUP_TMP}/${pkg_name}; then log 增量包完整性校验失败中止 return 1 fi cat ${BACKUP_TMP}/${pkg_name} | ssh -i /root/.ssh/id_backup_rsa \ ${BACKUP_USER}${BACKUP_HOST} \ cat ${BACKUP_TARGET}/${pkg_name} log 增量备份推送完成${pkg_name} } cleanup_old() { log 清理备机上的旧归档 ssh -i /root/.ssh/id_backup_rsa ${BACKUP_USER}${BACKUP_HOST} \ find ${BACKUP_TARGET} -name *.tar.gz -mtime ${KEEP_DAYS} -delete } main() { # 清理主机本地临时文件 mkdir -p ${BACKUP_TMP} if [ ! -f ${BACKUP_DB} ]; then create_full_backup else create_incr_backup fi cleanup_old } main4.1 脚本设计的几个关键决定我把快照文件放在主机的/backup路径下没有放到备机。这样每次执行tar时主机能直接读取snapshot判断增量内容如果我把snapshot放到备机上每次同步时还要先把snapshot拽回来链路就复杂了。快照文件会随着数据量增大而增长但它记录的是文件元信息通常只有几百KB到几MB级别放在主机侧完全可接受。使用临时文件目录 /backup/.tmp是因为直接cat流到备机再cat成目标文件可能让备机上的归档目录出现半截包。而先在主机本地生成完整包并做gzip -t校验然后push到备机能确保只有完整包才会进入归档目录。当然ssh链路中断仍可能产生半截的远端文件所以脚本里没有校验远端文件大小是否等于本地包大小这点我在下一节讲排查时再补充。4.2 为什么用gzip而不是zstd或不做压缩我早期也用zstd做过压缩压缩率确实更高但备机上的解压工具未必带zstd为了跨系统兼容性最终回到gzip。压缩级别上用默认的-6压缩机相较均衡。如果主机CPU不紧张可以改成-9如果带宽很小而CPU很强可以试试用pigz并行压缩tar -cf - ... | pigz -4 | ssh ...pigz是gzip的多线程版能把单个大文件的压缩速度提升数倍在同步几个GB到几十GB的数据时体感差距很明显。如果你的系统里没有pigz先安装再使用。4.3 crontab和systemd定时器选哪个我现在的环境里用的是crontab因为这套主机是存量机器不想引入systemd常驻进程改动。crontab写法# 每周日凌晨2点执行备份 0 2 * * 0 /usr/local/bin/tar_sync.sh /var/log/tar_sync_cron.log 21crontab有个坑它的PATH环境比登录shell小很多脚本里的tar、ssh、gzip等命令必须写绝对路径或者在脚本开头显式export PATH。上面脚本为了简洁没有加实际使用时建议在脚本开头加上export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin如果系统用systemd我更推荐用systemd timer因为能通过service单元管理日志、依赖、超时日志也能进journalctl统一查看。timer的写法也很直观一个.service文件定义执行命令一个.timer文件定义执行周期和随机延迟避免多台主机的备份在同一时间点集中打满网络。随机延迟是备机集群里非常实用的功能。5. 这半年同步脚本踩过的坑和排查思路脚本能跑起来是简单的事真正值钱的是遇到故障时的排查链路。我把使用这套脚本期间踩过的坑整理成下面几类每类都附上现象和定位方法方便你直接对照。5.1 tar退出码为0但备机上的包是坏的这是我早期踩过最隐形的一个坑。本地tar执行成功退出码0推到备机后包却打不开。定位后发现问题出在“文件在打包过程中被业务进程修改”tar在读取某个日志文件时文件正好被截断tar虽然通过--warningno-file-changed绕过了报警但生成的包内容是自洽的只是和磁盘上的最终文件不一致。gzip -t只能验证压缩流结构完整验证不了“文件内容是否最终版本”。解决办法是在还原端不依赖包而是把备机还原当成“尽力而为的副本”真正的数据一致性还要靠业务侧的快照或数据库的binlog保证。对同步脚本而言能做到的就是确认压缩流完整、归档内文件可正常解出。tar -tf列出归档内容并随机抽几个文件做内容比对是成本较低也比较有效的校验方式。我在关键文件的处理上还会配合diff但这不属于tar脚本本身的能力。5.2 管道传输中途断开备机留下半截文件ssh链路如果因为网络抖动断开主机侧tar可能已经执行完备机的cat进程被中断远端文件大小停在某个值。排查时先看本地包大小和远端包大小是否一致# 主机侧 ls -l /backup/.tmp/full-*.tar.gz # 备机侧 ssh syncuserbackup-host ls -l /backup/archive/如果两个size一致大概率没问题如果不一致基本就是链路中断。我现在的脚本会在推送后追加一个校验大小动作把本地字节数传给远端再把远端字节数比对不一致时把远端半截文件改名成.broken后缀保留现场后重推。5.3 tar -g增量快照在备机恢复时出现重复或缺失文件增量恢复时容易出现文件重复原因多半是增量包和全量包的目录层级不统一。比如全量打包时用了绝对路径 /data/app解包时会解到当前目录的 /data/app 下增量打包时如果用了相对路径 app解包位置就变成 /data/app 下的 app 目录这样会导致目录嵌套错位。我的习惯是在脚本里固定统一路径写法cd /data tar -g /backup/snapshot.snap -zcf /backup/test.tar.gz appcd /data后再以相对路径app打包解包时也先cd到解包目标目录再执行tar -xzf path/app保证所有包都能解到同一目录树。这个细节不处理好增量恢复出来的副本结构一定是对的但内容可能缺失。5.4 备份目录包含大量小文件时tar反而比rsync快小文件数量特别多时rsync的逐文件比对扫描会消耗大量CPU而tar直接读目录并写入归档流顺序读的效率更高。我之前同步一个包含40万个小文件的目录rsync全量同步大约需要2小时tar管道全量同步大约40分钟。两者在“是否比较内容”上设计不同tar把文件完整写入归档并传输rsync要先检查文件是否需要传输所以小文件多时tar的优势反而明显。但tar的劣势是“只认状态不认内容”如果只改了一个大文件的中间几KBtar依然会把整个大文件打进去而rsync只传差异块。所以大文件日常有零散修改、且带宽很贵的场景不要硬用tarrsync更合适。我的实际策略是业务数据这类小文件多的场景用tar数据库备份文件这类大文件场景用rsync。6. 把同步脚本变成一套可维护的备份习惯脚本本身不复杂但它给我带来最大的改变是主机到备机的同步从“随手敲命令”变成了“可预期、可监控、可清理”的固定动作。这里分享几个让我长期省心的扩展习惯。6.1 每次同步完我会附加一份备份清单除了tar包本身我会在备份目录下同步生成一份manifest.txt内容包含备份时间、包名、文件数目、总字节数、sha256值、gzip完整性检查结果。这样备机上的归档不是一片死文件将来某天需要紧急恢复时能通过manifest快速定位该恢复哪个包。生成逻辑也很简单sha256sum /backup/.tmp/full-*.tar.gz | ssh syncuserbackup-host cat ${BACKUP_TARGET}/manifest-\$(hostname).txt6.2 清洗策略不光是删旧包还要看磁盘水位单纯find -mtime 30 -delete有时会把重要包在磁盘紧急状态下误清理掉我建议在清理前先检查备机磁盘可用空间低于阈值时强制保留更多备份local avail avail$(ssh syncuserbackup-host df /backup | awk NR2 {print \$4}) if [ ${avail} -lt 10485760 ]; then log 备机剩余空间不足10GB跳过清理 return 1 fi6.3 出现“同步失败”时我自己的第一反应是看哪类错误这套脚本运行半年我总结了一个处理排查清单错误表现最可能原因第一步检查tar: Cannot open: No such file or directory源目录被业务删除或路径变化确认目录是否存在ssh: Connection refused备机未开机或sshd未启动ping telnet 22端口ssh: Permission denied密钥失效或同步用户被改名手动ssh -i测试gzip: invalid compressed data包被截断或本地IO异常gzip -t检查包本身tar: Error is not recoverable文件在归档中变化过大查看是否有进程写目录备机磁盘满日志或历史包堆积df -h检查水位6.4 未来的一个扩展思路接入监控告警我目前是让脚本把同步结果写入日志再通过日志采集上报给监控系统同步失败时触发告警。如果你的环境里没有现成的监控最简单的做法是在脚本末尾加一个失败echo让crontab通过MAILTO把输出发到邮箱。无论用哪种方式一定要让“失败”变得可见否则备份只是存档没有实际意义。对我来说tar同步脚本从来不是终点对备份结果的可验证性才是所有人都该补上的最后一公里。