服务器主机磁盘占用过高，八成是日志、备份或临时文件在作祟，清理前先定位再动手。
服务器磁盘空间不足怎么办？先查这三大元凶
磁盘空间告急时，别急着扩容。多数情况下罪魁祸首是日志文件、系统备份和临时缓存，这些文件悄无声息地蚕食着GB级空间，业内专家指出，企业在运维中遇到的磁盘问题,相当一部分源于缺乏定期审查机制。
日志文件：最容易被忽视的磁盘杀手
服务器运行过程中，各级应用和系统服务会持续生成日志。默认日志保留策略往往过于宽松，有些系统甚至设置为“永久保留”。
- 系统日志：
/var/log/目录下的messages、syslog、secure等文件，按周轮转，但若未合理配置轮转周期,单文件可轻松超过10GB。 - 应用日志：Web服务器（如Nginx、Apache）、数据库（MySQL、PostgreSQL）的慢查询日志和错误日志,在高并发环境下日增量可达数GB。
- 容器日志：Docker或Kubernetes环境下，容器标准输出日志若不限制大小,会迅速撑爆主机的系统盘。
一个实用的操作路径：登录服务器后执行 du -sh /var/log/ 查看各日志文件大小，再结合 logrotate 配置，将日志保留天数从90天缩短到30天，并启用压缩，清理后你可能会发现，被占用空间的一半以上都来自不该留存的日志。
系统备份与快照：冗余堆叠的陷阱
自动备份本是好事，但多份全量备份同时保留，磁盘占用会成倍增长，尤其是数据库备份，一次全量备份动辄几十GB，若保留7天增量加1次全量，空间消耗远超预期。
- 云服务器快照：很多用户勾选“自动快照”后未限制保留份数，导致快照积累到几十份,每份是完整磁盘镜像。
- 本地备份脚本：cron任务执行的tar打包，若未做增量处理,每周全量备份会持续占用固定大小空间。
建议：检查备份目录（如 /backup 或 /data/backup），确认保留策略，行业共识认为，保留3份全量备份加两周增量足以应对绝大多数恢复场景
,超出部分可直接删除或迁移到对象存储。
临时文件与缓存：系统运行的副产品
应用程序运行时产生的临时文件、编译缓存、系统更新缓存,同样会长期驻留。
- 包管理缓存：
yum或apt下载的包文件，安装后不会自动删除,时间久了可能积累几个GB。 - 编译中间文件：源码编译安装时，
/tmp或/usr/src下残留的obj文件、configure产物。 - 系统快照缓存：某些系统如Ubuntu的snapd，会保留多版本应用快照,一个snap包可能占用数百MB。
操作命令：sudo apt autoremove 清理过时依赖，sudo journalctl --vacuum-time=3d 限制系统日志保留时间，du -sh /tmp 检查临时目录。
服务器磁盘清理方法：从手动到自动的实操指南
定位到问题后，怎么清理？推荐按“先确认、再清理、后归档”的步骤执行,避免误删关键文件。
手动清理解放空间
对于临时性告警,直接手动清理最高效。
- 日志轮转测试：
sudo logrotate -f /etc/logrotate.conf强制轮转日志，并压缩旧日志为.gz，空间可回收50%以上。 - 删除过时备份：
find /backup -type f -name ".sql" -mtime +30 -delete删除30天前的备份文件。 - 清理缓存目录：
rm -rf /tmp/清空临时目录,但需确保没有进程正在使用。
注意：清理前用 du -sh 查看目标目录总大小，确认影响范围。一次清理后如果磁盘占用率从95%降到70%，说明操作有效,后续只需定期执行。
自动化脚本：让清理成为习惯
手动操作总有疏漏，建议配置cron任务，每周自动执行清理脚本。
脚本核心逻辑示例：
# 清理系统日志（保留3天） sudo journalctl --vacuum-time=3d # 清理应用日志（保留7天） find /var/log/nginx -mtime +7 -name ".log" -delete # 清理包缓存 sudo apt-get clean
将该脚本保存为 /usr/local/bin/disk-clean.sh，添加执行权限，并在crontab中添加
0 2 0 /usr/local/bin/disk-clean.sh,每周日凌晨2点执行。
行业共识认为，合理的自动化清理策略，能将磁盘90%的突发占用问题扼杀在摇篮里,运维人员只需关注异常告警而非日常维护。
极端情况：磁盘完全占满时的应急操作
当磁盘空间为0，连 df 命令都可能卡住,怎么办？
- 立即停止非核心服务：如Web服务器、日志收集器,释放被占用的文件句柄。
- 使用
lsof找回被删除但未释放空间的文件：lsof | grep deleted，找到这些文件后，执行> /proc/.../fd/...清空,空间立即释放。 - 临时迁移日志：将当前日志目录软链接到另一块有空间的磁盘,重启日志服务。
这一步是救命操作，可以让你在5分钟内从“磁盘100%”恢复到“15%可用”状态,后续再从容做持久化方案。
服务器磁盘扩容方案：什么时候该加盘？
清理只能解决短期问题，如果业务增长导致磁盘长期处于高水位，扩容才是根本方案，但扩容前，先判断是否必须加盘,还是可以优化现有分配。
先评估：是真的需要扩容，还是分配不合理？
- 检查分区使用率：
df -h显示/dev/sda1使用率95%，但/data分区只有30%，是否可以把数据迁移到/data？ - 检查是否有大文件未归档：
du -sh / | sort -rh | head -10找出根目录下最大的前10个目录，有时是某个应用将数据写在了系统盘,而不是数据盘。
场景描述：一家电商公司服务器磁盘告警，运维发现是数据库binlog写在了系统盘，而数据盘还有大量空闲。仅通过迁移binlog路径，就将系统盘使用率从90%降到30%,节省了扩容成本。
扩容方案选择：云盘与本地盘
如果确定需要扩容,根据服务器类型选择方案：
| 方案 | 适用场景 | 操作复杂度 | 成本 |
|---|---|---|---|
| 云盘在线扩容 | 云服务器，如简米云、酷番云 | 低，控制台直接调整 | 按量计费，短期可退 |
| 数据盘挂载 | 有额外数据盘槽位 | 中，需格式化挂载 | 一次购买 |
| 本地盘替换 | 物理服务器，性能要求高 | 高，需迁移数据 | 硬件成本较高 |
| 存储集群扩容 | 分布式存储场景 | 高，需重新平衡 | 按节点增加 |
推荐：对于大多数企业，云盘在线扩容是性价比最高的方案，无需停机，几分钟内完成，但需注意，扩容后通常需要扩展文件系统（如 resize2fs 或 xfs_growfs）,控制台操作后别忘执行这一步。
扩容后的长期规划
扩容不是终点，建议结合监控工具（如Prometheus + Grafana）设置磁盘使用率告警，在达到80%时提前介入，建立数据生命周期管理，定期归档冷数据到对象存储,让服务器磁盘专注于热数据。
服务器主机占用磁盘常见问题解答
服务器磁盘空间明明显示满了，但用 du 统计却找不到大文件，怎么回事？
这种情况通常是被已删除但未释放文件句柄的进程占用。可以用 lsof | grep deleted 查看，然后找到对应进程，重启或重定向文件描述符即可释放空间，也可能是挂载点覆盖导致，检查 /proc/mounts 确认是否有重复挂载。
清理日志后，磁盘空间并没有立即释放，为什么？
可能是日志文件正被进程写入，删除后进程仍持有文件描述符，空间不会释放，直到进程重启或 service rsyslog restart 才生效。优先使用 truncate -s 0 清空文件内容而非直接删除，这样在进程仍在运行时也能释放空间,且不影响写入。
服务器磁盘扩容时，是否必须关机？
云服务器多数支持在线扩容，无需关机，但物理服务器或本地盘扩容，通常需要停机操作，尤其是RAID重组或更换硬盘时。建议在业务低峰期操作，并提前做好快照备份。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/518536.html
