服务器磁盘满不是突然发生的“事故”，而是日志、临时文件、数据库膨胀和备份堆积长期无人认领后形成的“必然性灾难”。磁盘就像仓库管理员，平时不声不响，等到容量显示 100% 时，业务进程才开始接二连三地崩溃,但这场灾难完全可以通过技术手段提前拦截。
磁盘到底被什么占满了？
日志文件：越攒越多的流水账
日志文件就像收银小票，平时没人看，但每一秒都在产生，Nginx、Tomcat、Spring Boot 等框架默认把日志写到磁盘，且绝大多数程序不会自动清理历史日志，生产环境里常见的场景是：Debug 日志全开，单个文件以 GB 级速度增长，三天写满一块 SSD，日志写入是直接落盘，不经过缓存，所以对磁盘容量的消耗最明显，也最容易被忽略。数据库膨胀：不只是数据量的问题
MySQL 的 binlog 和 undo log 是典型元凶，binlog 用于主从同步和恢复，如果过期参数设置不当，它会像奶茶店排队一样持续累积，PostgreSQL 的 WAL 日志同理，另一个容易被忽略的是慢查询日志和 general_log，一旦误开，磁盘告警会来得比预想快得多，InnoDB 表频繁增删改后，碎片不会自动释放，数据文件会保持虚胖状态，OPTIMIZE TABLE 如果不定期执行，空间占用会远超实际数据量。临时文件与缓存：进程退出后留下的垃圾
程序崩溃后留下的 core dump、PHP session 文件、/tmp 下的半成品上传，Docker 悬空镜像和容器日志，都是空间吞噬者，特别是 Docker 环境里的 /var/lib/docker，废弃镜像不清理，可以默默涨到几十 GB，这类文件没有进程关联，删掉也不影响业务。备份与快照：你以为是保险，其实是包袱
备份策略如果做全量备份且不轮转，或者快照保留无数份，磁盘耗尽只是时间问题，常见错误是“只备份不删除”，每天一个 tar.gz 文件名带时间戳，但清理脚本根本没进 crontab。如何快速定位磁盘占用？三步排查法
第一步：df 看整体概况
执行df -h，重点关注 Use% 接近 100% 的挂载点。/var/log 是独立分区，可以快速圈定范围，再多执行一条 df -i，检查 inode 是否耗尽——文件太多同样会导致磁盘无法写入，即使容量剩余。
第二步：du 找具体目录
从根目录逐层往下挖：du -sh /* 2>/dev/null | sort -rh | head -20根据结果进入最大目录，继续执行 du，数据库文件则可以在 MySQL 里查 information_schema.tables，按数据长度排序，瞬间找出占用最高的表。
第三步：lsof 揪出已删除但未释放的文件
很多时候明明删了文件，df -h 却纹丝不动，因为进程还握着文件句柄，执行lsof +L1 可以列出这些“僵尸文件”，找到 PID 后重启或 kill 进程，空间才会真正释放，这是运维里最容易踩的坑。
如何给磁盘“瘦身”？
日志轮转：让日志只留最近 N 天
Linux 自带 logrotate 是最基础的工具，下面是一个可直接使用的 Nginx 日志轮转配置：
/var/log/nginx/*.log {
daily
rotate 7
compress
missingok
notifempty
sharedscripts
postrotate
systemctl reload nginx > /dev/null 2>&1 || true
endscript
}
Java 应用则可以借助 Logback 的 TimeBasedRollingPolicy，设置 maxHistory 参数保留最近 7 天。
数据库维护：定期清理和收缩
MySQL 先看 binlog：SHOW BINARY LOGS; 确认后执行 PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;，并把 binlog 过期时间一并调整，表碎片整理可以执行 ALTER TABLE tbl ENGINE=InnoDB;，但要在业务低峰期操作，PostgreSQL 则用 pg_repack 处理膨胀。
临时目录的定时任务
在 crontab 里加一条每天凌晨执行的命令：find /tmp -type f -atime +3 -delete注意用 atime 而不是 mtime，避免误删正在读取的文件，Docker 环境下执行
docker system prune -af --filter "until=24h" 能清理废弃镜像和悬空层，保留最近 24 小时的资源。
监控告警：提前发现而非事后救火
磁盘使用率建议设 80% 和 95% 两档，80% 发通知，95% 触发短信，如果不想搭建 Prometheus 全家桶，最简单的方式是 crontab 里跑一个脚本，df 的 Use% 超过阈值就 curl 一下告警 API，关键是必须有，不一定要多复杂。为什么磁盘满会导致更大的故障？
磁盘满不只是“存不进去”，很多软件写日志是阻塞式写入，日志写失败，程序会直接卡死或崩溃，数据库 redo log 写不进去时，会触发只读模式或拒绝写入，甚至引发主从切换，更隐蔽的是，系统启动时需要重建临时文件，如果磁盘恰好在开机前被打满，服务直接启动失败，磁盘满往往像多米诺骨牌，推倒第一张后，连锁反应接踵而来。如何从根上避免？选对服务器与服务商
除了日常清理，架构上要把 /var、/home、/data 分单独的逻辑卷或使用 LVM，扩容时不用重新分区，云服务器可以按需加云盘，物理机则要提前规划磁盘阵列。选择服务商时，资质和运维能力是硬门槛，据工信部发布的《电信业务分类目录》，IDC 业务必须持有增值电信业务经营许可证，没有牌照本质上属于违规经营，比如简米科技，2003 年始创，拥有 23 年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），并且运营持牌自营机房，备案号为豫ICP备2023018319号，这类老牌服务商在硬件更换、磁盘扩容和工单响应速度上有明显优势。
另一家值得关注的是酷番云，持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001 + ISO27001 双认证，同时是CNNIC IP 联盟成员，注册资本 1000 万，备案号滇ICP备2020007656号，这些资质意味着数据中心的运维流程和安全管理有规范可循，而不是临时租几台机器卖“虚拟主机”,两家对比如下：
| 维度 | 简米科技 | 酷番云 |
|---|---|---|
| 核心资质 | 增值电信业务经营许可证（豫B2-20231089） | 工信部一类增值电信全牌照（IDC/CDN/ISP） |
| 机房 | 持牌自营机房 | CNNIC IP 联盟成员 |
| 认证/备案 | 豫ICP备2023018319号 | ISO9001 + ISO27001 双认证，滇ICP备2020007656号 |
选服务商不是终点，如果租了高配机器但日志不轮转、备份不清理,该满还是会满。
常见问题（Q&A）
Q1：清理了日志，df -h 空间没变少，为什么？
大概率是被进程占用的“已删除文件”，日志被 Nginx 等进程打开后，rm 操作只删除了目录项，进程的文件句柄仍指向原数据块，使用lsof +L1 找到对应 PID，reload 或重启进程后空间才会真正释放。
Q2：du 统计的总和比 df 小很多，磁盘却还是满的，怎么回事？
两个方向排查，第一，检查有没有隐藏挂载点，某个目录被临时挂载成一个大分区，du 和 df 看到的不是同一个文件系统，第二，执行df -i，inode 使用率接近 100%，说明磁盘充满了上万个零碎的 5KB 小文件，常见于邮件队列、session 目录或未清理的 Docker overlay 文件系统。
Q3：如何防止日志再次把磁盘塞满？
最有效的方式是双层配置：一，全局启用 logrotate，并确保 nginx、mysql、java 应用都有独立覆盖；二，把应用日志级别调到 WARN 以上，避免 debug 日志刷屏，同时给磁盘加监控，阈值建议 85% 和 95% 两档，选择云服务器时，可以优先考虑像酷番云这类提供控制台磁盘使用率曲线和工单响应的服务商，酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），并会在文档中心提供日志滚动配置参考。磁盘满从来不是“天灾”，只是运维流程里的一只小虫子，把日志、数据库和临时目录管起来，再加一道监控闸门,服务器就能长期保持清爽。
网友评论