先确认crond服务是否运行且宝塔crontab条目生效，再验证Python环境、备份脚本、磁盘空间及/www/backup/database各级目录权限与SELinux状态。
备份目录存在但没生成任何 .sql.gz 文件：先确认 cron 是否真执行了
宝塔界面上“任务已添加”不等于它被系统调度过。很多情况下，crond 服务停了、或宝塔写入的 crontab 条目根本没生效，任务就一直躺在那里不动。
实操建议：
- 运行
systemctl status crond，确保状态是 active (running)；若为 inactive，执行systemctl start crond并设开机自启 - 执行
crontab -l，查找含/www/server/panel/class/backup.py或database关键词的行，确认宝塔确实写了定时规则 - 复制该整行命令（如
0 3 * * * /www/server/panel/pyenv/bin/python /www/server/panel/class/backup.py database mysql_abc），去掉前面时间部分，直接在终端运行——看是否立即生成文件、有无报错
mysqldump 命令找不到或权限拒绝：检查 PATH 和 Python 环境
宝塔 5.9+ 使用独立 Python 环境执行备份脚本，一旦 /www/server/panel/pyenv/bin/python 损坏、无执行权，或 backup.py 被意外清空，整个流程会静默退出，连日志都不留。
实操建议：
- 运行
ls -l /www/server/panel/pyenv/bin/python，确认输出中有-rwxr-xr-x权限位；若为----------或提示 Permission denied，执行chmod +x /www/server/panel/pyenv/bin/python - 运行
/www/server/panel/pyenv/bin/python --version，应能正常打印版本号；失败则说明 pyenv 损坏，需重装面板或手动修复 - 运行
head -n 3 /www/server/panel/class/backup.py，前几行应是合法 Python 代码（如#!/usr/bin/env python或import）；若为空或乱码，备份脚本已被破坏
磁盘空间足够但备份中断：df -h 和 du -sh 必须一起看
常见假象是 df -h /www 显示还有 10% 空间，但实际备份时仍失败——因为 mysqldump 会先写临时未压缩的 .sql 文件，体积通常是最终 .gz 的 3–5 倍。若磁盘只剩 2GB，而数据库导出原始 SQL 需 8GB，就会卡在中间并静默退出。
实操建议：
- 执行
df -h /www，剩余空间必须 ≥ 待备份数据库原始大小 × 2（保守起见） - 执行
du -sh /www/backup/database/*，确认旧备份没堆积；宝塔“保留天数”只清理自己生成的文件，手动丢进去的不会动 - 临时测试：用
sudo -u www dd if=/dev/zero of=/www/backup/database/test.img bs=1M count=500模拟写入 500MB，看是否成功；失败则不是空间问题，而是权限或 SELinux 拦截
目录权限看着对，但就是写不进：父目录权限和 SELinux 是隐形杀手
/www/backup/database 属主是 www:www、权限 755，不代表就能写——如果它的父目录 /www/backup 属主是 root:root 且权限是 700，www 用户连进入都做不到，更别说创建子目录或文件。
实操建议：
- 逐级检查：
ls -ld /www /www/backup /www/backup/database，确保每一级对www用户都有x（执行/进入）权限 - 若用的是 CentOS 7/8，运行
getenforce，返回Enforcing就代表 SELinux 开着；临时关掉验证：setenforce 0，再手动触发一次备份，成功则需配置 SELinux 策略而非永久关闭 - 注意：宝塔备份脚本可能调用
gzip，若系统没装或不在 PATH 中，也会导致生成.sql但不压缩；运行which gzip确认路径存在
真正卡住的地方，往往不在数据库本身，而在 /www/backup 这一层目录树的访问链路上——从根目录到目标文件夹，每一步的属主、权限、SELinux 上下文、挂载选项，缺一不可。
