备份路径配置需兼顾权限、环境、安全限制与运维可靠性，核心是确保运行用户对绝对路径有写权限、避开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。
- 在 crontab 文件顶部加两行：
SHELL=/bin/bashPATH=/usr/local/bin:/usr/bin:/bin - 备份命令里所有路径都写绝对路径：
/usr/bin/mysqldump而不是mysqldump - 重定向目标也必须是绝对路径，例如：
/usr/bin/mysqldump mydb > /backup/mydb_$(/bin/date +\%F).sql - 建议加日志：
2>> /backup/backup.log，方便排查权限或连接问题
备份路径要预留空间监控和自动清理机制
备份文件不会自己消失，放任不管几个月后可能占满整个分区。这不是“配置路径”的终点，而是起点。
- 用
df -h /backup检查剩余空间，建议低于 20% 时触发告警 - 自动清理旧备份：
find /backup -name "*.sql" -mtime +7 -delete（保留 7 天），注意-delete有风险，先用-print测试 - 如果备份量大，考虑用
gzip压缩：mysqldump mydb | gzip > /backup/mydb_$(date +\%F).sql.gz，节省 70%+ 空间 - 别忘了验证备份可用性：定期抽样
gunzip -c xxx.sql.gz | head -n 20看是否有 SQL 头部，或用mysqlcheck --check配合导入测试库
secure_file_priv 对 --result-file 的硬性约束。 
