#日志归档
该话题下聚合了社区中所有标记为「日志归档」的公开帖子。
7z命令行批量压日志，我拿三种参数跑了一周才敢定下配置
2026/11/9先说结论：Win解压缩解压快是真快，但要论命令行批量操作，还是得7-Zip。我上周把日志归档的流程整个重做了一遍，踩了点坑，记录一下。 背景：我们服务每天产生大概40G日志，之前是直接tar.gz扔归档盘。运维上周说归档盘快满了，让我看看能不能压得更小。我第一反应是换压缩算法，试了zstd和7z的L
日志包解压后权限全变777，我拿四台机子对了一遍md5才发现坑
2026/11/6背景 上周运维给我甩了个 12G 的日志归档包，说是线上事故复盘要用。我随手拿 Win解压缩 双击解压，速度确实快，3 分钟不到就出来了，当时还觉得挺香。结果一进目录傻眼：所有 .log 文件的权限全变成 777，原本的 640 全丢了。 问题复现 我这人习惯先质疑再对账，直接拿四台机子（Win10
日志压缩包按日期乱成一锅粥，我写了个脚本按月份归档
2026/11/1后端干久了，日志压缩包比代码还多。我们服务每天往一个目录里扔 app-2024-05-13.log.gz 这种文件，三年攒了快两千个。每次要查历史问题，ls 出来一屏全是日期，按文件名排序是乱的，因为有的月份补零有的没补。 上周排查一个跨月问题，我翻目录翻了五分钟，忍不了了。 问题在哪 文件名格式不
给日志包按项目分目录后，我拿哈希对账才发现上传脚本一直在重传全量
2026/10/28先说结论：日志和部署包体积失控，八成不是压缩算法的问题，是归档策略的问题。我这次踩的坑跟压缩软件本身没关系，纯纯是脚本逻辑。 背景 我们后端每天产出大约 4-6G 的日志包，加上每周两三次的部署包，之前全堆在一个目录里，按日期命名。最近发现备份盘吃紧，一查，三个月涨了 8 个 G 的增量，跟业务量根
批处理按日期切分日志，我加了行数预检才敢自动删旧包
2026/10/22先别急着吹自动化，切分脚本翻过车 之前写了个批处理，每天凌晨把 logs/ 下超过 7 天的 .tar.gz 按日期切分归档，顺手删掉源包。逻辑看着没问题，结果有一次一个日志包被下游程序写坏了，tar -tzf 直接报错，for /f 把错误信息当文件名，差点把当天正在写的日志目录给删了。 从那以后
日志包按日期切分后，我拿批处理脚本把每月整理时间压到十分钟
2026/10/21先说结论：日志包这东西，别指望一款工具全包，我现在是「入库用 Win解压缩、跑脚本用 7-Zip 命令行」，分工明确，谁也不耽误谁。 场景 我们后端服务每天凌晨滚一个日志归档，一个月下来二十几个包，单个 200M 到 1.5G 不等，里面还有嵌套的旧包。以前我是手动一个个解，解完再按日期挪文件夹，遇
压测了四款解压工具的命令行批量解压，Win解压缩快但脚本里真心不好用
2026/10/20上周要处理一批线上日志包，一共 1200 多个 zip，每个 15MB，得统一解压到按日期分的目录里。顺手把几款常用工具的命令行模式都拉出来跑了一遍，数据如下，给有批量需求的兄弟参考。 测试环境 Win10 22H2，i5-10400，16G 内存，SATA SSD 样本：1200 个日志 zip，