磁盘满自动清理日志定时任务宝塔部署指南

磁盘满最常见的元凶就是日志文件，尤其是 Nginx、PHP 和 MySQL 日志会随着时间不断膨胀，直到占满 / 分区。
解决思路很简单：写一个清理脚本，再用宝塔面板的定时任务按周期执行，让日志体积始终可控。
本文就带你在宝塔面板中完成这个部署，整个过程不需要编写复杂代码，照着操作即可。

哪些日志最容易撑爆磁盘

在部署之前，先确认你的服务器上有哪些日志在持续增长。
登录宝塔后台，打开「文件」页面，依次查看以下目录：

• /www/wwwlogs：Nginx 或 Apache 访问日志、错误日志，通常单个文件可达几 GB。
• /www/wwwroot/站点目录/runtime：PHP 程序生成的运行日志，如 ThinkPHP、Laravel 框架日志。
• /www/server/mysql/var：MySQL 慢查询日志、错误日志。
• /var/log：系统日志，如 syslog、messages。

你可以先用 df -h 查看磁盘使用率，再用 du -sh /www/wwwlogs 这类命令定位大目录。
确认是日志过大后，再进入下一步。

部署清理脚本：一个命令搞定旧日志

这里采用“只清空、不删除”的策略：保留日志文件本身，避免 Nginx 找不到文件而报错，同时把内容截断为 0 字节。
写入一个简单的清理脚本，路径建议放在 /www/clean_logs.sh。

在宝塔文件管理中创建该文件，内容如下：

#!/bin/bash
# 清理 7 天前没有修改过的日志文件，保留空文件
find /www/wwwlogs -name "*.log" -mtime +7 -exec truncate -s 0 {} \;
find /www/wwwroot -path "*/runtime/*.log" -mtime +7 -exec truncate -s 0 {} \;
# 也可以按大小清理：删除超过 500M 的日志（慎用）
find /www/wwwlogs -name "*.log" -size +500M -exec truncate -s 0 {} \;

保存后，在文件管理器中右键该文件，点击「权限」，设置为 0755，确保脚本可执行。
如果你想保留更长周期，把 +7 改成 +30；
如果想保留最近 3 天，就改成 +3。

在宝塔创建定时任务并绑定脚本

脚本准备好后，进入宝塔后台左侧菜单「计划任务」，选择「Shell脚本」，任务名称可填“自动清理日志”。
执行周期根据日志增长速度决定，一般选择“每天”或“N天”，推荐每天凌晨 2 点执行一次。

在脚本内容框中直接填写：

bash /www/clean_logs.sh

填写完成后点击「添加任务」。
宝塔会生成一条 crontab 记录，你可以在系统终端用 crontab -l 查看，确认任务已经写入。

任务添加后，不要急着等明天，先手动“执行”一次验证流程。
在计划任务列表右侧点击「执行」按钮，然后观察下方执行日志，出现 success 或没有任何报错即代表脚本运行正常。

避坑要点：这些错误新手最容易踩

清理日志虽然简单，但有几个坑会让任务失效甚至影响网站：

• 绝对不要删除日志文件，只截断内容。rm -f /www/wwwlogs/access.log 后，Nginx 依然持有旧文件句柄，磁盘空间不会释放，还会导致日志无法写入。使用 truncate -s 0 才能原地清空。
• 路径写错导致任务白跑。检查脚本里的目录是否存在，宝塔的站点路径不一定都是 /www/wwwroot，如果用了自定义目录，要改为实际路径。
• 权限不足导致 truncate 失败。如果脚本以 root 执行，通常没问题；但如果你用了普通用户执行，需要确保该用户对日志目录有写权限。
• 清理 systemd journal 日志。如果你的服务器使用 journald，并且 /var/log/journal 越来越大，可以用 journalctl --vacuum-time=7d 清理 7 天前的日志，这条命令可单独加进脚本。

如果你拿到服务器后担心之前的日志已经很大，可以先手动执行一次脚本，再用 df -h 对比清理前后的磁盘占用。

验证清理效果：三步确认任务生效

任务部署后，建议连续观察几天，重点确认三件事：

1. 磁盘占用是否下降：执行 df -h，查看 / 的 Use% 是否出现明显回落。
2. 日志文件是否被截断：执行 ls -lh /www/wwwlogs/，看到文件大小为 0 或远小于之前，说明清理成功。
3. 定时任务是否按时执行：在宝塔计划任务中查看执行日志，或者用 crontab -l 确认记录仍在。

另外，如果网站近期出现上传图片失败、后台登录缓慢等问题，优先考虑磁盘满是否已经引发 MySQL 或 PHP 无法写入缓存。
部署本次清理任务后，这类问题会明显减少。
如果日志增长极快，说明站点访问量异常或程序在疯狂写错误日志，需要进一步排查具体来源，而不是只依赖定时清理。

整个流程跑通后，磁盘空间就多了一道自动防线。
后续只要定期检查脚本有没有被误删、任务有没有停止即可。
如果你在部署过程中遇到“找不到文件”“执行失败”等问题，回到宝塔计划任务的执行日志里查看具体报错，通常都是路径或权限原因，按照上文避坑点逐项核对就能解决。