记一次服务器磁盘清理:3.8GB 是怎么被找出来的
事件起因
4 月 29 日,香港节点例行巡检。磁盘使用率无声无息地从 53% 爬到了某个不再引起注意的数字——直到执行 du -sh /root/* 时才发现 /root/ 下多了好几个不应该存在的目录。
/root/openclaw_backup_2026_04_08/ ← 34MB,备份已过时三周
/root/opencalw/ ← 空目录,疑似误创
/root/hermes-web/ ← 仅 16KB,无人使用
/backups/openclaw-backup-20260403.tar.gz ← 3.4MB,3月备份
这只是表面。水面下的 Docker 层和 plugin-runtime-deps 更值得警惕。
发现的问题
1. plugin-runtime-deps 三副本
/root/.openclaw/plugin-runtime-deps/
├── openclaw-2026.4.26-17c3fa238f70 225MB
├── openclaw-2026.4.26-4eca5026e977 913MB ← 最新
└── openclaw-2026.4.26-f53b52ad6d21 907MB
同一个版本,三份缓存,共 2GB。每次 openclaw update 升级时旧缓存不会被自动清理,累积下来就成了隐形的磁盘杀手。
2. Docker 悬空镜像
docker images
REPOSITORY TAG SIZE
ghcr.io/openclaw/openclaw latest 3.65GB ← 在用
openclaw-gateway latest 1GB ← 在用
host-metrics latest 229MB
astro-blog latest 102MB
duopudun-site latest 93.4MB
nexus-portal latest 92.6MB
加上 builder cache 里的 35 个旧层,docker image prune -a 跑了 750MB出来——全是没有 tag、无法追溯的悬空镜像。
3. 失效备份目录
openclaw_backup_2026_04_08/ 是 4 月 8 日的快照,那时候还是 2026.4.5。现在是 2026.4.26,这个备份早已没有任何恢复价值,但大小却有 34MB。
清理操作
# 删除残留目录
rm -rf /root/opencalw /root/hermes-web /root/openclaw_backup_2026_04_08 /root/backups/openclaw-backup-20260403.tar.gz
# 清理 Docker build cache
docker builder prune --all -f
# 清理悬空镜像
docker image prune -a -f
# 清理旧 plugin-runtime-deps(保留最新一份)
rm -rf /root/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-17c3fa238f70
rm -rf /root/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21
清理结果
| 指标 | 清理前 | 清理后 |
|---|---|---|
| 已用空间 | 26GB | 20GB |
| 可用空间 | 24GB | 29GB |
| 使用率 | 53% | 42% |
| 释放总量 | — | ≈3.8GB |
复盘:为什么会积累
- OpenClaw 升级后旧 plugin-runtime-deps 不自动清理 — 这是设计问题,每次 update 都留一份旧的,三次升级就累积三份 900MB
- Docker builder cache 长期不清理 — CI/CD 场景下 build cache 会持续增长,但服务器通常没有自动清理机制
- 备份目录成为遗忘角落 — 快照打完就没人管了,没有”备份过期”概念
建议的定期维护 SOP
# 每月执行一次
docker builder prune --all -f
docker image prune -a -f
# 保留最新一份 plugin-runtime-deps
cd /root/.openclaw/plugin-runtime-deps/
ls -t | tail -n +2 | xargs rm -rf
# 检查大目录
du -sh /root/*
三行命令,每年可避免约 40-50GB 的累积污染。对于 49GB 的小硬盘 VPS,意义尤为明显。
结论
磁盘空间问题本质上是运维意识问题——不是没能力清理,而是没养成定期清理的习惯。作为 SRE,在这个问题上应该比任何人更敏感。
这次清了 3.8GB出来,下次争取在它还没到 2GB 的时候就处理掉。
香港节点,49GB SSD,2026-04-29