mysql在线备份唯一稳妥方式是mysqldump，需用--single-transaction保障innodb一致性，并配合--routines --triggers --events导出完整对象；密码应存于~/.my.cnf（权限600），crontab定时执行（绝对路径+日志重定向），备份文件须带时间戳、压缩并自动清理旧文件，且必须校验文件非空及格式有效性。
MySQL 备份命令必须用 mysqldump，别用 mysqlhotcopy 或直接拷贝数据目录
直接复制 /var/lib/mysql/ 下的文件几乎必然失败——InnoDB 表在运行时文件不一致，备份出来无法恢复；mysqlhotcopy 已被弃用且只支持 MyISAM。唯一稳妥的在线逻辑备份方式就是 mysqldump。
实操建议：
- 用
--single-transaction保证 InnoDB 一致性（无需锁表），但要求 MySQL ≥ 5.6 且事务隔离级别为 REPEATABLE READ - 加上
--routines --triggers --events才能导出存储过程、触发器和事件调度器 - 避免使用
--all-databases，除非你真要备份所有库；更推荐显式列出库名，例如mysqldump -u root -p'xxx' db1 db2 > backup.sql - 密码不要写在命令行里（会泄露到
ps aux和 shell 历史），改用配置文件：~/.my.cnf，权限设为600，内容如下：
[client] user = backup_user password = your_secure_password
定时任务必须用 crontab -e，不能靠脚本里写 sleep 循环
crontab 是唯一可靠、可审计、可独立管理的定时机制。用 while true; do ...; sleep 86400; done 启动后台进程，一旦终端断开或系统重启就失效。
关键细节：
- crontab 的环境变量极简（PATH 通常只有
/usr/bin:/bin），所以mysqldump要写绝对路径，如/usr/bin/mysqldump - 时间字段用
0 2 * * *表示每天凌晨 2 点执行，别用中文注释混在 crontab 行里（会被当成命令一部分） - 务必重定向 stdout 和 stderr：
/path/to/backup.sh >> /var/log/mysql-backup.log 2>&1，否则失败时你根本不知道发生了什么
备份文件必须带日期戳并自动清理旧文件，否则磁盘迟早爆掉
不加时间戳的 backup.sql 每天覆盖一次，等于没备份；不清理旧文件，三个月后几百 MB 的 SQL 文件堆满 /backup 目录是常态。
脚本里这样处理最稳妥：
- 用
$(date +\%Y\%m\%d_\%H\%M)生成精确到分钟的时间戳，避免同秒多次运行冲突 - 文件名示例：
/backup/db1_20240520_0200.sql.gz，压缩节省空间（gzip默认压缩率够用） - 清理 7 天前的文件：
find /backup -name "db1_*.sql.gz" -mtime +7 -delete，注意-mtime +7表示“修改时间超过 7×24 小时”，不是“7 天前”
备份后必须校验 mysqldump 是否真正成功，不能只看脚本是否“跑完”
mysqldump 出错时可能仍返回 0 退出码（尤其遇到 warning 但继续执行），或者因网络中断、磁盘满、权限不足导致输出为空文件。不检查结果，等于白备。
校验动作要放在压缩和清理之前：
- 检查文件大小：
if [ ! -s "$backup_file" ]; then echo "ERROR: empty backup"; exit 1; fi - 检查是否包含关键标识：
head -n 20 "$backup_file" | grep -q "MySQL dump" || { echo "ERROR: not a valid mysqldump output"; exit 1; } - 可选：用
gzip -t校验压缩完整性（如果用了 gzip）
真正的难点不在写脚本，而在于让每次备份都可验证、可追溯、可恢复——比如定期抽样 gunzip -c xxx.sql.gz | head -50 看开头是不是 -- MySQL dump...，这事没人做，但出事时最管用。
