Linux 日志归档脚本怎么写：按天压缩、校验清单和过期清理

业务系统跑起来之后日志量每天都在增长，最基础的处理方式就是定期打包归档。但只写一句 tar -czf 完全不够：压缩过程一旦中断，很可能留下损坏的半份包；就算打包成功了没有配套校验记录，后续要恢复的时候根本没法确认文件是不是完好；要是清理规则写得太粗糙，搞不好连最近一份可用的归档都给误删掉。

下面这套 Bash 常用脚本把整个归档流程拆成了清晰的状态节点：固定读取来源日志、先写入临时压缩包、生成对应的 SHA-256 校验清单、校验完全通过之后再替换成正式归档文件。过期清理逻辑只针对已经生成完成的正式归档包，原始日志要不要截断完全交给应用自身的日志轮转机制处理，两个职责完全分开，不容易出乱子。

先把来源、归档和保留期配置项分开定义

脚本开头只需要配置三个基础参数：来源日志路径、归档文件存放路径、日志保留天数。来源路径最好按服务名固定写死，不要把外部传入的字符串直接拼接成文件路径；归档路径也要单独专用，避免清理动作误碰到其他备份、上传文件夹或者别的服务文件。

最小归档脚本实现：先压缩，再生成校验清单

把下面的内容保存为 archive-order-log.sh 即可。脚本采用 Bash 严格模式，遇到未定义变量或者管道命令失败的时候会直接停止执行；临时包始终存放在归档路径内部，最终的文件替换操作只发生在同一个文件系统中，不会出现跨盘移动的异常问题。

#!/usr/bin/env bash
set -euo pipefail

SOURCE="/var/log/order-api/app.log"
ARCHIVE_HOME="/var/backups/order-api"
KEEP_DAYS=14
DAY=$(date +%F)
BASE="order-api-${DAY}.tar.gz"
PART="${ARCHIVE_HOME}/${BASE}.part"
FINAL="${ARCHIVE_HOME}/${BASE}"
CHECK="${FINAL}.sha256"

mkdir -p "$ARCHIVE_HOME"
test -s "$SOURCE"

tar -C "$(dirname "$SOURCE")" -czf "$PART" "$(basename "$SOURCE")"
sha256sum "$PART" > "${PART}.sha256"

(cd "$ARCHIVE_HOME" && sha256sum -c "${BASE}.part.sha256")
mv "$PART" "$FINAL"
mv "${PART}.sha256" "$CHECK"

find "$ARCHIVE_HOME" -maxdepth 1 -type f \
  -name 'order-api-????-??-??.tar.gz' -mtime +"$KEEP_DAYS" -delete
find "$ARCHIVE_HOME" -maxdepth 1 -type f \
  -name 'order-api-????-??-??.tar.gz.sha256' -mtime +"$KEEP_DAYS" -delete

这里有个很容易被忽略的细节：校验命令读取的是临时包生成的清单，只有校验返回成功状态，才会把临时包移动成正式归档文件。如果压缩时磁盘空间不足、来源日志突然不可读，不会生成任何正式包和校验清单；原始日志文件也完全不受影响，处理完磁盘或者权限问题之后就可以直接重新运行归档操作。

先用小体积测试日志验证脚本运行结果

第一次跑脚本不要直接接入生产日志。先复制一份几十行的测试小文件到测试路径，运行完脚本之后应该能看到一份正式压缩包和一份同名的校验清单。之后可以把压缩包复制到另一台机器或者临时文件夹下，用校验清单做完整性检查，确认归档不是看起来正常，而是真的可以被正常验证。

bash archive-order-log.sh
ls -lh /var/backups/order-api
cd /var/backups/order-api
sha256sum -c order-api-2026-07-18.tar.gz.sha256
tar -tzf order-api-2026-07-18.tar.gz | head

正常情况下校验命令会返回 OK，解压之后的文件列表里能看到原始日志的文件名。如果手动修改压缩包里的任意一个字节再做校验，结果会直接报异常。这一步操作不能省略，它能确认你手里存的不是一份徒有备份外观的无效文件。

过期清理逻辑只处理已完成的正式归档

脚本里的清理条件用了固定文件名前缀、日期格式、文件后缀再搭配 -mtime 参数。完全不会碰扩展名为 .part 的临时文件，因为这类临时包说明某次归档流程可能还没执行完。对于遗留时间很长的临时包，更稳妥的处理方式是单独列出来排查生成原因，不要和正常归档文件一起批量删除。

如果归档之后还要把文件上传到对象存储，要把上传逻辑放在正式归档包生成之后，上传成功之后再单独记录远端存储的文件键值。不要因为上传失败就删掉本地的归档文件，本地设置的保留期本身就是最后一道恢复缓冲。等远端存储的可用性和恢复流程全部验证通过之后，再考虑缩短本地的日志保留时长。

上线前的检查清单

1. 来源文件为空或者不可读的时候，确认脚本直接停止，不会生成任何新的正式归档。
2. 手动把归档路径设置为不可写状态，确认临时包写入失败之后，不会覆盖前一天已经生成的正常归档。
3. 手动修改一份归档包的内容，再运行 sha256sum -c 做校验，确认校验逻辑能正常报出异常。
4. 提前准备一份超过保留期的正式包和一份同名的临时包，确认常规清理逻辑只会删除过期的正式包。

日志归档本身的逻辑代码量很小，但它是整个故障恢复链路里的重要环节。把临时状态处理、校验记录生成和清理边界的规则写明确之后，后续再接对象存储上传、监控告警或者集中日志检索系统，都不会推翻这套基础的运行逻辑。

相关问题

为什么不直接压缩之后就删除原始日志？

归档脚本没办法判断业务应用是不是还持有原始日志的文件句柄。原始日志的轮转、重开文件句柄和截断操作，应该交给应用本身或者专用的日志轮转工具处理，归档脚本只负责读取并保存日志的副本。

校验清单要和压缩包放在一起存储吗？

放在一起的话后续传输完验证完整性会更方便，也可以把清单同步到独立的存储位置，避免同一存储介质损坏导致两者同时丢失。核心要求是恢复流程里能同时拿到归档包和对应的校验清单，能明确两者的对应关系。

临时包长期遗留下来要怎么处理？

先查看文件的创建时间、磁盘剩余空间和脚本运行日志，确认对应的归档任务没有还在后台运行。确认是之前归档失败残留的旧文件之后，再人工或者通过单独的清理规则回收，不要用普通的保留期过期逻辑直接自动处理。

日志保留多少天比较合适？

具体时长取决于磁盘容量、远端副本配置、故障恢复目标和对应的合规要求。可以先用偏保守的保留天数先上线运行，结合每日日志增长量和实际恢复演练的记录再逐步调整。