给日志包按项目分目录后，我拿哈希对账才发现上传脚本一直在重传全量

先说结论：日志和部署包体积失控，八成不是压缩算法的问题，是归档策略的问题。我这次踩的坑跟压缩软件本身没关系，纯纯是脚本逻辑。

背景
我们后端每天产出大约 4-6G 的日志包，加上每周两三次的部署包，之前全堆在一个目录里，按日期命名。最近发现备份盘吃紧，一查，三个月涨了 8 个 G 的增量，跟业务量根本不成比例。

排查过程

1. 先按日期列出每天的包大小，发现周末的包跟工作日差不多大，这不正常，周末流量只有平时的三成。
2. 挑了两天的日志包，解压后逐文件算 sha256，对比发现大量文件内容完全一致，只是文件名里的时间戳不同。
3. 顺着时间戳去翻上传脚本，问题找到了：脚本判断「要不要重新打包」的依据是目录的 mtime，而目录里有个每分钟写一次的 health.log，导致整目录永远被判成「有更新」，于是每次都全量重打。

修法

• 把归档范围从「整个日志目录」收窄到按项目分子目录，每个子目录单独算 mtime。
• 每个包打完顺手落一个 manifest，记录文件列表和 sha256，下次打包前先 diff，没变的文件直接跳过。
• 部署包单独一个目录，跟日志彻底分开，避免日志的抖动污染部署包的触发条件。

效果
跑了一周，日均产出从 5G 左右降到 1.2G，周末的包从 4G 多降到 800M 上下。解压速度没变，但传输和存储的账先对上了。

一个提醒
如果你也在用「目录 mtime」判断增量，回去看看目录里有没有那种高频写入的小文件，比如健康检查、心跳日志。有的话，这个判断基本等于失效。

想问下各位，你们归档日志是按项目分目录还是按日期分？我现在的做法是项目下面再套日期，层级有点深，想找个更顺手的结构。