日志的迁移与归档

老机器退租前，最后一件容易被忘掉的事是历史日志。排历史故障、对业务数据、应对合规检查都靠它，删机器之前值得花半天打包归档。 一、历史日志先打包 日志通常分散在 /var/log、应用目录下的 logs、Web 服务的访问日志路径等位置。归档前先用 du 摸清体量： ``` du -sh /var/log /home/app/logs ``` 体量小的直接 tar 打包：`tar -czf logs-2026.tar.gz /var/log/nginx /home/app/logs`。打包前确认没有进程还在写日志，否则归档文件里会出现写到一半的残行，排查时容易误判。体量大的按月份拆开，压缩后传到对象存储或新机器的归档盘。传输走 rsync over ssh，传完用 md5sum 对比源和目标的哈希值，一致后再清理源文件。 二、检索的连续性 迁到新平台后，日志路径尽量沿用旧结构，历史脚本和排查习惯都不用改。如果顺势改用集中式日志，注意关键字段的连续性：时间戳格式、日志级别、服务名字段保持同一套，否则新旧日志放一起没法按时间线排查。过渡期建议新旧两套并行一两周，验证检索规则对两边都有效，再停掉旧的。 三、留存期怎么定 留存期没有统一标准，按业务性质定：一般 Web 访问日志留三到六个月，涉及交易、签约的日志按行业要求留更久。技术上分层处理：近期日志放本地盘，中期的压缩后放对象存储，过期的由定时脚本清理。存放日志的存储桶单独设访问权限，只给需要查日志的账号读权限，避免历史日志变成公开下载源。清理脚本上线前先拿测试目录演练一遍，确认只删该删的。 四、归档位置写进文档 归档完成后，在运维文档里写清楚：哪些日志放在哪个存储桶、压缩包的命名规则、怎么解包查询。两年后翻旧账的人未必是你，找不到等于没归档。 日志迁移完整走三步：打包校验、保持检索连续、按留存期归层。老机器退掉之前把这三步走完，历史数据才算真正带走了。