备份路径配置不是改 MySQL 配置文件就能生效的
MySQL 本身不提供“自动备份路径”配置项，
my.cnf里的
datadir只控制数据文件存放位置，和备份无关。真正决定备份路径的是你用的备份命令或工具——比如
mysqldump输出到哪、
mysqlpump的
--result-file参数、或者
Percona XtraBackup的
--target-dir。别在
mysqld配置里找 backup_path 这类选项，找不到。
用 mysqldump 定向备份到指定路径的实操要点
最常用也最容易出错的方式是直接调用
mysqldump并重定向输出。关键不是“配”，而是“写对命令”：
mysqldump -u root -p --databases db1 db2 > /backup/full_$(date +\%F).sql：注意路径
/backup/必须存在且 MySQL 运行用户（通常是
mysql）有写权限；否则会报
Permission denied如果加了
--single-transaction或
--lock-tables，要确认当前用户有
RELOAD和
LOCK TABLES权限，否则备份中途失败但文件可能已部分生成，路径里留个残缺文件 避免用绝对路径写进 crontab 却忘了设置
PATH环境变量，导致 cron 找不到
mysqldump，备份静默失败——建议在脚本开头显式声明：
export PATH="/usr/bin:/bin"
自动备份脚本里必须检查的三件事
哪怕只跑一次
mysqldump，也要确保：
/backup/目录磁盘空间足够：用
df -h /backup看，别等备份写到一半报
No space left on device备份文件名带时间戳且不覆盖：用
$(date +\%Y\%m\%d_\%H\%M)而非固定名，否则每天覆盖，真出事时只剩最新一份 备份后验证基础可用性：加一行
head -n 20 /backup/full_*.sql | grep -q "CREATE DATABASE" && echo "backup OK"，至少确认文件没空、SQL 头部正常
权限与安全容易被忽略的硬约束
MySQL 备份路径的安全性不只看“能不能写”，更要看“谁能看到、谁能删”：
不要把备份放在/var/www/或 web 可访问目录下，否则
http://yoursite.com/backup/full_20240501.sql可能直接暴露全量数据 备份文件属主设为
root:root，权限设为
600（
chmod 600 /backup/*.sql），防止其他普通用户读取 如果用
mysqldump的
--defaults-extra-file存密码，该文件权限也必须是
600，且不能放在家目录外——否则 MySQL 启动时可能因权限问题拒绝读取
路径本身只是个字符串，真正卡住备份成败的，永远是权限、空间、环境变量这三样。写完脚本先手动跑一遍，再扔进 crontab。
