Linux压缩命令避坑指南：tar、gzip与zip的选型、备份与恢复

1. 从一次翻车说起：压缩命令选错会怎样？

在 Linux 上待得越久，越不敢小看压缩命令。很多人觉得这不过是“打包”和“解压”的小事，可一旦放到生产服务器上，选错参数、选错算法、没看磁盘空间，几分钟就能把线上环境搞出大问题。linux 常用命令里，压缩命令绝对是最容易出“事故”的一类。这篇文章里的每一段内容，基本都来自我亲手踩过的坑，不光是告诉你命令怎么写，还想把命令背后的原理、适用场景、保命经验一起讲清楚，让你看完之后能少走几条弯路。

我记得很清楚的翻车现场有很多次，最典型的一次是给日志目录做备份。日志这种文件，全是文本，本来压缩率应该很不错，结果我用了一条自认为“标准”的命令，不仅备份失败，还差点把生产分区填满。那次之后我开始沉下心研究 Linux 下各种压缩工具的区别，而不是背几条命令就觉得自己会了。

1.1 那次备份日志时的“磁盘杀手”

当时的情况是：应用服务器上有三个月的日志，目录大概 800MB 左右，我准备压缩归档到备份盘。因为平时习惯了 tar czf，我抬手就是：

bash复制tar czf /backup/logs_2024.tar.gz /data/logs

问题出在哪？问题出在那个备份分区总共只有 1GB 可用空间。文本日志虽然压缩比高，但 /data/logs 里还有几个没轮转的几十 MB 大文件正在被应用持续写入，压缩过程中文件还在涨。tar 一边读文件一边写压缩包，写到一半备份分区满了，命令直接报错退出，留下一个残缺的 .tar.gz 文件。更要命的是，那个分区满了以后，同一个分区上运行的监控脚本也开始写不了临时文件，间接影响到了正常的日志采集。最后我处理完残包、清理了空间，才把这一串连锁反应压下去。

那次我只记住一个教训：压缩命令操作的是大文件、大目录，执行前第一件事不是背参数，而是看磁盘空间。

bash复制df -h /backup
du -sh /data/logs

如果备份目录和源目录在同一个分区，还需要确认目标盘剩余空间是源目录的好几倍。这里说的“好几倍”不是翻倍，因为你还要考虑到期间可能会有新的数据写入。备份类操作永远要把空间余量放宽，否则压缩中途失败是大概率事件。

1.2 先搞清楚：打包和压缩其实是两回事

tar 这个命令的名字来自 Tape Archive，最初设计出来是为了把多个文件“归档”到一盘磁带上，本身并不负责压缩。我们常说的 tar.gz，实际上是先用 tar 把一堆文件打包成一个 tar 包，再用 gzip 对这个包做压缩。如果你把这两件事混在一起，很多问题就会变得不好理解。

可以用一个生活类比：tar 做的事情是把散落在房间里的衣服一件件叠好塞进收纳袋，gzip 做的事情则是把收纳袋里的空气抽掉，让体积变小。tar 关心的是“有没有少一件衣服、顺序对不对、权限有没有保留”，gzip 只关心“能不能把 1 变成 0”，两者目标完全不同。

所以你在 Linux 下经常会看到这几种格式：

• .tar：只归档，不压缩，体积和原始文件总和差不多
• .tar.gz：tar 打包后经 gzip 压缩，速度较快，使用最普遍
• .tar.bz2：tar 打包后经 bzip2 压缩，压缩率通常更高，速度更慢
• .tar.xz：tar 打包后经 xz 压缩，压缩率最高，但最耗时
• .zip：自带归档和压缩能力，不依赖 tar
• .gz、.bz2、.xz：单独压缩单个文件，不保留多文件目录结构
• .tar.zst：tar 打包后经 zstd 压缩，速度和压缩率比较均衡，新环境里越来越多

不少人第一次看到 tar -czf 和 tar -cjf 时都会把 c、z、j、f 当成一堆神秘字母。其实拆开看就很简单：c 表示 create，创建包；f 表示 file，后面跟着的文件名；z 表示用 gzip 压缩；j 表示用 bzip2 压缩；J 表示用 xz 压缩。没有 z/j/J 的 tar 命令，就只是打包不压缩。

理解这一点以后，你至少能避开一个经典坑：直接对单个文件执行 gzip access.log，会生成 access.log.gz，原文件消失；但如果你想压缩一个目录，gzip 自己干不了，必须先 tar，或者用 zip 这类自带归档能力的工具。

2. tar 才是 Linux 压缩的绝对主角：常用组合拆开讲

tar 在 Linux 系统里基本是默认安装的，你几乎找不到一台没有 tar 的发行版。日常维护、备份、发布代码、迁移目录，遇到“多个文件+目录结构”这种场景，优先想到 tar 总是对的。下面这些命令，我基本每天都在用。

2.1 最常用的创建和解压组合，到底拆开看是什么

创建一个 tar.gz 压缩包的标准写法：

bash复制tar -czf project_backup.tar.gz /home/user/project

这条命令的含义是：把 /home/user/project 目录打包，然后用 gzip 压缩，输出到当前目录下的 project_backup.tar.gz 文件。解压到当前目录时用：

bash复制tar -xzf project_backup.tar.gz

x 就是 extract，解压。很多人喜欢写成 tar -zxvf，多出来的 v 表示 verbose，把处理过程中的文件名打印出来。如果你在脚本里用，建议不要加 v，否则日志会非常长，而且会影响一定性能。

记住一个原则：文件名最好写在 f 的后面，而且不要在这个位置后面再接别的参数。tar 的 f 参数有些“挑食”，如果写 tar -zcfv，它可能会把 v 当成文件名的一部分。写参数时保持 c、z、f 这种顺序问题不大，因为 GNU tar 允许简写合并，但别为了省事把 f 后面跟的文件名和参数混在一起。想更保险就直接写：

bash复制tar --create --gzip --file project_backup.tar.gz /home/user/project

这种长格式参数虽然输入麻烦，但放到脚本里可读性非常好，尤其适合给新人交接时用。

还有一个省盘技巧：如果目标是临时打包到另一台机器，或者只是想把目录结构原样搬走，用 tar -cf 直接打一个不压缩的包，速度比 gzip 快很多。很多场景下网络传输时间比本地压缩时间短，尤其是压缩 PDF、图片、视频这种本身已经高度压缩过的文件，gzip 一遍几乎没有任何收益，纯属浪费 CPU。

2.2 为什么有人用 jzf，有人用 Jzf？三个后缀别有洞天

当系统里有大批文本、日志、配置文件、数据库备份，我一般会根据需求选择不同压缩算法。tar 参数里的 z、j、J 分别对应 gzip、bzip2、xz。很多博客会用“更高压缩率”这几个字含糊带过，但实际选择远没那么简单。

我整理了一张常用对照表，方便你在不同场景下做判断：

只看压缩率的话，对同一份文本日志，xz 往往能比 gzip 再小 20% 到 30%。但 xz 的代价是 CPU 占用高，压缩时非常慢。如果你的机器本身堆满业务，为了压缩一个日志让 xz 占满 CPU 好几分钟，很容易影响线上业务。这种情况我会直接 tar -czf，用 gzip 的默认级别把负载降下来。机器负载和压缩时间之间，很多时候得优先保前面的安全，而不是一味追求那百分之几的体积。

2.3 tar 备份时的保命细节：权限、属主和排除目录

tar 最容易被低估的属性，是它会保留文件权限、时间戳、属主和属组。在做系统备份、迁移网站目录、搬迁用户数据时，这个特性非常重要。比如：

bash复制tar -czf home.tar.gz /home
tar -xzf home.tar.gz -C /

解压时加 -C / 指定解压到根目录，tar 会尽量恢复原来的相对路径。如果你的用户 ID 在目标机器上不同，可能需要加 --same-owner 或者用 root 解压，否则文件属主会变成当前用户。

备份时还经常要排除某些不该进包的东西，比如日志目录里的临时文件、缓存、.git 目录。用下面这些写法可以避开：

bash复制tar -czf site.tar.gz /var/www/site \
  --exclude="*.log" \
  --exclude="/var/www/site/cache" \
  --exclude="/var/www/site/.git"

注意 --exclude 的路径写法，写成相对路径更可靠性。很多人在这上面翻车，明明指定了排除目录，结果打包一开还是有大量 cache 文件，其实就是因为 tar 打包时实际包含的路径和你写的不完全一样。保险做法是先进到目标目录的父级：

bash复制cd /var/www && tar -czf /backup/site.tar.gz --exclude="site/cache" site

还有一个参数 --one-file-system，做整机备份时必须记住。它可以防止 tar 跨越挂载点，不然你以为自己在备份根目录，结果把 /proc、/sys、/dev 这些虚拟文件系统全部打包进去了。生产环境里不要轻易用自己的桌面机器做实验，但可以找个测试容器多试几次，感受一下限制路径后打包出来的体积差异。

3. gzip、bzip2、xz：三种压缩算法的性格完全不同

刚才从 tar 的角度讲了参数，这一节重点看单独执行的压缩程序。虽然 tar 帮我们做了一层封装，但你还是要理解 gzip、bzip2、xz 这三兄弟的真实差异，否则很难解释为什么有的压缩包解压快、有的解压慢。

3.1 我用 1GB 文本日志做的实测对比

我拿一个实际场景做过测试：同一份 1GB 左右的文本日志，分别用 gzip、bzip2、xz 在默认参数下压缩。由于机器配置和时间不同，数字只能作为参考，但比例关系很有代表性：

如果你只追求小体积，xz 非常有优势。接近 1GB 的文本日志能压成 80MB，比 gzip 小不少。可它花了整整 8 分钟，占 CPU 也非常猛。这个测试里机器负载不高，如果换到业务高峰期，我根本不会拿 xz 压大型目录。

gzip 能做到速度和压缩率的平衡，所以它成了 Linux 世界里默认的“万金油”。你系统里的 man 文档、软件包、日志轮转文件，绝大多数都是 gzip。bzip2 处在中间，但它有个优点：在某些老旧环境里，bzip2 的支持比 xz 更成熟。如果你的服务器是有些年头的发行版，或者要给客户的旧机器做交付，.tar.bz2 可能比 .tar.xz 更稳妥。

3.2 单文件压缩：gzip、bzip2、xz 和 zstd 直接用

当你手上只有一个文件要压缩，不必动用 tar。直接在命令行执行：

bash复制gzip access.log
bzip2 access.log
xz access.log
zstd access.log

执行完以后，原文件会变成 access.log.gz、access.log.bz2、access.log.xz 或 access.log.zst。如果你想把原文件保留下来，用 -k：

bash复制gzip -k access.log

解压对应的是 gunzip、bunzip2、unxz、zstd -d，也可以直接用 gzip -d、xz -d 这种方式。有一点容易搞混：gunzip 解压时如果后面还有 -c，它会把内容输出到标准输出而不是写文件。这在看日志、传数据时非常好用。

比如你不想把 .gz 解压出来就想直接看内容，用：

bash复制zcat access.log.gz | tail -100
bzcat access.log.bz2 | tail -100
xzcat access.log.xz | tail -100

这组命令能帮你省掉“解压-查看-删除”的尴尬操作。每次看到有人把 .gz 解开成一个几百 MB 的文本文件，只为了看一眼最后 100 行，我都替他的磁盘心痛。用管道配合 tail、grep、awk 才是正解。

3.3 压缩级别怎么选：-1 到 -9 不是越高越好

gzip、bzip2、xz 都支持通过 -1 到 -9 设置压缩级别，数字越大，压缩后体积通常越小，消耗时间和内存越多。但多数人并不知道，默认级别并不等于最高的 -9。gzip 默认是 -6，xz 默认是 -6，bzip2 默认是 -9。

有一条很实用的经验：如果你用 gzip 备份超大目录，时间很紧张又不想让 CPU 跑满，可以主动降低级别：

bash复制tar -czf - --use-compress-program="gzip -1" /data/large_dir > large_dir.tar.gz

也可以直接写成：

bash复制tar -c --gzip --level=1 -f large_dir.tar.gz /data/large_dir

不同 tar 版本对 --level 的支持不完全一样，我会用 --use-compress-program 这种方式，兼容性更好。压缩级别 -1 并不是“不压缩”，它仍然会做 deflate 压缩，只是更快。备份前如果磁盘剩余空间还可以，用 -1 往往能让整个备份流程缩短一半以上，对 CPU 的压力也小很多。

xz 特别要注意内存。xz -9 在处理大文件时可能需要几百 MB 甚至更高级别的内存，如果小内存机器上硬跑，可能会被系统 OOM Kill。真要用 xz 压大文件，建议先设置：

bash复制XZ_OPT="-T4 -6"

-T4 让 xz 使用 4 个线程，-6 保持默认级别，别为了极限体积把系统和数据都搭进去。压缩参数最好根据你真实的生产数据做过一轮测试再选，不要照搬网上任何人的“最优配置”。

4. zip/unzip：跨平台场景里绕不开的老朋友

我发现一个现象：很多 Linux 老手会看不起 zip，觉得它太“Windows”。但一旦公司有需求把文件发给 Windows 用户，或者从 Windows 上传文件到服务器，zip 才是省心工具。gzip、xz 在 Windows 上不是不能解压，但终归没有 zip 来得自然。下面这些坑，都是我在跨平台协作中用真金白银换回来的。

4.1 路径结构问题：为什么你解压出来一堆奇怪目录

创建 zip 包时最常见的错误就是路径没有控制好。假设你的服务器上有 /var/www/site 目录，你执行：

bash复制zip -r site_backup.zip /var/www/site

这个压缩包里很可能会带上 var/www/site 这层路径关系，甚至在某些压缩器下面会变成 /var/www/site 这种绝对路径的痕迹。Windows 用户拿到手后解压，发现不是直接得到一个 site 目录，而是一层一层嵌套的父目录，体验非常差。

正确做法是先进入目标目录的父级，再打包：

bash复制cd /var/www
zip -r /tmp/site_backup.zip site

这样解压出来就是一个完整的 site 目录，放在任何地方都不会污染现有目录结构。同理，解压别人的 zip 时，我习惯先看包结构再动手：

bash复制unzip -l site_backup.zip

-l 只是列出内容，不会真的解压。看到包里的第一层路径是什么，再决定是解压到临时目录还是直接解压到目标目录。这个习惯可以避免很多“解压覆盖出错”“目录嵌套混乱”问题。

4.2 中文文件名乱码与加密压缩

跨平台传文件时，中文文件名乱码是我见过最多的问题。Windows 下压缩 zip 时默认字符集可能是 GBK/CP936，而 Linux 下 unzip 默认按 UTF-8 解压，文件名就会出现乱码。解决方案不是去改系统 locale，而是用 unzip 的编码参数：

bash复制unzip -O CP936 chinese_files.zip

但需要注意，不是所有发行版自带的 unzip 都编译了 -O 参数支持。如果你用这条命令报错，可以试 7z 来替代：

bash复制7z x chinese_files.zip

7z 在识别中文编码方面通常比 unzip 更聪明。还有一个更彻底的思路：在 Windows 上压缩文件时，尽量用较新版本的工具，字符集选择 UTF-8；在 Linux 上压缩时，文件名本身就是 UTF-8，一般不会产生乱码。

zip 加密方面有几种做法。zip -P 密码 这种写法非常不安全，因为密码会出现在 shell 历史里，别人只要看一下 history 就能拿到。安全做法是：

bash复制zip -e secret.zip data.txt

执行后交互式输入密码。但 zip 的加密强度并不高，如果真的涉及敏感信息，我更推荐用 7z 的 AES-256 加密，或者先用 gpg 加密文件再打包。压缩包的加密从来不是压缩命令本身能覆盖的完整需求，把“防止误看”和“安全保密”分开处理。

4.3 zip 分卷与超大包合并

zip 本身支持分卷功能，格式是 -s 指定单卷大小。比如每卷 100MB：

bash复制zip -s 100m -r big_data.zip /data/big_dir

这条命令会生成 big_data.zip、big_data.z01、big_data.z02 等一系列文件。分卷主要是为了绕过文件系统单文件大小限制，比如 U 盘 FAT32。但要注意，拆出来的分卷没法被普通 unzip 直接合并，要先把分卷还原成一个完整 zip：

bash复制zip -s 0 big_data.zip --out full_data.zip

如果你需要分卷压缩并在 Linux 上解压，还有一个更省心的方案：用 tar 打一个不压缩的大包，然后用 split 按大小切割。这样每段文件是普通的文件片段，合并时直接 cat 就行，不需要额外工具，兼容性极高。在后一节里我详细讲这个思路。

5. 生产环境里才用得上的一些老手操作

基础的压缩命令只解决“把文件变小”的问题，生产环境里经常还要处理“怎么传得最快”“怎么边压边备”“怎么看包里的内容但不动整包”这类实际需求。这些玩法不常见，但一旦遇到性能瓶颈会非常有用。

5.1 用管道边压缩边传输，不落中间文件

有一次我需要把 A 服务器上的一个大目录完整搬迁到 B 服务器，磁盘紧张，没地方放临时压缩包。传统解法是先在 A 服务器上压缩，再 scp 过去，再删掉临时文件。更优雅的解法是直接让 tar 输出到管道，通过网络传过去：

bash复制tar -czf - /data/site | ssh user@remote "cat > /backup/site.tar.gz"

这里的关键是 -f -，表示 tar 打包输出到标准输出，而不是某个文件。管道把二进制流直接交给 ssh，到了远程服务器后 cat 把流写成文件。整个过程不产生本地中间文件，对于磁盘空间很小的机器来说是保命技巧。

如果目标机器上也想直接完成解压，可以进一步写成：

bash复制tar -czf - /data/site | ssh user@remote "tar -xzf - -C /data/"

看到没有，远程命令里的 -f - 表示从标准输入读压缩包。这条命令看起来简单，但你在生产环境里能用好它，就能避免很多“传完包再解压再删除”的低效步骤。如果远程服务器支持密钥登录，整个流程可以写进脚本定时执行。用 scp 虽然也能实现，但管道方式更干净，尤其遇到超大的二进制文件时能省一次磁盘写操作。

5.2 多核同时压：pigz、pbzip2、zstd 的并行价值

单核压缩在现在动不动就是 16 核 32 核的服务器上，其实是一种浪费。gzip、bzip2 默认都是单线程，但 Linux 生态给了我们并行版本。pigz 是 gzip 的并行实现，pbzip2 是 bzip2 的并行实现，zstd 本身就支持 -T 多线程。用 tar 时这样封装：

bash复制tar -cf - /data/logs | pigz -p 8 > logs.tar.gz
tar --use-compress-program="pigz -p 8" -cf logs.tar.gz /data/logs

第二条命令里，tar 用指定的压缩程序去替代默认 gzip。如果你的系统只装了 pigz，没装 pbzip2，同样思路换一下程序名就行。我用 32 核机器备份一个大目录时，pigz 多线程带来的提速非常明显，压缩时间能从十几分钟降到两三分钟。前提是磁盘 I/O 跟得上，如果磁盘本身饱和，就算 64 核也没用，该换 SSD 就换 SSD。

5.3 快速查看压缩归档内容，但别全解压

很多时候我只想知道压缩包里有什么，不改动任何文件。对应不同格式有一条速查链：

bash复制tar -tzf files.tar.gz
tar -tjf files.tar.bz2
tar -tJf files.tar.xz
unzip -l files.zip
7z l files.zip

tar -tzf 和 tar -tvzf 的区别是后者能看到权限、大小、属主等详细信息。你不需要把包解开就能决定下一步该怎么处理，这个习惯能省大量时间。

直接查看压缩包里的某个文本文件内容也可以全流式完成，不用解压整个包。假设一个 tar.gz 里面有一个 README.txt，我想只看这个文件的前几行：

bash复制tar -xzf files.tar.gz -O README.txt | head

-O 表示把文件内容输出到标准输出，而不是真正写盘。如果你想追查某个日志但不想解压几百 MB 的包，这种操作方式非常推荐。

5.4 用 split 切割超大压缩包与合并技巧

有些场景里，你做了压缩包以后发现它仍然太大，比如要刻录到光盘、放到 FAT32 的 U 盘，或者传输工具单文件限制 2GB。这时 split 就能上场：

bash复制split -b 2000m site_backup.tar.gz part_

执行后会生成 part_aa、part_ab、part_ac 这样的文件。合并时不要用 cat 反向操作就行：

bash复制cat part_* > site_backup.tar.gz

为什么我不直接用 zip 的 -s 分卷？因为 cat 合并是最原始、最不会出错的方案，不依赖任何压缩程序的还原逻辑。缺点是必须先合并成完整压缩包才能解压，不能只解压某一个分段。但很多传输工具本身支持断点续传，如果只是突破大小限制，这个方案完全够用。

如果你的系统安装了 7z，也可以用 7z 自己分卷：

bash复制7z a -v2000m site_backup.7z /data/site

解压时直接 7z x site_backup.7z.001，7z 会自动找后续分卷，不用手动合并。这个做法更适合 Windows 和 Linux 双平台协作，因为 7-Zip 在很多地方是标配软件。

6. 压缩包损坏、中断时，能救多少算多少

压缩这件事，最怕的不是压缩得慢，而是压缩包生成到一半或者传输过程中损坏。遇到这种问题，第一步千万别慌，更别直接把文件删了。不同格式有不同的恢复策略，能救多少算多少。

6.1 gzip 文件截断时的“半截抢救”

gzip 格式在文件末尾有校验信息，如果压缩包被截断，比如传输中断、磁盘写满，gunzip 可能会报 unexpected end of file。但这不代表里面的数据全都废了。gzip 压缩的原理决定了破坏点是局部的，前面的数据通常还能解出来。

我一般这样操作：

bash复制gzip -dc broken.sql.gz > broken.sql

-d 表示解压，-c 表示输出到标准输出。即便 gzip 在中途报错，它也能把已经解压出来的部分写完。然后你可以检查这个 SQL 文件能导到哪一步，哪些表的数据已经恢复。如果你的存档是 tar.gz，先别直接解压 tar，先把 gzip 层“剥掉”：

bash复制gzip -dc broken.tar.gz > broken.tar

后面再用 tar 工具去处理这个不完整的 tar 包，能取出多少文件是另一回事，至少不会因为一个校验错误就把所有努力付之一炬。

6.2 zip 包有多个文件时，损坏一个不等于全毁

zip 和 gzip 不一样，它把每个文件都独立压缩，并在文件末尾有中央目录。所以 zip 包里如果有几个文件损坏，其他文件往往还能正常解压。unzip 默认可能因为目录结构问题直接罢工，先用修复参数重建索引：

bash复制zip -FF broken.zip --out repaired.zip

这一步会扫描整个 zip 包，尝试修复中央目录。修复后如果仍然有问题，试试用 7z：

bash复制7z x broken.zip

7z 在遇到坏条目时会继续处理后续条目，能把没损坏的文件救出来。如果你心里对“哪个文件坏了”有点数，可以先 unzip -l 尝试列表，再针对性提取某个文件。千万不要因为 unzip broken.zip 报错就以为整个包都没救了，很多时候只是坏了一两个文件而已。

6.3 tar 包不完整时的处理思路

tar 是一种非常朴素的串行归档格式，没有中央索引，读取规则是顺着文件内容一个一个往后找。如果一个 tar 包在中间损坏了，后面的文件确实很难恢复，但前面的文件通常还能解析出来。GNU tar 有一个参数：

bash复制tar -xif broken.tar

-i 表示忽略归档中的零块，可以理解为“遇到坏区域别停，尽量继续往后找文件头”。如果在解压时报错，留意标准输出里已经成功释放了哪些文件，先把它们归档起来。如果文件头本身损坏，tar 可能直接放弃，此时可以尝试用十六进制工具手工查看块边界，但那是另一套工程量很大的取证玩法，日常用不上。

预防永远比抢救重要，所以备份压缩包之后，我习惯立刻做一次完整性验证：

bash复制gzip -t file.tar.gz
bzip2 -t file.tar.bz2
xz -t file.tar.xz
unzip -t file.zip
7z t file.7z

这一条命令的成本很低，但能让你在备份完当场确认文件是不是可用，而不是等到要恢复数据时才傻眼。

7. 最后一章速查表：场景化选型比背参数更重要

很多刚接触 Linux 的人会到处复制“Linux 压缩命令大全”，然后发现记不住，因为缺乏场景。命令是用来解决问题的，不是用来背的。如果你在真实环境里清楚自己要干什么，选型思路就出来了，参数自然也就记住了。

7.1 如果只能记住这些命令，优先记它们

下表是我给自己的团队做交接时最常用的压缩命令清单：

这里没有加入 xz、bzip2 的连接命令，因为它们格式和上面的 gzip 几乎一一对应，只要你会 gzip，换一个参数就行。真正的难点不在命令本身，而在于什么时候选择哪个工具。

7.2 根据业务场景选择压缩命令的几条心法

我最常遇到的几类实际问题，按场景给出我的选型习惯：

• 磁盘空间紧张、备份后长期不访问的冷数据：用 tar -cJf 或 7z a，xz 或 7z 格式，压缩率优先。数据库历史备份、月度归档我经常这么干。
• 需要快速备份、恢复速度也要快的日志和网站目录：用 tar -czf 搭配 gzip 默认级别，必要时用 pigz -p 并行加速。gzip 是 Linux 默认生态里兼容性最好的选择，任何 Linux 机器拿到 .gz 都能解。
• 作为临时交付件发送给 Windows 用户：用 zip，注意路径层级和中文文件名。尽量不要用 tar.gz 发到 Windows 用户那里，他们真的可能不会解。
• 多个相同大文件目录需要增量备份：tar 本身不适合增量，优先考虑 rsync 配合快照，如果一定要打包，用 tar --listed-incremental 做增量归档。
• 在受限的小内存 VPS 上压缩超大数据库文件：先用 mysqldump 导出，再接管道直接 gzip -1，级别低一点，不要用 xz，防止 OOM。具体可以这样：

bash复制mysqldump -u root -p mydb | gzip -1 > mydb.sql.gz

这些心法背后有个共同逻辑：压出来的包不是越大越好，压缩过程造成的系统风险和操作成本经常比那几十 MB 的体积更重要。做运维不是搞艺术，稳定和可恢复才是第一位的。

如果让我只给一个最终建议，我会说：不管用哪种压缩命令，永远先想好“这个包将来在哪里、用什么工具、谁来解压”。压缩只是手段，解压成功才是目的。你手上的命令不是越高级越好，而是越匹配你的下游环境越好。这套思路想清楚以后，再去看任何一篇压缩命令大全，你会发现那些参数自己都能推理出来。