mysqldump备份失败主因是权限或连接配置不当，应使用~/.my.cnf（chmod 600）、限定最小权限、排除系统库；crontab需指定全路径和PATH；备份后gzip压缩并定期清理旧文件。
mysqldump 命令备份失败：权限不足或连接被拒
直接执行 mysqldump 报错 access denied for user 或 can't connect to local mysql server，本质是脚本运行身份没权限访问数据库，不是 mysql 本身坏了。
实操建议：
- 别用 root 用户写明文密码到命令行（会被
ps看见），改用配置文件~/.my.cnf，并设权限chmod 600 ~/.my.cnf -
.my.cnf内容必须包含[client]段，且不能有多余空格或 BOM 头，否则mysqldump会静默忽略 - 如果备份用户是专门建的（推荐），只给
SELECT+LOCK TABLES权限，别给FILE——除非真要导出到服务端磁盘 - 远程备份？加
-h参数，但确认 MySQL 允许该 IP 连接（host字段在mysql.user表里）
crontab 定时任务不执行：环境变量和路径陷阱
cron 启动的 shell 是极简环境，PATH 不含 /usr/local/mysql/bin，也找不到你家目录下的 .bashrc，所以 mysqldump: command not found 很常见。
实操建议：
- 在 crontab 里显式写全路径：
/usr/bin/mysqldump（用which mysqldump确认） - 加一行
SHELL=/bin/bash和PATH=/usr/local/bin:/usr/bin:/bin到 crontab 开头 - 所有重定向输出加绝对路径，比如
> /backup/mysql_$(date +\%F).sql，别用~/backup/ - 加日志重定向：
2>> /var/log/mysql-backup.log，否则失败了你也看不到报错
备份文件越来越大：如何跳过日志库和临时表
默认 mysqldump --all-databases 会把 information_schema、performance_schema、sys 全 dump 出来，不仅浪费空间，恢复时还可能报错。
实操建议：
- 用
mysql -Nse "SHOW DATABASES LIKE 'your_app_%'"动态生成库名列表，避免硬编码 - 排除系统库：加参数
--ignore-database=information_schema --ignore-database=performance_schema --ignore-database=sys - 跳过某些大表（如日志表）：
--ignore-table=app_db.log_events，注意格式是db_name.table_name - 加
--single-transaction（InnoDB 专用），比--lock-all-tables影响小得多，但别在 MyISAM 上用——会失效
压缩与保留策略：防止磁盘被撑爆
纯 SQL 文件体积大，长期不清理，/backup 分区某天就 100%，接着 MySQL 写 binlog 都失败。
实操建议：
- dump 后立刻用
gzip压缩：mysqldump ... | gzip > backup_$(date +\%F).sql.gz - 用
find /backup -name "*.sql.gz" -mtime +7 -delete清理 7 天前的，放进 cron 脚本末尾 - 别用
rm -rf /backup/*这种粗暴方式——万一路径写错，整个目录没了 - 如果启用了 MySQL 的
binlog，记得定期PURGE BINARY LOGS，它和备份文件是两回事，但都吃磁盘
真正麻烦的是跨机房同步备份和加密传输，那些得配 SSH key、rsync 排除、gpg 加密，一动就是权限链和信任链问题——先确保本地定时能稳跑一周再说。
