站点运营里，磁盘空间往往是最不起眼、却最容易突然出问题的一项。流量没涨、内容没加，服务器却提示写入失败，数据库变成只读，图片上传不了，缓存也写不进去，最后页面直接打不开。很多时候不是程序突然坏了，而是磁盘被日志、备份、缓存和临时文件慢慢填满了。这篇就整理一套磁盘空间与日志清理的自查思路，帮助把问题提前发现。
一、磁盘空间为什么会悄悄被吃掉
磁盘不会无缘无故满。常见占用来源有几类：
- 应用日志与访问日志：每天都有访客和蜘蛛访问，日志持续追加，如果没有轮转和保留策略，几个月就能占掉大量空间。
- 数据库文件与二进制日志：业务数据增长、慢查询日志、binlog 未及时清理，都会让数据库目录变大。
- 备份文件：本地备份、数据库导出、整站打包，如果只增不减，很快会成为最大占用项。
- 缓存与临时文件：页面缓存、对象缓存、上传临时文件、会话文件，平时不起眼，积压后也很可观。
- 媒体资源：图片、视频、附件不断上传，原图未压缩、旧版本未清理，也会推高占用。
二、先看整体，再看具体目录
自查时不要一上来就删文件。先用命令看清楚现状，再决定处理顺序。
常用查看命令
- df -h：查看各分区使用率和剩余空间，先确认是哪个分区告急。
- du -sh /path/*：按目录统计占用，逐层缩小范围。
- find /path -type f -size +200M：找出大文件，优先检查异常的大日志或大备份。
- ls -lh：查看文件大小和时间，判断哪些是近期快速增长。
找到占用大户后，再区分“可以立即清理”“需要保留但可压缩”“必须迁移到对象存储或外部备份”三类，避免误删仍在使用的数据。
三、日志文件：该留的留，该转的转
日志是排查问题和分析蜘蛛抓取的重要依据，但不能无限保留。比较稳妥的做法是配置日志轮转，按天或按大小切割，并设置保留份数和压缩策略。
正在写入的日志文件不要直接删除。直接删可能出现进程仍持有文件句柄、空间不释放的情况。更合适的做法是通过日志轮转、truncate 或重启对应服务来处理。
对于访问日志和蜘蛛抓取日志，可以保留最近一段时间用于分析 URL 发现、抓取频率和状态码分布，更早的日志压缩归档后转移到其他存储。应用调试日志如果已经不影响排查，保留周期可以更短。
四、备份、缓存与临时文件的保留策略
备份是最后的安全垫，但备份策略需要和磁盘容量匹配。可以按下面的顺序检查：
- 本地是否保留了多份完整备份？如果同一份数据每天打包，却只增不删，需要重新评估保留天数。
- 数据库备份是否包含不必要的旧表、旧日志表？导出前能否排除部分大表？
- 缓存目录是否有过期清理机制？会话文件、缩略图、编译缓存是否设置了生命周期？
- 上传临时文件是否在请求结束后正常清理？异常中断留下的临时文件是否有人处理？
- 旧版本程序包、旧主题、旧插件是否还留在服务器上？确认不再回滚后可以归档移除。
五、把清理变成例行检查
临时清理只能救急，站点运营更需要例行检查。可以设置磁盘使用率监控，在达到阈值时告警，而不是等磁盘 100% 才被动处理。
- 每周或每月查看一次分区使用率变化趋势。
- 确认日志轮转任务、备份清理任务、缓存清理任务是否按计划执行。
- 新增栏目、开放上传或接入新服务后，重新评估磁盘余量。
- 记录一次清理前后的空间变化，便于判断哪些目录增长最快。
六、简单自查清单
- 当前所有分区使用率是否都低于告警阈值？
- 最大的几个目录分别是什么，是否属于预期占用？
- 日志是否有轮转、压缩和保留份数？
- 数据库 binlog、慢查询日志是否设置了清理策略？
- 本地备份保留天数是否明确，旧备份是否自动删除？
- 缓存和临时文件是否有过期清理机制？
- 磁盘告警是否能通知到实际处理的人？
磁盘空间不是一次性任务，而是站点运营里需要持续关注的健康指标。把查看、轮转、清理和告警固定成流程，才能在流量增长或蜘蛛频繁抓取时，不让硬盘先成为瓶颈。