宝塔自动备份失败主因是cron未触发、磁盘空间不足或权限链中断；需查/www/wwwlogs/cron.log确认任务执行情况，用df -h /www和du -sh /www/backup/database/*定位空间问题，逐级检查/www、/www/backup、/www/backup/database目录权限及属主，并注意SELinux拦截。
宝塔自动备份失败，八成不是脚本问题，而是 cron 没跑起来、磁盘满了、或权限卡在中间某一层。直接看面板上的“失败”提示没用，得去服务器里挖真实线索。
查 cron.log 才知道任务到底有没有执行
宝塔的计划任务底层就是 Linux 的 cron，但它的日志不走系统默认的 /var/log/cron，而是写进自己的 /www/wwwlogs/cron.log。面板上显示“备份完成”或“失败”，可能只是 cron 启动了进程，但 mysqldump 一执行就退出了——这个过程只会记在这里。
- 运行
tail -n 50 /www/wwwlogs/cron.log，重点找含backup.py或mysqldump的行 - 如果完全没相关记录，说明 cron 根本没触发：检查
crontab -l -u www（面板任务默认用 www 用户）是否真有这条定时规则 - 如果看到
Permission denied，别急着改备份目录权限——先看报错路径是不是/www/backup这一级，父目录没写权限也会导致子目录创建失败 - 若日志里出现
command not found: mysqldump，说明宝塔找不到命令，不是 PATH 问题（新版已硬编码路径），而是 mysqldump 二进制文件被移走或重命名了
用 df -h 和 du -sh 配合看磁盘到底卡在哪
“磁盘已满”是宝塔备份失败最常被误判的原因。df -h 显示根分区 98%，不代表备份就一定失败——关键要看 /www 所在挂载点，以及备份目标目录本身的可用空间。
- 先跑
df -h /www，确认/www分区使用率；如果它挂在/dev/vda1上，而df -h显示的是/dev/vdb1满了，那跟备份无关 - 再跑
du -sh /www/backup/database/* 2>/dev/null | sort -hr | head -5，看是不是旧备份堆满目录；注意宝塔“保留天数”只清理自己生成的文件名（如mysql_20240520_120000.sql.gz），手动丢进去的不会动 - 别漏掉
/www/Recycle_bin/：回收站清空后文件还在磁盘上，rm -rf /www/Recycle_bin/*是最直接的清理方式 - 如果
df -h正常但备份仍中断，可能是mysqldump写临时文件时被系统 kill——这时候dmesg | tail里常能看到Out of memory: Kill process或No space left on device
权限问题往往卡在 www 用户写不了 /www/backup/database
目录存在 ≠ 能写。宝塔备份脚本以 www 用户身份运行，哪怕你给 /www/backup/database 设了 777，只要它的父目录（比如 /www/backup）属主是 root:root 且权限是 755，www 也无法在其中创建子目录或文件。
- 逐级检查：
ls -ld /www /www/backup /www/backup/database，确保每一级对www用户都有执行（x）权限（即目录可进入） - 修复命令：如果
/www/backup属主是 root，运行chown -R www:www /www/backup；如果只想改权限，用chmod 755 /www/backup - 临时验证：执行
sudo -u www touch /www/backup/database/test.txt，失败就说明权限链断在某一层 - SELinux 开启时（CentOS 7/8 默认），即使权限全对也会静默拒绝——临时关掉测试：
setenforce 0，再试一次备份
真正卡住的地方，往往不在备份脚本本身，而在 cron 是否启动、磁盘哪一层满了、或者 www 用户能不能穿过层层目录走到最终落点。三者缺一不可，少查一个，就会反复踩同一个坑。
