Linux tar 打包与压缩实战:从归档原理到增量备份

tar 是 Linux 上最经典的归档与备份工具:软件源码包、容器镜像层、服务器迁移、定时备份,几乎都离不开它。但很多人只会一句 tar -zxvf,对它的核心概念、压缩算法选型、增量备份这些进阶能力并不清楚。这篇文章从原理讲到实战,最后在真实服务器上做了一组压缩对比实测,帮你一次搞懂 tar。

先分清:归档与压缩是两回事

tar 名字来自 Tape Archive(磁带归档),它的本职工作只有一件事:打包——把一堆文件和目录合并成一个文件,并且保留文件权限、属主、时间戳、符号链接、空目录等元信息。

压缩是 gzip、bzip2、xz、zstd 这些工具的事,tar 本身并不压缩。两者通过管道协作:

tar -cf archive.tar dir1 dir2        # 只打包,不压缩
tar -czf archive.tar.gz dir1 dir2    # 打包 + gzip 压缩

所以 tar -czf 可以拆解为「tar 打包 → 管道 → gzip 压缩」。理解这一点,很多疑问就迎刃而解:比如已压缩的归档不能追加文件(tar -rf 只对未压缩的 .tar 生效),因为压缩流不支持原地追加。

最常用的打包与解包命令

# 创建归档(打包)
tar -cf backup.tar /home/user/docs /etc/nginx

# 查看归档内容(不解压)
tar -tf backup.tar

# 解包(自动识别压缩格式,无需指定 z/j/J)
tar -xf backup.tar
tar -xf backup.tar -C /restore/path      # 解包到指定目录

# 追加文件(仅未压缩归档)
tar -rf backup.tar /home/user/newfile

几个高频选项:

注意 tar -czf 的 -f 必须紧跟归档文件名,所以 tar -czf backup.tar.gz dir 里 backup.tar.gz 才是文件参数,别把顺序写反。

四种压缩算法实测对比:gzip vs bzip2 vs xz vs zstd

选哪个压缩算法,取决于你要「快」还是「小」。为了给你真实数据,我在一台 Ubuntu 24.04.4 LTS 服务器(GNU tar 1.35,四种压缩工具均已安装)上,对同一份 26MB、734 个文件的文本数据(系统日志 + 文档 + locale 数据)分别用四种算法打包,结果如下:

可以看到,zstd 用了 gzip 六分之一的耗时,得到了几乎相同的大小;而 xz 虽然比 gzip 再小 28%,代价是 12 倍的压缩耗时。速度与体积的取舍非常直观。

怎么选

• 日常备份、脚本自动化:gzip,兼容性最好,任何机器都能解;
• 新项目、内部传输:zstd,又快又小,zstd 解压速度也是最快的;
• 软件发布、长期归档:xz,体积最小,适合一次压缩、多次下载分发(内核源码包、发行版镜像都在用);
• bzip2:被 zstd 全面超越,新项目不必再考虑。

zstd 支持在 GNU tar 1.31 引入,1.35 起 --zstd 成为正式选项,.zst / .tzst 后缀也会被 tar 自动识别为 zstd。Ubuntu 22.04+ 自带 tar 1.34/1.35 和 zstd,可以放心用。

一个常见误区:对已压缩数据再压缩

日志轮转出来的 .gz、图片、视频、压缩包,里面已经是压缩数据,再打包压缩几乎不会再变小,反而白白消耗 CPU。备份时可以显式排除:

tar --exclude='*.gz' --exclude='*.png' --exclude='*.mp4' -czf backup.tar.gz /var/log /data

不解压也能办事:查看与提取技巧

几百个文件的归档,没必要先整个解压再找文件。tar 支持直接在归档内检索和单文件提取:

# 列出归档内所有条目(不解压)
tar -tzf backup.tar.gz | head -6

# 统计归档内文件数
tar -tzf backup.tar.gz | wc -l        # 744 个条目

# 在归档内搜索指定文件
tar -tzf backup.tar.gz | grep auth.log

# 只提取一个文件到指定目录
tar -xzf backup.tar.gz -C /tmp/extract logs/auth.log

# 提取后直接查看内容
head -3 /tmp/extract/logs/auth.log

上图演示:26MB 的归档共 744 个条目,不用解包,直接定位并单独提取出 logs/auth.log,再 head 查看前几行日志——省时又省磁盘。

增量备份:--listed-incremental 一次只存变化

全量备份每次都重新打包全部数据,费时费空间。tar 的 --listed-incremental 用快照文件(snar)记录每个文件的状态,第二次打包时只把变化过的文件写进归档——这就是增量备份:

# 第一次:快照文件不存在,tar 做全量备份,并建立快照
tar --listed-incremental=/root/snapshot.snar -czf full.tar.gz docs logs

# 修改数据后:第二次打包,只写入变化的文件
echo "root: 追加一条新日志" >> logs/cron-demo.log
tar --listed-incremental=/root/snapshot.snar -czf inc.tar.gz docs logs

实测效果非常直观:全量包 6.0M,而改动一个文件后的增量包只有 6.9K(归档里只有被修改的 logs/cron-demo.log 等变化内容)。日积月累,增量备份能省下大量存储和传输时间。

恢复方法

增量备份的恢复顺序是:先解全量,再按时间顺序依次解各个增量包:

tar -xzf full.tar.gz -C /restore
tar -xzf inc.tar.gz  -C /restore        # 按备份顺序依次执行

两个坑

• snar 快照文件必须保留:它是判断「哪些文件变了」的基准,丢了就无法继续增量,只能重新全量;
• 增量包不能独立恢复:它依赖全量包作为基线,单独解出来是不完整的。

实战:不落盘的管道传输与定时备份

服务器间直接传输归档

不用先打包、再 scp、再解压三步骤,一条管道让数据流经 SSH 直达目标:

# 本地打包,直接写到远端(不产生中间文件)
tar -czf - /data | ssh user@backup-server 'cat > /backup/data.tar.gz'

# 更彻底:远端直接解包
tar -czf - /data | ssh user@backup-server 'tar -xzf - -C /restore'

定时增量备份

把 --listed-incremental 和 cron 结合,就是一套实用的备份方案:周一全量,其余每天增量,find 定期清理 30 天前的备份:

# 每周一凌晨 2 点全量,其余每天凌晨 2 点增量
0 2 * * 1 tar --listed-incremental=/backup/snap.snar -czf /backup/full-$(date +\%F).tar.gz /data
0 2 * * 2-7 tar --listed-incremental=/backup/snap.snar -czf /backup/inc-$(date +\%F).tar.gz /data

备份脚本的最后一道防线

备份完先验证归档能正常读取,再让它进入保留区——否则备份是坏的,灾难恢复时才发现就晚了:

tar -tzf /backup/data.tar.gz >/dev/null && echo "备份完整,可正常读取" || echo "备份异常!"

总结

掌握「归档与压缩分离」的原理、四种算法的取舍、增量备份的用法,日常的打包、传输、备份需求就都能从容应对了。

参考资料

• GNU tar 1.35 官方手册(压缩章节)
• Cygwin:tar 更新至 1.35,启用 ZStandard 支持
• Linux 压缩命令实战:tar、gzip、bzip2、xz、zstd 怎么选
• zstd 官方文档