Linux 磁盘满了别慌：从定位到清理的完整排查手册

磁盘满是最容易让人手忙脚乱的线上故障：服务写不进日志、数据库拒绝写入、部署传包失败，第一反应往往是到处删文件。其实只要按固定顺序排查，大多数问题十分钟内就能定位，而且不会误删关键数据。

第一步：先看整体，再看细节。先用 df -h 确认是哪块盘满了，是根分区、数据盘还是日志盘；再用 df -i 看 inode 使用率。很多人只看空间，却忽略了小文件过多导致 inode 耗尽，表现同样是写不进文件，这时删大文件也无济于事。

第二步：找到真正的大户。用 du -sh /var/* 之类的方式逐层下钻，或者用 du -h --max-depth=1 / 排序，优先看日志、备份、缓存和临时目录。常见的嫌疑对象包括滚动失效的应用日志、未清理的数据库 binlog、反复下载的安装包、容器镜像层和长期堆积的 core dump。定位时不要一上来就 rm -rf，先确认目录归属和用途。

第三步：区分能删、能挪、不能动。能删的是明确的过期日志、临时文件和已确认无用的备份；能挪的是历史归档和冷数据，可以先移到对象存储或另一块盘；不能动的是正在运行的业务数据、数据库主文件和系统关键目录。凡是拿不准的，先改名或移动到回收站目录，观察一天再彻底删除。

还有一个经典陷阱：文件删了，空间却没释放。这通常是因为进程还持有已删除文件的句柄，磁盘空间要等进程退出或文件描述符关闭才会回收。可以用 lsof | grep deleted 找到相关进程，重启对应服务或让应用重新打开日志文件即可。直接重启整台机器虽然有效，却不是首选做法。

日志问题要从源头治理。检查日志轮转是否生效，确认 logrotate 配置、保留天数和压缩策略；对增长最快的服务单独设置级别，避免把调试日志长期开在生产环境。数据库方面，定期清理过期 binlog 和慢查询日志，并把备份放到独立存储，避免备份把业务盘写满。

清理完成后还要做三件事：一是重新执行 df -h 和 df -i 确认恢复；二是检查服务是否恢复写入，看看最近的日志是否正常滚动；三是记下这次的大户目录和增长原因，写进运维清单。临时救火结束，真正的收尾是预防。

预防比清理便宜得多。给关键分区设置 80% 和 90% 两档告警，留出处理时间；给日志和备份目录设置配额或独立分区，避免一个服务拖垮整台机器；定期做一次磁盘巡检，把增长趋势画出来，提前扩容或归档。遇到磁盘满，先稳住服务、再定位大户、最后安全清理，这套顺序比任何删除命令都重要。