宝塔面板磁盘占满的真正元凶是未轮转的日志文件：/www/wwwlogs/、/www/server/panel/logs/、/www/server/nginx/logs/及mysql binlog；需用logrotate自动切割并手动清理历史日志。
宝塔面板磁盘占满的真正元凶是哪些日志文件
90% 的磁盘爆满不是因为网站文件，而是宝塔自身和 Nginx/Apache/MySQL 产生的日志长期堆积。最典型的几个路径：/www/wwwlogs/（站点访问日志）、/www/server/panel/logs/（面板运行日志）、/www/server/nginx/logs/（Nginx 错误日志）、/www/server/data/ 下的 MySQL binlog（如果开启）。
这些日志默认不自动轮转或删除，尤其 wwwlogs 里每个站点每天生成一个 xxx.log 和 xxx.error.log，几个月下来轻松吃掉几十 GB。
常见错误现象：df -h 显示 /www 分区使用率 98%，但 du -sh /www/* 加起来远小于该值——说明有被删除但未释放空间的大文件（典型就是正在写入、但被 rm 掉的日志），此时需查 lsof +L1 或重启对应服务。
用 logrotate 实现 Nginx 和宝塔日志的自动切割与清理
宝塔自带的「日志切割」功能（在网站设置 → 日志管理）只对单个站点生效，且依赖面板定时任务，一旦面板卡死或 cron 异常就失效。更可靠的是直接配置系统级 logrotate。
实操建议：
- 编辑
/etc/logrotate.d/bt-nginx，内容如下：
/www/wwwlogs/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 644 www www
sharedscripts
postrotate
[ -f /www/server/nginx/logs/nginx.pid ] && kill -USR1 `cat /www/server/nginx/logs/nginx.pid`
endscript
}
-
rotate 30表示保留最近 30 天的压缩日志，可根据磁盘大小调低（如 7） -
postrotate中的kill -USR1是关键：通知 Nginx 重新打开新日志文件，避免服务中断 - 同理，为宝塔面板日志建
/etc/logrotate.d/bt-panel，监控路径设为/www/server/panel/logs/*.log - 别忘了执行
logrotate -f /etc/logrotate.d/bt-nginx手动触发一次，验证是否生成.1.gz文件
清理已积累的无用日志和缓存文件
自动切割只管未来，历史垃圾得手动清。注意：别直接 rm -rf /www/wwwlogs/*，可能删掉正在写的日志（导致磁盘不释放）。
安全清理步骤：
- 先停掉写日志的服务：
bt stop（停面板）、service nginx stop（或systemctl stop nginx） - 再清理：
find /www/wwwlogs/ -name "*.log" -mtime +90 -delete（删 90 天前的原始日志） - 清理宝塔临时缓存：
rm -f /www/server/panel/cache/* /www/server/panel/tmp/* - 检查 MySQL binlog：
mysql -uroot -p -e "show binary logs;"，若不需要主从，进my.cnf注释掉log-bin并执行reset master; - 最后
service nginx start && bt start，再确认日志是否正常写入新文件
面板内置清理工具为什么经常失效
宝塔「系统监控 → 磁盘清理」里的「清理日志」按钮，本质是调用 rm -f /www/wwwlogs/*.log，但它不判断文件是否被进程占用，也不做轮转，容易导致：
- Nginx 继续往已被删的 inode 写数据，磁盘空间不释放
- 清理后没 reload，新日志仍写入旧路径（因文件描述符未关闭）
- 面板自身日志（如
panelBoot.pl）不在清理范围内，长期运行会撑大/www/server/panel/logs/
所以不要依赖这个按钮。真正可靠的方案是：关服务 → 清老日志 → 开服务 → 配好 logrotate 定时跑。
最容易被忽略的一点：宝塔升级后，/etc/logrotate.d/ 下的自定义配置不会被覆盖，但面板自身的 cron 任务（如「每日清理」）可能被重置，记得检查 crontab -l | grep bt 是否还存在你配的 logrotate 调度项。
