直接压缩日志再传输可提升效率，推荐用tar -czf打包压缩整个目录或指定日志，压缩级别选-6平衡速度与体积，支持管道边压边传，并可用zcat/zgrep等命令不解压快速查看内容。
直接压缩日志再传，体积小了，自然就快了。关键是选对方式、压得合理、不卡流程。
先打包再压缩，别单个硬压
gzip 本身不处理目录结构，单独压缩每个日志文件会丢失路径，还难管理。正确做法是用 tar 打包 + gzip 压缩一步到位：
- 打包压缩整个日志目录：`tar -czf logs.tar.gz /var/log/nginx/`（-c 创建归档，-z 调用 gzip，-f 指定文件名）
- 只压指定类型日志：`find /var/log -name "*.log" -mtime -7 | tar -czf recent_logs.tar.gz -T -`（找近7天的 .log，打包压缩）
- 这样既保留目录层级，又生成单一 .tar.gz 文件，方便 scp 或 rsync 传输
压缩级别要务实，别盲目求“最压”
日志多是文本，gzip 对它效果好，但级别越高越耗 CPU 和时间。实测 100MB 日志：
- -1（最快）：压缩后约 28MB，耗时 1.2 秒 —— 适合实时推送或定时任务里赶时间
- -6（默认）：压缩后约 22MB，耗时 3.5 秒 —— 平衡点，推荐日常备份和跨机传输
- -9（最压）：压缩后约 21MB，耗时 8.7 秒 —— 多花 5 秒只省 1MB，一般没必要
传输瓶颈常在带宽，不是体积；CPU 占满反而可能拖慢其他服务。用 tar -czf -6 就够稳。
边压边传，省中间存储
不想先写死硬盘再传？用管道直连，内存中完成压缩+传输：
- 本地→远程（ssh）：`tar -cf - /var/log/app/ | gzip -6 | ssh user@host "cat > app_logs.tar.gz"`
- 配合 rsync（更可靠）：`tar -cf - /var/log/error/ | gzip -6 | ssh user@host "gunzip | tar -xf - -C /backup/"`（解压直落目标目录）
- 避免生成临时 .gz 文件，减少 I/O，也省空间
传完能快速查内容，不用先解压
接收方拿到 .tar.gz 后，常需确认是否传全、有没有关键错误——不用解包就能看：
- 看前几行：`zcat logs.tar.gz | head -20`（注意：这是看压缩包里第一个文件；若想看特定日志，得先 tar -tzf 列表，再用 zcat 配合 tar -O）
- 搜关键词：`zgrep "500\|timeout" logs.tar.gz`（自动解压并 grep，支持正则）
- 统计行数：`zcat logs.tar.gz | wc -l`（适用于单文件压缩包；多文件需 tar -O 提取后再算）
这些操作都秒级响应，省去解压再查的等待。
