磁盘空间莫名其妙快速增长，是 Ubuntu 服务器最常见的“隐形杀手”之一。很多时候表面看是“磁盘满了”，但真正原因往往藏在几个容易被忽略的地方。本文系统梳理生产环境中导致磁盘异常增长的最常见 10 大原因，并给出针对性的排查与处理思路。
一、最常见的 10 大原因
- 日志文件无限制增长（出现频率最高，约占 40%+） 最典型：nginx/apache access.log / error.log、应用自定义日志、journald 未限制、mysql slow query log、redis/aof 文件等。
- 数据库文件膨胀 MySQL/PostgreSQL 的 binlog、slow log、general log 未开启自动清理；PostgreSQL 的 WAL 文件堆积；MongoDB oplog 过大；ClickHouse 数据目录膨胀。
- 缓存目录失控 /var/cache/apt/archives/ 积累了大量 deb 包 /var/cache/snapd/ 或 snap 缓存 PHP/opcache、nginx proxy_cache、Varnish、Redis 内存不足时写盘的 dump.rdb/aof
- Docker / 容器相关 Docker overlay2 存储驱动下镜像/容器/volume 层堆积 未清理的 exited 容器、dangling images、build cache 容器内日志未做 volume 外挂，导致容器内 /var/log 无限增长
- 临时文件未清理 /tmp、/var/tmp 被某些程序大量写入临时文件且未删除 编译构建、解压包、备份脚本产生的临时文件
- 用户家目录或项目目录膨胀 上传文件、备份文件、git 仓库克隆、日志文件、node_modules、venv、.cache 等 开发/测试用户在 /home 下放了大量数据
- 系统快照或备份残留 LVM 快照未删除、timeshift、btrfs 快照、rsync 增量备份未清理旧版本
- 内核旧版本占用 /boot 多次升级内核后旧内核未删除（尤其是 /boot 分区小的时候）
- 邮件队列堆积 /var/spool/postfix/ 或 exim 队列（邮件服务器常见）
- 其他隐蔽增长 core dump 文件（ulimit 未限制 core size） crash dump（/var/crash） systemd-coredump（/var/lib/systemd/coredump）
二、快速定位“谁在吃空间”的黄金流程
建议按以下顺序排查，通常 5–10 分钟就能找到元凶。
- 总体概览 df -h df -i（别忘了检查 inode 是否耗尽）
- 根目录下各文件夹占用排名（最关键一步） du -sh /* | sort -hr | head -15 通常前 3–5 名就能锁定问题目录
- 针对可疑目录继续深挖
- 日志类：du -sh /var/log/* | sort -hr
- 缓存：du -sh /var/cache/*
- Docker：docker system df
- 数据库：du -sh /var/lib/mysql /var/lib/postgresql 等
- 用户目录：du -sh /home/* /root/*
- 交互式神器（强烈推荐提前安装） ncdu / （像文件管理器一样浏览，按 d 删除，按 ? 查看帮助）
- 大文件/旧文件查找 find / -type f -size +500M -exec ls -lh {} ; 2>/dev/null find /var/log -type f -mtime +30 -size +100M
三、针对性处理方案
| 原因 | 立即处理 | 长期预防 |
|---|---|---|
| 日志文件无限制增长 | truncate -s 0 大日志文件 logrotate 配置 daily + rotate 7 + compress | /etc/logrotate.d/ 下为每个服务写规则 journald.conf 设置 SystemMaxUse=2G |
| Docker 膨胀 | docker system prune -a –volumes docker image prune -a | 设置 –log-opt max-size=50m 定期 cron prune |
| 数据库膨胀 | 清理 binlog：PURGE BINARY LOGS BEFORE ‘日期’ PostgreSQL：VACUUM FULL + WAL 归档 | 开启 binlog expire_logs_days 设置 logrotate 或 pg_cron 自动清理 |
| 缓存堆积 | apt clean / apt autoclean rm -rf /var/cache/apt/archives/* | unattended-upgrades + cron 每周清理 |
| 临时文件 | rm -rf /tmp/*（重启前较安全） | tmpfs 挂载 /tmp noexec/nosuid 选项 |
| /boot 旧内核 | apt autoremove 或手动 dpkg –purge linux-image-旧版本 | apt autoremove –purge 定期执行 |
| 用户目录乱放 | quota 用户配额 du -sh /home/* 找出大户沟通 | 教育用户、定期扫描 /home |
四、总结：生产环境防磁盘爆炸的“铁三角”
- 监控先行 netdata / prometheus-node-exporter + 告警（磁盘使用率 > 80% 告警）
- 自动化清理 每周 cron 任务：
- apt clean && journalctl –vacuum-time=30d
- docker system prune -f（谨慎）
- find /var/log -type f -mtime +90 -delete（配合备份）
- 日志策略 所有服务日志必须配置 logrotate 或 journald 限制 核心原则：日志永不应该无限制增长
记住一句话： “磁盘空间异常增长，99% 的根源都是‘某个进程在不停地写文件且没人管’”
只要养成“看到 df -h 异常 → du -sh /* → ncdu 深挖 → 定位写进程 → 配置 logrotate / 清理策略”的肌肉记忆，磁盘爆炸问题就能从“凌晨被叫醒”变成“提前一周就收到告警”。
