VPN 日志保留期限：绑定事件，而非数字
保留期限取决于事件、内容和策略，而不是统一的截止日。找出每一份副本，停止详细采集，并保留一份简短记录。
其实没人问 VPN 日志该留多久；他们问日志是干什么用的，答案才决定日期。同一个事件可能产生两份寿命不同的文件，把它们当作同一条策略，会同时造成过度保留和证据丢失。原因尚不明确时抓取的调试导出，与监控存储里的一行并不是同一件东西。先问目的，再定日期。
选日期前先回答四个问题
四个问题决定文件是否保留：事件是否仍在进行、文件里有什么、谁需要读它，以及适用策略要求什么。按这个顺序回答，保留日期自然浮现。推理可以放进一张表：
| Question | How it moves the answer |
|---|---|
| Incident state | An open investigation justifies a protected original; a closed one rarely does |
| Content | Connection identifiers, internal names and addresses raise the cost of a leak |
| Audience | Who retrieves it, and whether a redacted excerpt would serve them instead |
| Policy floor | The applicable service or organizational rule, which overrides a shorter reasoning |
事件进行期间，保留一份受保护的原始文件，以便日后比对事件或回答支持问题，并为它书面指定负责人和用途。对响应团队之外的人，一份简短的脱敏摘录通常就够，而且远比分发完整导出容易辩护。原始文件与摘录是受众不同的两种产物，把它们混为一谈，才同时造成过度保留和证据丢失。策略设定的是下限，所以若策略要求的更久，以策略为准。
用记录收尾，而不是用导出收尾
在工单里写一份四行记录：现象、客户端与版本、定位问题的那一条错误行，以及修复方式。不要附加其他内容，因为导出是给你自己的，记录是留给下一个人的。
记录也更可能被读到：完整导出多半只对当初抓取它的人有用，而那个人已经知道发生了什么。把记录放在下一次事件会被检索的地方，通常就是工单，而不是以日期命名的文件夹。如果记录必须可追溯又不能暴露连接标识，可以用案件编号承载引用。若仍有问题未决，原始文件仍按上文的受保护副本规则保留；记录一旦存在，其余都可清除。
删除之前先找齐每一份副本
先看导出文件夹，再看事件时间窗内的日志，再看工单附件，再看备份目录，最后看监控存储。如果同一个连接标识出现在第五个地方，说明清单做错了。日志才是常见的意外来源，因为在你阅读导出时它仍在继续采集。
使用受支持的轮转与删除路径，而不是手工解除文件链接。仍被打开的文件在目录项消失后仍占用存储，删除看似完成却什么都没释放。这是贴着隐私标签的存储缺陷，两个目标一个都没达成。
先停止采集，再验证删除
通过拥有该采集的应用来停止临时详细采集，而不是编辑它的输出文件。被遗忘的调试设置会在旧记录删除后继续写入新记录，悄悄抵消你刚做完的工作。检查实际生效的日志级别，而不是你记得设置过的值。然后确认剩下的内容受保护，且只有预期的人能取回。
原则是数据最小化：只保留既定目的所需的内容，只保留所需的时间，不多留，正如RFC 6973 隐私指南所述。没有目的而保留的文件，是带时间戳的负债。当你能说出文件、目的、负责人和结束日期，这个决定才算完成。