记录牧安平台从 0 到 1 的开发过程，一个待业在家的网安老兵边做边想。

第3期聊技术选型，我说探针落库挑了 SQLite——零依赖、本地文件、断网也能跑，听着挺美。第5期数据能自己进来了，落库、查库都顺。

昨天晚上，这台探针自己把我部署它的云主机根分区塞满了，服务死活起不来。

一个干安全检测的探针，自己先把宿主机的磁盘干爆了。说出来有点丢人，但排查过程值得每一个写采集 / agent / 探针的人看一遍——这坑不挑人。

我把自研的轻量探针（代号 Shepherd L3，跑在云主机上的采集器，数据落本地 SQLite）丢到一台云主机上做长期运行验证，想看看能不能稳住。

头几天一切正常。直到某天重启，它死活起不来，日志里只有一行：

FileNotFoundError: [Errno 2] No usable temporary directory

"没有可用的临时目录"。这报错一看就是磁盘满了——Python 解释器自己启动时连写个临时文件的地方都没有。

Filesystem Size Used Avail Use% Mounted on/dev/vda1 40G 40G 0 100% /

根分区 100%。可这是个探针，数据量不大，SQLite 主库撑死几百 MB，怎么可能吃满 40G？

一层层往下找，最后锁定在探针的工作目录：

主库 `safety-net.db` 才 300 多 MB，结果它的**备份快照的 WAL 文件** `safety-net.db.bak-wal` 一路涨到了 26G。

三、原理复盘：SQLite WAL + 在线备份 = 时间炸弹

要搞懂它为什么涨，得先说清楚 SQLite 的 WAL 模式。

默认 SQLite 用 rollback journal（DELETE 模式）：改数据先写日志，提交后把改动写回主库文件，再删日志。

WAL（Write-Ahead Log）模式反过来：写操作先追加到一个独立的 `-wal` 文件里，主库文件暂时不动；读的时候合并 `-wal` 的内容。只有当触发 checkpoint（检查点）时，`-wal` 里的数据才会被写回主库，然后 `-wal` 被截断复用。

WAL 的好处是读写不互相阻塞，并发高。代价是：**只要 checkpoint 不发生，`-wal` 就会一直长大。**

探针有个定时快照：`snapshot_backup()` 用 SQLite 的在线备份 API 把主库 `safety-net.db` 复制到 `safety-net.db.bak`，用来做故障回滚。

问题出在：主库是 WAL 模式，而原来的备份函数**没有强制目标库用 DELETE 模式，也没有在备份后清理 `-wal` / `-shm`**。

于是每次快照，目标 `safety-net.db.bak` 在 WAL 模式下被反复写入，它的 `-wal`（也就是 `safety-net.db.bak-wal`）一路追加却从不被截断。探针每天采集几千条告警，快照频繁触发，这个 `-wal` 就像

，一路涨到 26G，直到把根分区塞满。

WAL 模式的库，只要连接不干净关闭、或没做 checkpoint，它的 `-wal` 就会无限增长。而"备份"这个动作，如果目标库也是 WAL 模式，等于在复制的同时又制造了一个新的增长源。

 四、修复：强制 DELETE 模式 + 清理残留

pythondef snapshot_backup():if not os.path.exists(DB_PATH):return Falsetry:_ensure_backup_dir()

先把主库 WAL 完整性落盘，保证快照一致性

try:sc = sqlite3.connect(DB_PATH)sc.execute("PRAGMA wal_checkpoint(TRUNCATE)")sc.close()except Exception:passsrc = sqlite3.connect(DB_PATH)dst = sqlite3.connect(SNAPSHOT_PATH)

关键：强制目标库用 DELETE 模式——顺带 checkpoint 并清掉旧 .bak-wal

dst.execute("PRAGMA journal_mode=DELETE")src.backup(dst)dst.close()src.close()

兜底清理：绝不留 .bak-wal / .bak-shm

for suf in ("-wal", "-shm"):fp = SNAPSHOT_PATH + sufif os.path.exists(fp):try:os.remove(fp)except OSError:passreturn Trueexcept Exception as e:print(f"[safety-net][backup] 快照失败: {e}")return False

1. **备份前**对目标库 `PRAGMA journal_mode=DELETE`——让快照落成一个干净的单文件，而不是 WAL 模式库。

2. **备份后**显式删掉 `-wal` / `-shm`——双保险，杜绝残留。

归档备份 `archive_backup()` 同理处理。

排查时还发现两个会加重事故的坑，一起修了：

原本启动脚本每次启动都跑一遍 `pip install`。磁盘满了的时候，`pip` 自己要写临时目录也会失败——于是"磁盘满 → pip 失败 → 服务起不来 → 想重启清空间却因为起不来没法操作"的死锁。改成：只在依赖缺失时才装。

原来的重启依赖 `fuser` 杀旧进程，`fuser` 没装就杀不干净，新旧进程抢端口。改成先 `pkill -9 -f Shepherd_l3_app.py`，按端口取到 PID 再 `kill -9`，最后清掉 `__pycache__`（避免旧字节码被优先加载），再启动。

六、给运维 / 安全同学的 checklist

这次事故纯属"自己人坑自己"，但暴露的问题很典型：

一个 `.bak-wal` 文件，26G，把整台云主机的根分区干满，让服务起不来——根因不过是"备份时忘了管 WAL 模式"。

SQLite 很好用，WAL 模式更适合高并发采集。但每一份方便都有代价：WAL 的代价就是"你得负责让它 checkpoint"。工具自己不会替你收尾。

第3期我吹过"零依赖、本地部署、断网自愈"，听着省心。这期算是把那张漂亮选型的另一面亮出来——**地基稳不稳，不看它顺风时多轻巧，看它长跑时会不会自己把自己绊倒。** 一个连自己磁盘都看不住的探针，真塞到项目现场，出事的可就不只是云盘了。

下期玩个花活儿，把探针装在飞牛里，聊聊这个怎么实现。

本系列记录牧安平台从 0 到 1 的开发过程，一个待业在家的网安老兵边做边想。

AI开发牧安 ·第9期 探针跑着跑着，把磁盘吃满了

数据库

运维

后端

SQLite WAL模式备份陷阱：探针因未清理.bak-wal文件导致26G磁盘占满，服务崩溃。修复方案：备份时强制PRAGMA journal_mode=DELETE，清理残留-wal/-shm文件，并优化启动脚本避免pip死锁。监控需关注异常文件增长，定期checkpoint，确保自监控覆盖。

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

AI开发牧安 ·第9期探针跑着跑着，把磁盘吃满了

AI开发牧安 ·第9期探针跑着跑着，把磁盘吃满了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI开发牧安 ·第9期 探针跑着跑着，把磁盘吃满了

AI开发牧安 ·第9期 探针跑着跑着，把磁盘吃满了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI开发牧安 ·第9期探针跑着跑着，把磁盘吃满了

AI开发牧安 ·第9期探针跑着跑着，把磁盘吃满了