mysql备份文件应存于独立挂载点如/backup/mysql/，确保隔离性与可访问性；须避开datadir、/tmp、/root等危险路径；需显式指定绝对路径并确认权限；--tab参数路径须符合secure_file_priv限制；本地压缩校验后再上传云存储；须配置定期清理策略。
MySQL 备份文件该放在哪里？优先考虑隔离性与可访问性
备份文件不能和 MySQL 数据目录（/var/lib/mysql）放一起，否则磁盘损坏或误删 datadir 时备份一并丢失。理想位置需满足：独立挂载点、定期校验可达、非 root 用户可写（避免用 sudo mysqldump 直接写入系统目录）。
常见可行路径包括：
-
/backup/mysql/（推荐：单独挂载的硬盘或 LVM 卷） -
/mnt/nas/backups/mysql/（NAS 或远程挂载，需确保 umask 和用户权限兼容） -
/home/backupuser/mysql/（普通用户主目录下，适合测试环境）
避免使用 /tmp、/var/tmp 或 /root —— 这些位置可能被自动清理、权限受限或不可跨重启保留。
mysqldump 输出路径受 shell 权限限制，不是 MySQL 配置项
mysqldump 本身不决定存储位置，它只是把 SQL 写到 stdout 或你指定的文件路径。最终落盘位置由执行命令的用户权限和目标路径的写入权限决定。
典型错误操作：
- 用
sudo mysqldump ... > /var/log/mysql/backup.sql——/var/log通常仅允许 root 写，且日志目录不适合存大体积备份 - 直接写到
/etc/mysql/下 —— 该目录只读或无写权限，会报错bash: /etc/mysql/backup.sql: Permission denied - 用相对路径如
mysqldump db1 > backup.sql—— 当前工作目录不确定，易遗漏或覆盖
正确做法是显式指定绝对路径，并确认目标目录存在且可写：
mkdir -p /backup/mysql/<br>chown backupuser:backupuser /backup/mysql/<br>mysqldump -u user -p db1 > /backup/mysql/db1_$(date +\%F).sql
使用 --tab 参数时，-T 路径必须是 MySQL 服务端可写目录
mysqldump --tab 会生成 .sql（建表语句）和 .txt（数据）两个文件，其中 .txt 是由 MySQL server 进程直接写入的，因此 -T 指定的路径必须满足：
- 在 MySQL 配置中被
secure_file_priv白名单允许（查看用SELECT @@secure_file_priv;） - MySQL 进程用户（通常是
mysql）对该目录有写权限 - 不能是符号链接（部分版本会拒绝）
例如：
mysqldump --tab=/var/lib/mysql-files/ -u user -p db1是安全的；而
--tab=/backup/mysql/ 很可能失败，除非你已修改 secure_file_priv 并重载配置。
云存储或远程归档前，先本地压缩再传输
直接 mysqldump | gzip | ssh user@host 'cat > backup.sql.gz' 看似简洁，但一旦网络中断，备份就残缺且难以恢复。更稳妥的做法是分两步：
- 先落地为完整文件：
mysqldump db1 | gzip > /backup/mysql/db1_$(date +\%F).sql.gz - 再校验并上传：
gunzip -t /backup/mysql/db1_$(date +\%F).sql.gz && aws s3 cp ...
注意：gzip 压缩后文件名务必带 .gz 后缀，否则后续脚本或定时任务可能误判为未压缩文件；同时，date +\%F 中的 \% 需转义，否则会被 shell 解析错误。
真正容易被忽略的是备份文件的生命周期管理——没有定期清理策略的 /backup/mysql/ 几个月后就会占满磁盘，而 find /backup/mysql -name "*.sql.gz" -mtime +7 -delete 这类命令，必须在 crontab 中明确指定 PATH 和工作目录，否则可能静默失效。
