当 Linux 服务器磁盘占用飙升至 94%，线上服务随时面临崩溃风险。本文复盘了云养 OpenClaw 时的真实“磁盘救援”实录，带你快速定位“空间杀手”，安全释放超 10GB 的宝贵空间。

📁 环境背景

• 运行服务：OpenClaw 生产环境
• 操作系统：Ubuntu 24.04 LTS
• 硬件配置：40GB 系统盘
• 当前危机：磁盘可用空间仅剩不到 3GB。

---

🚨 第一步：系统状态诊断

在开始任何“删库跑路”式的清理前，摸清底细是第一步。我们需要确认系统版本和具体的磁盘占用情况。

1. 确认系统环境
不同发行版的包管理器和日志路径有所不同。通过查看版本，确认我们使用的是现代的 Ubuntu 链：

cat /etc/os-release
# 输出确认：Ubuntu 24.04.4 LTS (Noble Numbat)

2. 探测磁盘水位
使用 df 命令查看是哪个分区在拉响警报：

df -h

执行结果节选：

/dev/vda2 40G 36G 2.4G 94% /

🔴 紧急警报： 根分区 /dev/vda2 已使用 94%，仅剩 2.4GB 可用空间！此时如果不做干预，系统随时可能因为磁盘写满而宕机。

---

🔍 第二步：抽丝剥茧，定位“空间杀手”

找到了拥堵的分区，接下来要揪出是谁吃掉了空间。这里强烈推荐一款可视化磁盘分析神器：ncdu。

1. 扫描根目录

# 安装 ncdu
sudo apt install ncdu -y
# 扫描根目录（排除虚拟文件系统以提升速度）
sudo ncdu / --exclude /proc --exclude /sys --exclude /run

扫描结果让人大跌眼镜：

13.3 GiB [#############################] /root

问题发现： /root 目录竟然占用了高达 13.3GB 的空间！作为超级用户的家目录，通常只会存放少量配置文件，这显然是不正常的。

2. 深入 /root 目录查底细
我们进入该目录，用 du 命令按大小排序，看看里面到底藏了什么：

sudo -i
cd /root
du -sh .[^.]* * 2>/dev/null | sort -rh | head -20

排名前三的目录浮出水面：

1. .npm：5.2GB (Node.js 包缓存)
2. .cache：4.4GB (系统/应用通用缓存)
3. .openclaw：1.9GB (OpenClaw 核心业务数据)

真相大白： 原来有近 10GB 的空间被 Node.js 和各类应用的缓存白白侵占了。

---

🧹 第三步：外科手术级的安全清理

定位了目标，接下来就是安全删除。清理的原则是：精准清理无用缓存，绝不动核心业务数据。

1. 清除 Node.js 缓存（释放 5.1GB）

.npm 目录是包管理器的历史缓存，删除它绝对安全，不会影响任何已安装服务的运行。

# 推荐做法：使用 npm 官方清理命令
npm cache clean --force

# 强力做法：如果缓存过于顽固，直接物理超度
rm -rf ~/.npm/*

验证：空间从 5.2GB 瞬间降至 28MB。

2. 清除系统临时缓存（释放 4.4GB）

.cache 存放着各类程序的临时文件，同样可以放心清理。

# 一键清理缓存目录
rm -rf ~/.cache/*

验证：空间从 4.4GB 降至 12KB。

注： 排名第三的 .openclaw (1.9GB) 属于不可或缺的核心数据，且经排查并未产生冗余大文件，我们必须完整保留。

---

💾 第四步：深度压榨，辅助空间释放

除了解决主要矛盾，我们还可以给系统做个常规的大扫除。以下三个操作能额外挤出不少空间：

1. 清理 APT 包管理器垃圾
Ubuntu 每次更新都会留下安装包缓存，定期清理是个好习惯：

sudo apt clean           # 清理已下载的 .deb 缓存
sudo apt autoremove      # 卸载孤立的无用依赖包

2. 瘦身 systemd 日志 (Journald)
系统运行久了，底层日志会变得无比庞大。我们将日志上限锁定在 200MB，并清理旧归档：

# 保留最近 200MB 核心系统日志
sudo journalctl --vacuum-size=200M

# 清理旧的普通日志归档
sudo find /var/log -name "*.gz" -type f -delete
sudo find /var/log -name "*.old" -type f -delete

3. 优化多余的 Swap 交换文件
在之前的扫描中，我们发现系统有 swapfile (8GB) 和 swap.img (1.9GB) 两个交换文件。保留一个足矣，果断干掉冗余的 swap.img：

# 确认占用情况
swapon --show
# 关闭并删除多余的 swap.img
sudo swapoff /swap.img
sudo rm /swap.img
# 记得去 /etc/fstab 中注释掉对应行，防止重启报错
sudo nano /etc/fstab 

---

📈 第五步：大功告成，效果验收

经过一系列的清理操作，到了验收战果的时刻：

df -h

最终结果：

/dev/vda2 40G 28G 10G 74% /

✅ 救援成功：
磁盘使用率从危急的 94% 健康回落至 74%！
可用空间从捉襟见肘的 2.4GB 暴涨至 10GB！

再次用 ncdu 检查，庞大的 /root 目录已经从 13.3GB 缩水到合理的 1.9GB（正好是必须保留的 .openclaw 数据）。

💡 总结与建议

对于像 OpenClaw 这样在云端持续运行的 AI 代理服务，环境依赖（如 npm/python 包缓存）的默默消耗往往是导致磁盘告急的“隐形杀手”。为了防止未来再次遭遇 94% 的心跳暴击，建议：

1. 建立缓存清理机制：将 npm cache clean --force 和 apt autoremove 写入 crontab 定时任务中，每月自动执行一次。
2. 监控告警：在云服务商后台设置磁盘使用率 80% 的阈值告警，防患于未然。

如果你也正在云养 OpenClaw，不妨现在就登上服务器，敲下 df -h，给你的服务器做个体检吧！

---

(本文纯属实战复盘，执行删除命令前请务必确认当前目录及文件重要性，建议操作前做好快照备份。)