那天晚上我对着 du 的输出愣了一会儿。客户在群里甩来一句「磁盘爆了，帮我查查是不是被日志占用了」，后面跟上那句每次都会出现的「注意有数据，别给我删了」。

我把日志目录 /www/wwwlogs 整个加起来算了一遍——8.3M。

不是 830M，是 8.3M。磁盘已经 97% 了。

那阵子我习惯把客户机都接进七亿批量远程管理工具，一台宝塔面板的 Discuz 论坛服务器也在列表里，MySQL 5.7.44、nginx、php-fpm 85，都是面板默认那套。SSH 终端连上去，先按着最顺手的思路走：盘满 → 多半是日志 → 清日志。这条路上全是经验，可经验这东西最容易骗人，它给你的是「最常见的那个原因」，不是「这台机器上的那个原因」。

所以读了那 8.3M 之后，我没接着收拾日志，改去把「谁大」这件事摊开看。du 按大小排一遍，再 find 捞一下超过 100M 的文件，四个大户就露头了：

  • MySQL 的 binlog，大概 5.8G。my.cnf 里明明写了 expire_logs_days=10，但那段日子写入量不对，一天能涨快 7G，配的过期天数根本追不上。
  • 宝塔自己的站点备份包，一个 tar.gz 就有 6.1G，躺在备份目录里没人动。
  • 客户 admin 目录下手工分的卷，www.part01 到 part09 的 rar，加起来 6.3G。
  • 一个 1.4G 的错误日志，名字叫 microsof-aabadd.err，Windows 版 MySQL 留下的老物件，尾巴停在 2026-09-25 的一次 Shutdown，之后压根没再写过一行。

真正「活着的日志」，反倒是那 8.3M。

清那个 1.4G 的 err 之前，我照老习惯做了三个动作：lsof 看有没有进程还攥着它（没有）；确认它不是当前在写的 error log（末尾时间是 9/25，机器后来没产生过新日志）；最后 tail -n 500 把尾巴存成一份 .tail500 留痕，再用 : > 清空。直接 rm 也不是不行，但留痕这习惯救过我好几次——真出了事，至少能说清原来里面是什么。

一轮下来，磁盘从 97% 掉到 82%，释放大概 7G（binlog 和那个老 err 是大头）。

没清干净，也不适合一次清干净。binlog 没有过期策略还会再涨；剩下那 12G 多的备份——客户手工分的卷、宝塔的备份包——我没敢替人家做主删。这些不是垃圾，是人家自己留的退路。我只把位置和大小列了个清单发过去，删不删让他们定。

所以客户那句「别给我删了」其实帮了大忙，它一直提醒我：我面对的不是一堆文件，是别人留着的底牌。

以前我也问过自己，为什么每次盘满，大家第一反应都是日志。大概是日志最常见，也大概是清日志看着最「安全」——反正日志嘛，删了就删了。但「最安全」和「最占地」是两码事。真正占地方的，往往是备份、binlog 这种「有用所以一直留着」的东西。凭感觉清，很容易清了个寂寞，盘该满还是满。

后来我给自己定了条死规矩：盘满，先 du 排序看前几名，谁大动谁，日志排第几就第几。这台机器，日志排在末尾。

前一天刚写过这台机器挂载掉盘那次，也是「看着像 A，查完是 B」的路子。同一台机器连着两晚找我，一篇写挂载、一篇写占盘，也算凑齐了。

回头看，那天最省事的一步反而是最危险的一步。要是我真顺着「日志占的」去清日志，清完一看盘还是 97%，再回头找原因，那才叫白折腾。