服务器磁盘快满了，先别急着删：用 du、journalctl 和 logrotate 三步定位清理

磁盘报警最常见的第一反应是到处删文件，结果往往是删错了、空间也没释放，或者第二天又满了。更稳妥的顺序是：先确认是哪个分区满、再定位到具体目录和大文件、最后用系统自带的轮转机制把增长管住，而不是一次性清掉所有日志。

第一步：确认满的是哪里，是空间满还是 inode 满

df -h

df -i

只看 Use% 最高的那一行。如果是根分区满，就从根分区往下查；如果是 /var 单独分区，就重点查 /var。df -i 也要看，inode 用满时即使 df -h 还有空间，也写不进新文件，常见原因是大量小文件。

第二步：用 du 一层层往下找，不要一上来就删

du -h --max-depth=1 / 2>/dev/null | sort -hr | head -20

找到最大的目录后，再往下一层：

du -h --max-depth=1 /var 2>/dev/null | sort -hr | head -20

如果怀疑是某个大文件，直接找出来：

find / -xdev -type f -size +500M 2>/dev/null | head -20

-xdev 的作用是只在当前文件系统里找，避免把挂载的其他盘也扫进来。找到大文件后先看它属于哪个服务、最近还在不在写，再决定处理方式。

第三步：日志往往是大头，先看 journal，再看应用日志

journalctl --disk-usage

如果 journal 占了几个 GB，可以先按大小或时间清理，清理前确认不需要这么久的日志留存：

journalctl --vacuum-size=500M

journalctl --vacuum-time=7d

要长期管住，在 /etc/systemd/journald.conf 里设置，例如 SystemMaxUse=500M，然后重启 journald 生效：

systemctl restart systemd-journald

应用日志则看 /var/log 下按大小排序：

du -sh /var/log/* 2>/dev/null | sort -hr | head -20

第四步：删之前先分清“正在写的文件”和“已删除还占着的文件”

对正在被进程写的文件，直接 rm 并不一定释放空间，文件可能变成 deleted 状态继续占盘。先查：

lsof | grep deleted

确认后更安全的做法是清空而不是删除，例如：

: > /var/log/xxx.log

或者用 truncate -s 0 /var/log/xxx.log。这样进程不用重启，空间马上释放。如果是已经不需要的历史日志压缩包、旧备份，先移到别处或确认备份后再删，不要凭文件名猜。

第五步：用 logrotate 把日志增长管住，而不是每次手动救火

给自己的应用写一个轮转配置，例如 /etc/logrotate.d/myapp：

/var/log/myapp/*.log {

  daily

  rotate 7

  compress

  missingok

  notifempty

  copytruncate

}

copytruncate 适合不能重启的应用，它是复制后清空原文件；如果应用支持重新打开日志文件，用 create + postrotate 重启或发信号更干净。写完后先演练，不要直接等第二天：

logrotate -d /etc/logrotate.d/myapp

logrotate -f /etc/logrotate.d/myapp

-d 是调试输出，不真正轮转；确认无报错后再用 -f 强制跑一次验证。

收尾检查清单

1. 再跑一次 df -h 和 df -i，确认 Use% 和 inode 都回到安全线以下。

2. 确认关键服务还能正常写日志，不要只看空间数字。

3. 把这次最大的三类占用记下来，下次报警时直接先查这三处。

一句话总结：先 df 定位分区，再 du 定位目录和文件，再用 journalctl 和 logrotate 管住日志增长；正在写的文件用清空代替删除，已删未释放的文件用 lsof 查出来。这样处理一次，磁盘问题才不容易反复出现。