工单 · 数据保留与释放空间¶

依据：数据保留与释放空间、日常运维与共用执行规则。

目标：<准确机器、挂载点、目录或数据库；VPS 可使用已核实的 SSH alias>
现象：<磁盘/inode 告警 / 写入报 No space left / 空间对不上 / 数据库文件偏大 / 备份保留到期 / 其他>
用途与可接受影响：<RPO/RTO、审计与合规要求；不确定就先只观察>
现有授权：<默认只读；如已授权具体清理，记录精确路径、动作与保留窗口>

先确认执行的机器与挂载点、文件系统类型、是否只读、是否有 quota；容器内先确认宿主。
先给目标数据分类：原始数据 / 可重建缓存 / 日志 / 备份。
只有“能按确定规则重建、代价可接受”才算可删缓存；名字像 cache 或位于 /tmp 不是证据。

分别看空间与 inode（df -hT、df -i）；用 du 定位增长但不做全盘扫描。
保证 df 与 du 在同一个文件系统范围内对照，并注意权限不足/快照/metadata 的差异。
写失败要保留准确 errno：EROFS 与 EDQUOT 不是 ENOSPC，别混同。
若 df 与 du 对不上，检查“已删除但仍被打开”的文件（lsof -a -p <pid> +L1 / /proc/<pid>/fd），
last hardlink 移除且最后打开引用关闭后才释放；权限缺口记 unknown，不用 head 假装扫描受限。
正确做法是让进程重开日志或按服务方式轮转，而不是直接删除正在使用的文件。

SQLite：DELETE 后页空间通常留待复用、文件未必缩小（auto_vacuum 影响物理缩减）；
VACUUM 才可能回收，就地 VACUUM 可能需要约 2 倍原库的额外空闲空间并持写锁，非 INTEGER PRIMARY KEY 时 ROWID 可能变；
WAL 模式下空间可能在 -wal，checkpoint 是写+锁动作且通常复用 WAL 不缩文件，不随手删 -wal/-shm。
想备份用在线 backup API 或 VACUUM INTO（一致副本）；VACUUM INTO 写新文件、失败不算备份；不 cp 正在写入的库文件。
只读查询用 sqlite3 -readonly，避免目标不存在时建空库。动 VACUUM 前先确认有一份一致且验证过可恢复的备份。

日志/journal/备份都按各自 owner 的保留策略处理：journald 预算、logrotate 规则、备份保留。
轮转不等于备份（copytruncate 有拷贝后截断间隙会丢记录）；没有恢复验证的唯一备份不能当作已受保护。

禁止：无差别 rm/truncate、仅因名字像 cache 就删除、删除正在使用的数据库/日志、
在无一致备份时就地 VACUUM 大库、把容器/镜像内部目录当通用清理对象。
但按已批准的保留策略，允许淘汰明确不可恢复的过期数据（owner 接受损失、所需数据已另有保留）。

交付：
1. 现状证据：目标挂载点的空间与 inode、增长来源与数据分类。
2. 若建议释放：释放哪一类、依据、owner、空间收益与代价、回退路径。
3. 涉及数据库：一次业务层恢复验收；integrity_check 只查结构、不替代业务恢复，重型扫描考虑负载。
4. 在已有授权内完成已授权的释放；未授权的删除先给具体候选与停止条件。
5. 分开报告“文件已删”与“空间确实回收”“数据仍可恢复”。

回报：实际在哪执行；释放了哪一类数据、依据与 owner；前后 df/inode 对比；
      哪些经真实回收验证、哪些只是静态判断；未验证什么；如何接手。
真实机器、账号、路径与数据留在 owner 私有位置，不提交公开仓库。