服务器磁盘空间不足怎么办：Linux 磁盘清理与日志清理操作教程

适用场景：什么时候需要做磁盘清理

服务器运行一段时间后，磁盘空间慢慢被吃满是非常常见的问题。典型表现包括：网站上传图片时报错、数据库写入失败、日志文件无法生成、系统命令执行时提示 "No space left on device"，甚至面板和 SSH 登录都变得异常缓慢。

常见的空间大户主要有几类：网站访问日志和错误日志长期累积、系统日志（journal、syslog）无上限增长、MySQL 的 binlog 二进制日志堆积、定时任务产生的大量输出文件、软件包缓存与旧内核，以及临时目录中的遗留文件。本文面向使用 Linux 服务器（CentOS、Ubuntu、Debian 等常见发行版）的站长和运维人员，给出一套可以直接照着做的排查与清理流程。

开始之前有一个重要提醒：涉及删除文件的操作都存在风险，尤其是日志和数据库相关目录。执行任何删除动作前，请先确认业务低峰期、做好关键数据备份，并逐条确认路径无误后再执行，避免误删正在使用的文件导致服务异常。

第一步：用 df 和 du 定位空间占用大头

清理磁盘的第一步不是删文件，而是先搞清楚空间到底被谁占了。先登录服务器，执行以下命令查看整体磁盘使用率：

df -h

这条命令会列出所有挂载点的总容量、已用容量和使用百分比。重点关注 Use% 达到 80% 以上的分区，通常是根分区（/）。如果根分区快满了，再逐层往下排查。

接下来用 du 命令找出大目录。先从根目录开始，查看一级子目录的占用情况：

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

这条命令会按大小倒序列出根目录下占用最多的 20 个目录。如果提示权限不足，可以在命令前加 sudo。找到占用异常的目录后，再进入该目录重复执行类似命令（把路径替换掉），逐层下钻，一般两三层就能定位到具体的大文件或大文件夹。

另外可以配合 find 命令直接搜索超过指定大小的大文件，例如查找全盘超过 500MB 的文件：

find / -type f -size +500M -exec ls -lh {} \; 2>/dev/null

第二步：清理系统日志与 journal 日志

在使用 systemd 的系统（如 CentOS 7+、Ubuntu 16.04+）上，journal 日志是常见的空间大户，长期不清理可能累积几个 GB。可以先查看当前 journal 占用：

journalctl --disk-usage

如果占用较大，可以只保留最近 7 天的日志（请根据合规与排查需求评估保留时长）：

journalctl --vacuum-time=7d

也可以按总大小限制，例如只保留 500MB：

journalctl --vacuum-size=500M

为了避免以后再次无限增长，建议同时修改配置做长期限制。编辑 /etc/systemd/journald.conf，将 SystemMaxUse 设置为合理值（如 SystemMaxUse=500M），保存后执行 systemctl restart systemd-journald 使配置生效。修改系统服务配置前，建议先备份原文件。

对于传统的 syslog 类日志（/var/log 下的 messages、syslog 等），如果配置了 logrotate 轮转一般不会失控；若发现单个日志异常巨大，先检查对应服务的日志级别配置，再考虑轮转或归档后删除旧文件。

第三步：清理 Nginx/Apache 与网站日志

网站访问日志是流量较大的站点最常见的空间消耗来源。以 Nginx 为例，日志通常位于 /var/log/nginx/ 目录，可以先查看占用：

du -sh /var/log/nginx/

如果日志文件很大，不建议直接 rm 正在被写入的日志文件——那样空间不会立即释放，进程仍持有文件句柄。推荐的做法是先复制归档再清空，或使用 truncate 截断：

truncate -s 0 /var/log/nginx/access.log

更规范的方式是配置 logrotate 自动轮转。大多数发行版安装 Nginx 时已自带 /etc/logrotate.d/nginx 配置，可以检查其中 daily（按天轮转）、rotate 14（保留份数）等参数是否符合需求。调整前同样建议先备份原配置文件。

宝塔面板用户可以直接在面板的"日志"相关设置里设置网站日志保留天数或关闭不需要的站点日志，比手动清理更省心。但关闭日志前请评估：日志在排查攻击和异常流量时非常有用，重要站点建议至少保留一段时间的访问日志。

第四步：清理 MySQL binlog 与软件包缓存

开启了 binlog 的 MySQL 数据库，二进制日志可能积累几十 GB。先登录 MySQL 查看占用情况：

SHOW BINARY LOGS;

再查看 binlog 的保留策略：

SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

如果保留时间过长，可以调整为保留 7 天（604800 秒），该参数可在 my.cnf 中配置后重启数据库生效，或在线执行 SET PERSIST 立即生效。注意：清理 binlog 前务必确认备份策略完整，因为 binlog 是数据恢复和主从复制的重要依据，删除前建议先用 mysqldump 或物理备份做一次全量备份。

软件包缓存方面，CentOS 系可以执行 yum clean all 清理 yum 缓存；Ubuntu/Debian 系可以执行 apt-get clean 与 apt-get autoremove 清理缓存和无用依赖包。旧内核也会占用 /boot 分区空间，autoremove 可以一并处理，但删除内核前请确认当前正在使用的内核不会被移除。

常见问题与注意事项

问题一：删除大文件后 df 显示空间没有释放？ 这通常是因为有进程仍持有该文件的句柄，常见于日志文件被直接 rm 的情况。可以用 lsof | grep deleted 查找已删除但仍被占用的文件，重启对应服务（如 nginx、mysql）后空间即会释放。因此删除正在被写入的日志时，优先用 truncate 而不是 rm。

问题二：磁盘没满但 inode 用完了怎么办？ 用 df -i 查看 inode 使用率。如果 inode 接近 100%，说明是海量小文件导致，常见于 session 文件、邮件队列、缓存碎片。用 find /var -type f | wc -l 之类的命令定位小文件集中的目录，再针对性清理。

问题三：可以设置定时自动清理吗？ 可以。将清理命令写入 crontab 定时执行（例如每天凌晨清理 7 天前的临时文件），或依赖 logrotate 自动轮转。但自动删除类任务务必先用 find -mtime 测试匹配到的文件列表，确认无误后再挂到定时任务，避免误删。

问题四：清理后空间很快又满了？ 说明存在持续增长源，比如某个服务在疯狂打日志、数据库 binlog 未限制、或有程序在无限写临时文件。清理只是治标，应回到第二步继续用 du/find 定位增长源，从配置层面限制（如降低日志级别、设置 binlog 过期时间、配置 logrotate）。

总结

磁盘清理的核心流程可以概括为四步：先用 df -h 确认使用率，再用 du/find 定位占用大头，然后按"系统日志 → 网站日志 → 数据库日志 → 软件包缓存"的顺序逐项清理，最后通过 logrotate、journald 限制和 binlog 过期策略防止问题复发。

整个过程中最重要的原则是安全第一：删除任何文件前先备份、先确认路径与业务影响；正在被写入的日志用 truncate 处理而不是直接删除；自动清理任务上线前先小范围验证。养成定期检查 df -h 的习惯（可以配合监控告警或定时任务），在磁盘使用率达到 80% 时就提前介入，能避免绝大多数因磁盘写满引发的服务故障。