crontab中压缩参数失效主因是环境缺失和alias干扰，应使用绝对路径、禁用alias或换zstd；压缩等级需按文件类型匹配；时间戳、锁、权限、PATH四要素须显式处理。
crontab 里调用 gzip/bzip2/zstd 压缩时，-9 不一定生效
计划任务执行环境默认没有加载用户 shell 配置（如 ~/.bashrc），gzip 可能是 alias 到 gzip -6 或被 wrapper 脚本拦截，直接写 gzip -9 在 crontab 里常被忽略。
- 用
which gzip查真实路径，crontab 中写绝对路径，比如/bin/gzip -9 - 避免 alias：在 crontab 命令前加
/bin/bash -c，或显式禁用 alias：\gzip -9 - zstd 比 gzip/bzip2 更可靠——它没常见 alias 干扰，且
-T0（自动多线程）在备份大文件时提速明显
备份脚本中压缩等级要和文件类型匹配
盲目统一用 -9 反而拖慢整体流程：文本日志压得再狠也省不了多少空间，但 CPU 占满会影响其他任务；而数据库 dump 的 SQL 文件，用 zstd -19 确实能多省 15% 体积。
- 日志类（
.log,.out）：gzip -3或zstd -3，平衡速度与压缩率 - SQL / XML / CSV：可上
zstd -19，但注意内存占用（-M1G限制最大内存） - 已压缩内容（
.jpg,.mp4,.zip）：别再套一层压缩，gzip -0或直接cp，否则徒增 I/O 和时间
crontab 时间表达式和文件名时间戳不一致导致覆盖或遗漏
用 date +\%Y\%m\%d 生成文件名，但 crontab 设的是 0 2 * * *（每天 2 点），若某次执行延迟到 2:05，而下一次又准时 2:00 开始，两个任务可能写入同一天的文件名，造成覆盖。
- 在脚本开头用
START_TIME=$(date -u +\%Y\%m\%d_\%H\%M\%S)固定时间戳，不依赖 cron 触发时刻 - 加锁：用
flock -n /tmp/backup.lock -c 'your_backup_cmd'防重入 - 检查上一个备份是否成功：校验
ls -t backup_*.tar.zst | head -1的 mtime 是否在 24h 内，而非只看文件名日期
systemd timer 替代 crontab 更适合带依赖的压缩备份
当备份需等数据库导出完成、或压缩前要先 rsync 同步、或失败后需重试，crontab 很难处理依赖和状态追踪，systemd timer 天然支持 After=、StartLimitIntervalSec 和日志聚合。
- 写一个
backup.service，ExecStart调用含压缩逻辑的脚本，明确设Type=oneshot - 配
backup.timer，用OnCalendar=02:00+Persistent=true（断电后补触发） - 查状态统一用
systemctl status backup.service，日志直接journalctl -u backup.service -n 50，不用翻/var/log/syslog
真正麻烦的不是选哪个压缩参数，而是时间戳、锁、路径权限、环境变量这四样在无人值守时全会悄悄出错。尤其 PATH 在 systemd service 里默认极短，/usr/bin/zstd 得写全，不然就静默失败。
