结论先行：六个字：留得下、查得动。六个月是合规上的下限，不是工程上的目标。真正要定的是四件事——容量怎么估、冷热怎么分层、删除由谁批准、离场时怎么交。这四件事不定，日志平台会变成一台只能进不能出的存储设备。

本文只谈留存这件事的工程与口径，不谈日志该怎么分析。

六个月意味着多大的量

一个中等规模的数据中心，服务器、网络设备、安全设备、数据库、堡垒机、云平台加起来往往有数十类日志源，日增数据量按 TB 级算并不罕见。六个月就是把这些量乘以一百八十天，再加上副本与索引的开销。

估算时容易漏三块：安全设备与流量类日志的体量通常被低估；索引本身占用可观空间；副本策略会让实际占用翻倍。可行的做法是先选十到二十个代表性日志源实测一周，再按类型外推，而不是凭经验给一个总数。

全量热存是最贵的做法

六个月之内都要求可查，但并不要求都在最快的存储上。冷热分级是通行做法：近一到三个月放高性能介质，保证检索秒级返回；更早的数据转到低成本介质，接受查询慢一些。分层的判据不是「重要不重要」，而是「多久会被查一次」——取证与审计的查询绝大多数集中在前几周。

谁能删，比留多久更重要

留存策略写好了，执行层面还要回答一个问题：到期之后谁来删。如果没有人负责，数据只会一直堆着，成本逐年上涨；如果谁都能删，审计链条就断了。

稳妥的写法是把删除做成一个需要审批的定期动作：到期数据先进入待删除清单，由安全与运维双方确认无未结的审计或取证事项，再执行，执行记录留档。反过来，任何针对单条日志的删除都应当留痕并可追溯。

离场时，日志算谁的

这件事常在合同期结束才被想起。日志里有客户业务的痕迹，属于客户资产。服务期结束时，需要明确三件事：全量数据怎么移交（介质、格式、时间范围）、平台侧的副本怎么销毁、移交之后服务方是否还保留检索权限。

把这三条写进合同附件，比事后解释有效得多。

四个可以照着核的问题

  • 日增数据量的实测值是多少，按哪几类日志源测的。
  • 分层策略怎么定的，超过三个月的日志查询平均要多久。
  • 到期删除由谁审批，最近一次删除的记录能不能调出来。
  • 合同结束时数据怎么移交，副本怎么销毁。

边界与前提

三点说明。其一，留存期限的具体要求以适用的等保等级、行业监管规定与合同约定为准，六个月是常见下限而非统一标准。其二，文中涉及的容量与性能数字为参考性量级，不同日志源结构差异很大，须以实测为准。其三，冷热分层会牺牲部分查询体验，这一取舍应在方案阶段与业务方共同确认，而不是由运维单方面决定。

深圳市奇摩计算机有限公司在日志平台落地时，习惯先把日志源清单与日增量测准，再定分层与留存策略，最后把删除审批与离场移交写进交付文档。预约咨询，可以按你现在的日志源清单，一起把六个字算清楚。