录像、事件图和日志共用磁盘时，保留天数不是一个静态数字，实际码率与事件量会改变需求。
容量预算应包含稳定流量、峰值事件、索引与操作余量。按年龄清理还要考虑上传确认和业务保留，文件删除与索引状态需要协调。
一、问题的范围与前提
技术交付包含环境、接口、数据、权限和验证范围。某个模块演示成功，不代表整套系统已验收。应将已有结果、工程目标和待验证条件分别记录，让读者知道结论能够应用到哪里。
二、技术分析与方案取舍
视频预算可以从实际码率乘时长得到基础量，再加事件图、索引、日志和操作余量。事件率高峰与存储水位会影响可保留时间。清理应按证据等级、上传确认和业务周期决定，不将所有文件一律按最老删除。文件与数据库索引同时核验，磁盘不足时给出明确状态，而不是继续宣称录像完整。
从业务动作和现场约束建立任务边界，再确定各模块输入输出与责任。文档保存可重现的配置方法和异常路径，实际凭据独立管理。公开案例只分享已有资料能支持的过程，客户身份、内部数据、商业金额与未公开实现细节继续脱敏。
三、实现与排查的顺序
- 按实际码率和事件频率预算。
- 区分证据与可重建缓存。
- 设置磁盘水位。
- 清理后校验索引文件关系。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
4
df -h
df -i
journalctl --disk-usage
docker system df
空间、inode、journal 和 Docker 各有统计口径。根分区满既可能是大文件，也可能是海量小文件耗尽 inode。这里仅查询，不自动清理；先确定增长来源与业务保留条件，再选择对应轮转或清理策略。
四、验证和结果解释
每项结论有对应的样本、日志或验收条件，不以篇幅和图表数量替代证据。系统整体收益与单模块效果使用不同口径，重复建设内容不能多次归因。版本记录关联源码、配置和数据迁移，便于后续排查和恢复。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 高峰容量仍有余量 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 未确认关键证据不被提前删除 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 磁盘不足能降级并记录 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
验证需要由维护者在独立条件下复现，包括断网、重启、异常输入和回退。交付文件存在不代表部署完成，部署完成也不代表全部业务可用。限制应写成具体条件和检查方法，让下一次实施能够据此调整。
五、适用边界与结论
平均码率不代表最坏条件，不能只按分辨率估算所有视频。重要数据还需备份而非延长本机保留。
这条路径把“按实际码率和事件频率预算”与“清理后校验索引文件关系”连在一起，中间保留可复查的条件。实施时优先确认“高峰容量仍有余量”，再检查“磁盘不足能降级并记录”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
