Linux如何配置数据库自动备份_Linux数据库自动备份配置实践-LINUX-PHP中文网

最轻量可控的mysql自动备份方案是mysqldump+crontab；密码须存于~/.my.cnf（权限600）；必加--single-transaction、--routines、--triggers、--events；crontab需用绝对路径、指定shell、重定向日志；备份文件名用%f_%h%m，压缩并软链latest，配合find自动清理。

linux如何配置数据库自动备份_linux数据库自动备份配置实践

直接说结论：用 mysqldump + crontab 是最轻量、最可控、最易排查的 MySQL 自动备份方案，别一上来就堆 Docker 或第三方工具。

为什么不能把密码写在 `mysqldump` 命令里

明文密码出现在命令行中，会直接暴露在 ps aux 和 shell 历史里，还可能被 /var/log/audit/ 记录。更危险的是，crontab 执行时环境变量不全，-p'xxx' 这种写法在定时任务里大概率报错或静默失败。

正确做法是创建 ~/.my.cnf（权限必须设为 600）：

[client]
user = backup_user
password = YourStr0ngP@ss!

然后在脚本里直接调用 mysqldump my_database > backup.sql，不用带任何认证参数。

如果用 root，建议新建专用用户并限制权限：

CREATE USER 'backup_user'@'localhost';
GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER, EVENT ON my_database.* TO 'backup_user'@'localhost';

`mysqldump` 必加的四个关键参数

默认导出不保证一致性，尤其在业务写入频繁时，容易备份出“半截数据”。这几个参数不是可选，是底线：

--single-transaction：对 InnoDB 表开启一致性快照（不锁表），但对 MyISAM 无效；
--routines：否则存储过程和函数全丢；
--triggers：触发器不会自动包含；
--events：事件调度器定义也不会导出。

漏掉任意一个，恢复后功能可能残缺——比如订单系统依赖某个 event 清理日志，备份里没它，上线就积压。

crontab 定时任务总不执行？先查这三处

常见现象：手动运行脚本成功，但 crontab 里死活不生成文件，也没报错。

crontab 默认 PATH 很窄，mysqldump 路径要写绝对路径（如 /usr/bin/mysqldump），用 which mysqldump 确认；
脚本开头必须有 #!/bin/bash，且 crontab -e 里调用的路径必须是绝对路径（如 /home/backup/backup.sh）；
日志重定向被忽略：在 crontab 条目末尾加 >& /var/log/mysql-backup.log，否则所有输出都丢进邮件队列，而多数服务器没配本地 mail 服务。

典型 crontab 条目应类似：

0 2 * * * /home/backup/backup.sh >& /var/log/mysql-backup.log

备份文件怎么命名才不乱套

用 $(date +%F_%H%M) 比 $(date +%Y%m%d) 更可靠，因为同一秒内多个备份会冲突；但更重要的是：别只靠文件名判断新旧。

压缩备份更省空间：mysqldump ... | gzip > backup_$(date +%F_%H%M).sql.gz；
删除旧文件别只看时间戳，用 find ... -mtime +7（注意：-mtime 是按 24 小时整数倍算，不是日历天）；
真正保险的做法是：每次备份前先 rm -f $BACKUP_DIR/latest.sql.gz，再 ln -s backup_*.sql.gz $BACKUP_DIR/latest.sql.gz，这样总有“最新”软链可用。