备份路径配置需兼顾权限、环境、安全限制与运维可靠性，核心是确保运行用户对绝对路径有写权限、避开MySQL数据目录分区、适配secure_file_priv限制、规范crontab环境变量，并建立空间监控与自动清理机制。
备份路径不能只改 mysqldump 命令里的输出文件位置
很多人以为在执行 mysqldump 时指定 /backup/db.sql 就算配置好了备份路径，其实这只是客户端写入路径，和 MySQL 服务端无关。真正需要配置的，是备份脚本运行时的**工作环境权限、磁盘空间归属、以及定时任务上下文中的路径解析逻辑**。
- Linux 下必须确保运行备份命令的用户（如
mysql或root）对目标目录有write权限 - 路径建议用绝对路径，避免 crontab 执行时因
$HOME或$PWD不一致导致写入失败 - 不要把备份存到
/var/lib/mysql同一分区——万一磁盘满，MySQL 进程可能直接挂掉 - 如果用 LVM 快照或 xtrabackup，还需额外配置临时快照挂载点，那才是真正的“备份路径准备”
用 mysqldump 备份时，路径相关的常见错误
最典型的报错是：mysqldump: Got error: 1045: Access denied for user 或更隐蔽的 bash: /backup/db.sql: Permission denied。后者根本不是 MySQL 错误，而是 shell 写文件失败。
-
mysqldump -u root -p mydb > /backup/mydb_$(date +\%F).sql—— 如果/backup不存在或不可写，命令会静默失败（重定向失败但mysqldump本身仍返回 0） - 使用
--result-file参数时，该路径由 MySQL 服务端进程解析，必须是 MySQL 用户（如mysql用户）可写的本地路径，且不能是网络路径或符号链接（取决于secure_file_priv设置） - 检查当前限制：
SELECT @@secure_file_priv;，若返回/var/lib/mysql-files/，那--result-file只能写到这个目录下
crontab 定时备份必须显式声明 SHELL 和 PATH
很多备份脚本在终端能跑通，放进 crontab 就失败，90% 是因为 cron 使用最小化环境，PATH 不含 /usr/bin 或 /bin，找不到 mysqldump 或 date。
