备份路径不能只改 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/bash
PATH=/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有风险，先用
gzip压缩：
mysqldump mydb | gzip > /backup/mydb_$(date +\%F).sql.gz，节省 70%+ 空间 别忘了验证备份可用性：定期抽样
gunzip -c xxx.sql.gz | head -n 20看是否有 SQL 头部，或用
mysqlcheck --check配合导入测试库 备份路径本身很简单，难的是让每次写入都可靠、可追溯、不挤占关键服务资源。最容易被忽略的，其实是 cron 环境变量和
secure_file_priv对
--result-file的硬性约束。
