备份失败时应先手动执行mysqldump命令排查：检查命令是否存在、用户权限（SELECT/LOCK TABLES/SHOW VIEW/TRIGGER）、备份目录空间与写入权限、SELinux状态、MySQL配置（max_allowed_packet、timeout等），并查看task.py.log日志定位真实错误。
备份失败时先看 mysqldump 是否能手动执行
宝塔后台显示“数据库备份失败”，但没给具体错误，大概率是底层 mysqldump 命令根本没跑起来。直接登录服务器，用宝塔所用的 MySQL 用户（通常是 root 或 btmysql）手动试一下：
mysqldump -u root -p --single-transaction --routines --triggers 数据库名 > /tmp/test.sql- 如果提示
command not found，说明系统 PATH 里没包含mysqldump路径，宝塔找不到它（常见于 MySQL 二进制安装或自定义路径） - 如果报
Access denied for user，说明宝塔用的账号没权限——注意：不是 phpMyAdmin 里的权限，而是 MySQL 系统层面对DUMP操作的权限（SELECT,LOCK TABLES,SHOW VIEW,TRIGGER都要开）
检查 /www/backup/database/ 目录空间与写入权限
宝塔默认把备份存到 /www/backup/database/，这里卡住比想象中更频繁：
- 用
df -h /www看磁盘是否已满（尤其小内存 VPS 容易被日志或旧备份塞爆） - 用
ls -ld /www/backup/database/确认目录属主是www，且权限至少为755；若属主是root，www用户无法写入 - 若启用了 SELinux（如 CentOS 7/8），即使权限对，也会静默拒绝写入，临时验证可运行
setenforce 0，再试备份
MySQL 配置限制导致 mysqldump 中断
有些 MySQL 配置会直接让 mysqldump 失败，且错误不回传给宝塔界面：
-
max_allowed_packet太小（如设为 1M），遇到大表或含长文本字段的表会直接断连，建议调到64M或更高 -
wait_timeout或interactive_timeout过短（如 60 秒），备份中途连接被服务端主动关闭，表现为“备份文件为空”或“只导出了一半表” - 确认
skip-networking没开启——虽然本地 socket 可用，但某些宝塔版本仍会尝试走 TCP，导致连接拒绝
宝塔任务日志里藏了真实错误原因
别只盯着面板上的红字，真正的线索在任务日志里：
- 打开
/www/server/panel/logs/task.py.log，搜索最近时间戳附近的mysqldump行 - 常看到类似
mysqldump: Got error: 2013: Lost connection to MySQL server during query，这就指向上面提到的超时或 packet 设置 - 如果日志里有
Permission denied但备份目录权限看着没问题，很可能是父目录（如/www/backup/）权限不足，导致子目录创建失败
备份失败从来不是单一原因，磁盘、权限、MySQL 配置、SELinux、PATH、用户权限，任何一环松动都可能让 mysqldump 默默退出。最稳妥的方式是按顺序手动复现每一步，而不是依赖宝塔界面上那句模糊的“失败”。
