服务器磁盘爆满别先乱删：从 df、du、journalctl 到 Docker 日志的完整排查实战

服务器磁盘爆满告警

服务器最怕的一类故障，不是 CPU 高，也不是内存抖一下，而是磁盘直接 100%。磁盘一满，Nginx 可能写不了临时文件，MySQL 可能无法写 binlog，Redis 可能持久化失败，Docker 容器日志可能继续膨胀，连 SSH 登录后的命令补全都可能变慢。

很多新手看到磁盘爆满，第一反应是随手 rm -rf。这很危险。生产机器上删错目录，轻则丢日志、丢缓存，重则删掉数据库文件、上传附件、证书、配置，故障直接升级。正确做法是先保留现场，再定位是哪一类文件占空间，最后按风险级别清理或扩容。

本文按一次真实生产排障的顺序写：先判断哪个分区满，再定位大目录，再区分日志、Docker、数据库、上传文件、系统包缓存，最后给出清理、扩容、快照和预防方案。适用于腾讯云、阿里云、AWS、Azure、Oracle Cloud 和普通 VPS 上的 Linux 服务器。

参考来源：

Docker 官方日志驱动文档：https://docs.docker.com/engine/logging/configure/
Docker json-file 日志驱动文档：https://docs.docker.com/engine/logging/drivers/json-file/
systemd journalctl 官方手册：https://www.freedesktop.org/software/systemd/man/journalctl.html
腾讯云云硬盘快照文档：https://www.tencentcloud.com/document/product/362/31638

1. 先判断：到底哪个分区满了

排查总流程

第一条命令：

df -h

重点看这几列：

Filesystem Size Used Avail Use% Mounted on
/dev/vda1 50G 49G 300M 100% /
/dev/vdb1 200G 160G 40G 80% /data

如果 / 满了，系统日志、Docker 默认目录、包缓存、临时文件都可能是原因。如果 /data 满了，通常是数据库、上传文件、对象同步目录、备份包或业务日志。如果 inode 满了，明明还有容量也会创建不了文件。

检查 inode：

df -ih

inode 爆满常见于小文件太多，例如会话文件、缓存碎片、邮件队列、小图缩略图、临时任务输出。

2. 第二步：不要全盘 find，先用 du 定位大目录

先从根目录开始，只看一层：

sudo du -xhd1 / 2>/dev/null | sort -h

参数解释：

-x：不跨文件系统，避免扫到挂载盘。
-h：人类可读。
-d1：只看一层目录。

如果发现 /var 很大，再继续：

sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /var/log 2>/dev/null | sort -h

如果发现 /data 很大：

sudo du -xhd1 /data 2>/dev/null | sort -h

大目录定位

排障时不要一上来就执行这种命令：

sudo find / -type f -size +1G

它不是不能用，而是可能很慢，还会扫到挂载盘、虚拟文件系统和大量无关目录。先用 du -xhd1 把范围缩小，再用 find 精查更稳。

3. 第三步：常见元凶一，systemd journal 日志

systemd 的 journalctl 用来查看 systemd-journald 收集的日志。官方手册说明，journalctl 会打印 systemd journal 中保存的日志条目。很多服务器如果没有限制日志大小，长期运行后 journal 可能占用数 GB 甚至更多。

查看 journal 占用：

sudo journalctl –disk-usage

看最近错误：

sudo journalctl -p err -n 100 –no-pager
sudo journalctl -u nginx -n 100 –no-pager
sudo journalctl -u your-app -n 100 –no-pager

清理到指定大小：

sudo journalctl –vacuum-size=1G

或只保留最近 7 天：

sudo journalctl –vacuum-time=7d

注意：清理日志前先确认是否需要留证、审计或排障。如果机器刚发生故障，建议先导出关键日志：

sudo journalctl -u your-app –since "2 hours ago" > app-last-2h.log

4. 常见元凶二，Docker 容器日志

Docker 官方文档说明，默认 json-file 日志驱动会把容器日志以 JSON 形式存储在宿主机文件中；官方配置文档也提醒，如果默认 json-file 不做日志轮转，产生大量输出的容器可能导致磁盘空间被大量占用。

先看 Docker 占用：

sudo du -xhd1 /var/lib/docker 2>/dev/null | sort -h

查容器日志文件：

sudo find /var/lib/docker/containers -name '*-json.log' -type f -printf '%s %p\\n' 2>/dev/null | sort -n | tail -20

如果某个日志文件非常大，先确认容器名：

docker ps –no-trunc
docker inspect –format='{{.Name}} {{.LogPath}}' $(docker ps -aq)

Docker日志爆仓

临时清空单个容器日志：

sudo truncate -s 0 /var/lib/docker/containers/<container-id>/<container-id>-json.log

长期方案是配置日志轮转。示例：

{
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "3"
}
}

保存到：

/etc/docker/daemon.json

然后重启 Docker：

sudo systemctl restart docker

注意：重启 Docker 会影响容器，生产环境要确认业务窗口。

5. 常见元凶三，Nginx / 应用访问日志

查看 Nginx 日志：

sudo du -h /var/log/nginx/* 2>/dev/null | sort -h
sudo tail -n 50 /var/log/nginx/error.log

如果 access.log 很大，不能直接删掉正在写的文件。更稳的方式：

sudo mv /var/log/nginx/access.log /var/log/nginx/access.log.$(date +%F-%H%M)
sudo nginx -s reopen
gzip /var/log/nginx/access.log.*

如果应用日志很大，先找日志目录：

sudo du -xhd1 /opt 2>/dev/null | sort -h
sudo du -xhd1 /var/www 2>/dev/null | sort -h
sudo find /opt /var/www -type f -name '*.log' -size +100M 2>/dev/null

对于 Java、Node.js、Python、Go 服务，建议用日志切割或集中日志系统，不要无限写本地文件。

6. 常见元凶四，数据库和备份包

MySQL 常见大文件：

binlog
slow log
general log
dump 备份
临时导出文件

查看 MySQL 目录：

sudo du -xhd1 /var/lib/mysql 2>/dev/null | sort -h
sudo ls -lh /var/lib/mysql | tail

查看 binlog：

SHOW BINARY LOGS;
SHOW VARIABLES LIKE 'expire_logs_days';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

不要手动删除 MySQL binlog 文件。应使用 MySQL 命令清理，例如：

PURGE BINARY LOGS BEFORE '2026-08-01 00:00:00';

清理前必须确认备份和主从复制状态。否则可能导致恢复链断裂或复制异常。

7. 需要立刻恢复服务时，按风险分级处理

恢复优先级

低风险释放空间：

sudo journalctl –vacuum-size=1G
sudo apt clean
sudo yum clean all

中风险操作：

sudo truncate -s 0 large-app.log
sudo mv access.log access.log.bak && sudo nginx -s reopen

高风险操作：

删除数据库文件
删除上传目录
删除容器 volume
删除 /var/lib/mysql
删除 /var/lib/docker/volumes

这些操作没有确认前不要做。

8. 云服务器上更稳的方案：扩容、快照、迁移

如果磁盘已经反复满，不要只靠清日志。云服务器上更稳的路线是：

创建快照。

扩容云硬盘。

在系统内扩展分区和文件系统。

验证服务和数据。

腾讯云云硬盘快照文档说明，快照保存某一时间点的云硬盘副本，可用于恢复云硬盘到快照创建时的数据状态。不同云厂商都有类似能力，上线业务建议在重大清理、扩容和升级前先做快照。

Linux 内部扩容示例需要按文件系统类型执行：

lsblk
df -Th
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1

如果是 XFS：

sudo xfs_growfs /

实际设备名可能是 /dev/vda、/dev/nvme0n1 或其他名称，不要照抄设备名执行。

9. 预防清单：别等 100% 才报警

磁盘使用率超过 75% 发提醒，超过 85% 发告警。
Docker 配置日志轮转。
Nginx 和应用日志启用 logrotate。
数据库 binlog 设置合理保留期。
上传文件不要长期堆在系统盘。
备份包写到对象存储或独立数据盘。
每月做一次恢复演练。
重大清理和扩容前先创建快照。

10. 最后一张排查速查表

最终速查表

如果现在机器已经报警，可以按这个顺序执行：

df -h
df -ih
sudo du -xhd1 / 2>/dev/null | sort -h
sudo journalctl –disk-usage
sudo du -xhd1 /var/lib/docker 2>/dev/null | sort -h
sudo du -h /var/log/nginx/* 2>/dev/null | sort -h
sudo find / -xdev -type f -size +500M -printf '%s %p\\n' 2>/dev/null | sort -n | tail -20

磁盘爆满不是单纯“空间不够”，它往往暴露了日志治理、备份策略、应用异常输出、数据库保留策略和监控告警的缺口。真正稳定的服务器，不是永远不出问题，而是出问题时能快速定位、低风险恢复，并在下一次之前把同类问题挡住。

如果你正在维护网站、API、小程序后端或 AI 应用服务，可以把服务器配置、磁盘分区、Docker/Nginx/数据库情况整理清楚，再做针对性的容量和备份方案评估。