站点跑了一段时间之后，访问日志、错误日志、缓存文件、备份包会一点点把磁盘吃掉。等到写不进去的时候，表现往往不是“日志报错”，而是数据库连不上、图片上传失败、页面直接报 500，排查时先要绕一大圈。把日志轮转和磁盘空间检查固定成日常动作，能省掉不少这类突发问题。
磁盘写满时，最先出问题的是什么
- 数据库写入失败，会话或缓存无法落盘；
- 上传目录写不进新文件，后台发布内容卡在半路；
- 日志继续追加失败，出错的现场反而看不到；
- 部分中间件直接拒绝请求，外部访问统一报错。
这些现象看起来像程序缺陷，源头却常常在磁盘。所以先判断“是不是空间问题”，能避免在代码里空找原因。
先做几项基础检查
- 分区使用率：用 df -h 看根分区和数据分区，注意数据盘和日志盘是不是分开挂载的。
- inode 使用率：用 df -i 查看。小文件特别多时，空间还有余量但 inode 已经用尽，同样写不进新文件。
- 增长最快的目录：用 du 按层级排序，找出最近明显变大的目录，通常集中在日志、缓存和备份三处。
- 大文件清单：找出单个几 GB 的日志或备份包，这类文件往往是最直接的元凶。
- 日志状态：确认是否在压缩、是否按周期切分，还是所有日志都堆在同一个文件里一直追加。
日志轮转的常见做法
按大小或按天切分
访问量稳定的站点可以按天切分，流量波动大的更适合按大小切分，避免某天生成一个几 GB 的文件。两种方式也可以同时使用：达到指定体积或到了指定时间，任一条件满足就轮转。
保留周期与压缩
保留份数要结合排查习惯来定。近期日志建议保留 7 到 14 天，更早的可以用压缩包形式留存，或者直接归档到别的存储上。压缩后通常能省下大量空间，前提是别把压缩文件和原文件同时留在同一分区。
轮转之后要让服务重新打开文件
日志被移走或改名后，进程如果还握着原来的文件句柄，新日志会继续写进已被删除的文件，看起来像是“日志不见了但空间没释放”。这种情况下需要在轮转完成后触发一次重新打开日志的动作，或者重载对应服务。
别把日志删得太干净
出问题的时候，最近七到十四天的日志往往是最有用的一段。清理之前先确认自己可能要查的时间范围，再决定删到哪一天。
顺手检查其他吃空间的地方
- 本地备份包：是否只保留最近几份，是否和站点数据放在同一块盘；
- Web 服务缓存与临时上传文件：上传被中断时容易留下半截文件；
- 应用缓存和旧版本发布目录：每次发布都留一份，时间长了体量可观；
- 系统层面的临时文件和包管理缓存，也可以定期看一眼。
一个可执行的自查流程
- 记录当前各分区与 inode 的使用率，作为基线，方便之后对比。
- 找出近期增长最快的目录，确认是日志、缓存还是备份造成的。
- 检查日志轮转配置是否真的生效，保留份数和压缩设置是否合理。
- 调整之后观察一个完整周期，确认切分、压缩、重载都正常。
- 给使用率设置阈值提醒，例如到 80% 提示、到 90% 告警。
- 把清理无用备份和临时文件写进维护清单，按固定节奏执行。
小结
日志和磁盘听起来是运维细节，但它直接决定蜘蛛和访客能不能正常拿到页面。把检查做成固定动作，成本远低于事后救火。