服务器磁盘清理不是可做可不做的日常任务，而是直接影响系统稳定性和业务连续性的关键操作，一旦磁盘空间耗尽，轻则服务响应变慢，重则数据库崩溃、网站无法访问，最有效的清理方法是通过系统自带工具和定制脚本，定期自动化处理日志、缓存和临时文件。参考2
为什么服务器磁盘空间总是不够用
很多运维人员是在服务器报警之后才去排查磁盘问题,磁盘空间的消耗速度往往被低估，日志文件、系统更新缓存、数据库 Binlog、Docker 容器日志、用户上传的临时文件，这些都在不断累积，一台运行半年的 Web 服务器，仅 Nginx 访问日志就可能占用几十 GB，如果不对这些文件做清理策略，磁盘很快就会被填满。
从行业共识来看,磁盘使用率长期超过 80% 会显著影响 I/O 读写性能，对于数据库服务器尤其明显，当剩余空间低于 5% 时，Linux 系统还会限制普通用户写入，导致服务异常，清理磁盘不是等到满了再处理，而是应该建立常态化机制。
服务器清理磁盘命令有哪些
不同操作系统下的清理命令差异很大,但核心思路一致：找到占用空间的大文件，删除无用数据，释放 inode 和块空间，以下是最常用的命令组合，适用于绝大多数 Linux 环境。
查找大文件和目录
使用 du 命令可以快速定位磁盘空间的“罪魁祸首”，常用参数组合：
du -sh / 2>/dev/null | sort -rh | head -10这条命令列出根目录下每个子目录的占用大小,并排序显示前 10 个，如果想查看某个目录更深层的占用，可以换成 du -sh /var/log/。du -sh 是排查磁盘空间的起点，几乎所有磁盘清理都要先跑这一步。
清理日志文件
日志是占用空间的最大来源之一,系统日志（/var/log）、应用日志（/var/log/nginx、/var/log/mysql）都需要关注，手动清理可以执行：
truncate -s 0 /var/log/.log使用 truncate 将文件内容清空，保留文件本身，避免因为删除文件导致正在写入日志的进程异常，如果要清理超过指定天数的日志，可以用 find 配合 -mtime 参数：
find /var/log -name ".log" -mtime +30 -delete这条命令会删除 30 天前的 .log 文件，建议先不加
-delete 跑一遍，确认文件列表无误后再执行删除。参考2
清理包管理缓存
apt 或 yum 在更新系统时会下载大量缓存包，这些包在安装完成后就不再需要。
apt autoremove -y
apt autoclean对于 CentOS 系统，使用 yum clean all。apt autoremove 还能自动删除不再被依赖的内核和驱动，这一操作通常能释放几百 MB 到几个 GB 的空间。
清理 Docker 环境
Docker 容器是无状态部署的利器，但停止的容器、未使用的镜像、悬空的卷会持续占用磁盘，一条命令清理所有无用资源：
docker system prune -a --volumes这条命令会删除所有停止的容器、未被任何容器使用的镜像、以及所有未被容器挂载的卷，执行前请确认没有正在使用的临时存储，如果容器数量较多，建议分步执行，先清理镜像，再清理卷。
清理 journal 日志
systemd 的 journal 日志默认会一直保留，占用空间可能出乎意料，查看当前日志占用：
journalctl --disk-usage设置日志保留时间或最大大小比较有效：
journalctl --vacuum-time=7d
journalctl --vacuum-size=500M第一条只保留最近 7 天的日志，第二条将日志总量限制在 500 MB，这些命令可以配置成定时任务，防止日志无限增长。
如何清理服务器磁盘空间（场景化指南）
命令只是工具,真正的问题在于：不同场景下应该优先清理什么？以下按常见服务器类型给出具体操作路径。
Web 服务器：访问日志和错误日志是重点
一台 Nginx 服务器运行半年，access.log 和 error.log 可能膨胀到几十 GB，如果日志文件分散在多个域名目录下，先用 du -sh /var/log/nginx/ 查清每个站点的大小，然后对超过 30 天的日志进行压缩并自动删除。
推荐做法：配置 logrotate 工具，按天或按大小分割日志，保留最近 30 天的记录，并自动压缩旧日志，logrotate 的配置文件在 /etc/logrotate.d/，针对 Nginx 可以这样设置：
/var/log/nginx/.log {
daily
rotate 30
compress
delaycompress
missingok
notifempty
create 640 nginx adm
}这样就不用手动清理,系统每天自动处理。
参考2
数据库服务器：慢查询日志和 Binlog 是藏污纳垢的地方
MySQL 的慢查询日志如果长期开启，会积累大量日志，建议在排查性能问题时开启，平时关闭，Binlog 的清理则更为关键，因为它直接影响数据库恢复，设置 expire_logs_days 参数，让系统自动删除过期日志：
SET GLOBAL expire_logs_days = 7;或者在配置文件中永久生效,清理前请确认数据库备份策略，Binlog 时间内不要短于全量备份间隔。
文件服务器：临时上传目录和缓存目录
文件服务器（如 FTP、SFTP、对象存储网关）的临时目录往往是磁盘空间的黑洞，用户上传文件后未及时清理，或者分片上传的碎片未被合并，都会占用空间，建议设置 crontab 定时清理超过 24 小时的临时文件：
find /tmp -name ".part" -type f -mtime +1 -delete对于缓存文件（如 Nginx 的 proxy_cache、CDN 回源缓存），可以设置缓存过期时间，并在磁盘空间紧张时主动清理。
容器化环境：镜像层和容器日志
容器化服务器中,镜像和容器的日志文件是两大空间大户，Docker 默认日志驱动是 json-file，单个容器日志没有大小限制，会一直增长。建议在启动容器时限制日志文件大小：
--log-opt max-size=10m --log-opt max-file=3这个参数让每个容器日志文件最大 10 MB，保留 3 个轮转文件，超过后自动删除旧日志，配合 docker system prune 定期执行，可以保持容器环境干净。
服务器磁盘清理的注意事项
清理磁盘操作不当可能导致服务中断、数据丢失，甚至系统崩溃，以下几条业界总结的规则必须遵守：
- 永远不要在生产环境直接删除文件而不确认，先用
du和find列出文件清单，确认没有业务依赖后再执行删除操作，对于日志文件，优先使用truncate而非rm，避免句柄泄漏。 - 清理前检查 inode 使用情况，有时候磁盘空间还有剩余，但 inode 耗尽，同样无法写入文件，使用
df -i查看 inode 使用率，inode 满了，需要清理大量小文件（如邮件队列、session 文件）。 - 不要随意删除 /var/log/wtmp 或 /var/log/btmp 这样的系统文件，这些文件记录登录历史，删除后会影响安全审计，建议使用
logrotate
- 对于生产环境，清理操作尽量在业务低峰期执行，尤其是数据库服务器，清理 Binlog 或重建索引可能会产生 I/O 压力，影响线上查询。
- 建立自动化清理脚本，并定期测试，可以将清理命令写成 Shell 脚本，放到 crontab 中每周执行一次，脚本中要加入日志记录，方便回溯，首次执行后，观察至少一周，确保没有误删文件。
服务器清理磁盘常见问题
服务器磁盘满了怎么办，但无法删除任何文件？
如果磁盘满且找不到大文件,通常是进程占用了已删除的文件句柄，使用 lsof | grep deleted 命令，会发现大量标记为 (deleted) 的文件，这些文件已被删除但仍在被进程打开，此时只能重启对应进程，或者直接重启服务器来释放空间。建议先重启占用最大的进程，Nginx 或 Tomcat，避免影响所有服务。
清理服务器磁盘后，服务性能没有明显提升？
磁盘清理的主要作用是释放空间,防止服务因空间不足而异常，对于性能提升，更关键的是磁盘 I/O 的优化，如果清理后空间充足但性能依然慢，需要检查磁盘是否使用的是 HDD 而非 SSD，或者是否存在大量随机读写操作，清理操作本身不会直接提升 I/O 速度，但可以减少因磁盘碎片或 inode 压力导致的额外开销。
如何保证服务器清理磁盘脚本不会误删重要数据？
脚本上线前,先在测试环境运行，确认逻辑无误，脚本中对于删除操作，可以先使用 -print 或 -ls 代替 -delete，将输出结果写入日志，人工复核后再启用删除。在脚本中强制添加文件路径白名单，只允许清理特定目录（如 /var/log、/tmp、/var/cache），禁止删除业务数据目录，对于数据库 Binlog，清理前需要通过 PURGE BINARY LOGS 语句，而非直接删除文件，以保证 MySQL 内部记录一致。
服务器磁盘清理不是一次性的应急动作,而是需要融入日常运维的健康检查项，通过命令排查、工具配置和脚本自动化，可以在不增加运维负担的前提下，有效避免磁盘写满导致的故障，最理想的状态是：磁盘使用率始终保持在 60% 至 80% 之间，空间预警永远不需要触发。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/530642.html
