告别手动清理！彻底解决宝塔面板硬盘频繁被日志撑爆的问题

前言

使用宝塔面板管理 Linux 服务器的站长，大概率都遇到过这个尴尬的问题：服务器运行一段时间后，磁盘空间突然 100% 爆满，导致 MySQL 数据库停止服务甚至站点瘫痪。

上去一查，发现大多是各类访问日志（Access Log）、错误日志（Error Log）、数据库二进制日志（Binlog）把空间吃光了。虽然宝塔面板提供了“清理日志”工具，但每次都要人工上去点一下，治标不治本。

本文将分享一套一劳永逸的自动化日志治理方案，只需一次性配置，就能彻底解决日志撑爆硬盘的烦恼。

解决方案

一、开启宝塔【日志切割】计划任务（最核心）

宝塔面板本身具备日志自动切割与定期清理的功能，但默认可能没有开启或配置合理的保留周期。

1. 配置网站日志切割

登录宝塔面板，进入左侧 【计划任务】。
添加任务：
- 任务类型：选择 【日志切割】
- 切割网站：选择 【所有网站】
- 执行周期：选择 【每天】（建议设在凌晨访问低峰期，如 00:30 或 03:00）
- 保留最新：设置为 3 至 7 份（仅保留最近 3-7 天的日志，超期的自动删除）
点击 【添加任务】。

2. 配置系统垃圾清理

在 【计划任务】 中，将任务类型选择为 【清理系统垃圾】。
执行周期 设为 【每周一次】 并保存。

二、限制与清理 MySQL Binlog 日志（隐形空间大户）

如果你的网站开启了 MySQL 的 Binlog（用于主从同步或数据恢复的二进制日志），且未设置自动过期时间，这些文件会默默吃掉几十甚至上百 GB 的空间。

1. 设置自动过期保留时间

进入宝塔面板 -> 【软件商店】 -> 打开 MySQL 设置。
点击 【配置修改】，查找并修改以下参数：
- MySQL 5.7 及以下：查找 expire_logs_days，设置为 expire_logs_days = 7（保留 7 天）。
- MySQL 8.0 及以上：查找 binlog_expire_logs_seconds，设置为 binlog_expire_logs_seconds = 604800（604800 秒 = 7 天）。
保存并重启 MySQL 服务。

2. 手动清理历史积压的 Binlog

如果当前已经产生了大量 mysql-bin.0000x 文件，可以登录 MySQL 终端执行以下 SQL 快速释放空间：

SQL

-- 清理 7 天前的二进制日志
PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;

三、限制 Linux 系统日志（journalctl）体积

Linux 系统自带的 systemd-journald 服务也会不断积累日志（存储在 /var/log/journal/），默认往往没有严格的空间上限。

可以直接通过终端执行以下命令限制其最大体积：

Bash

# 1. 立即清理系统日志，仅保留最近 500M
journalctl --vacuum-size=500M

# 2. 修改配置文件，永久限制系统日志最大占用 500M
sed -i 's/#SystemMaxUse=/SystemMaxUse=500M/' /etc/systemd/journald.conf

# 3. 重启日志服务使配置生效
systemctl restart systemd-journald

四、优化本地备份文件的保存策略

除了日志之外，本地备份文件积压也是导致硬盘爆满的另一大原因。

检查保留份数：在宝塔 【计划任务】 中检查【备份网站】和【备份数据库】任务，建议保留份数设为 3~5 份。
迁移至云存储（推荐）：
- 在宝塔【软件商店】安装免费的云存储插件（如 七牛云 Kodo、腾讯云 COS 或 阿里云 OSS）。
- 将备份目标修改为云存储桶，本地保留份数设为 0 或 1，既保障了数据安全，又彻底释放了本地磁盘。

附：常用 Linux 磁盘空间排查命令

当服务器再次提示磁盘空间不足时，可以使用以下命令快速精准定位“罪魁祸首”：

Bash

# 1. 查看各大挂载分区的总体占用情况
df -h

# 2. 查看根目录下各个文件夹的大小（定位哪个目录占用最大）
du -sh /* 2>/dev/null | sort -hr | head -n 10

# 3. 快速排查宝塔日志目录体积（最常见占用点）
du -sh /www/wwwlogs