mysqldump 定时备份与恢复演练

备份没演练过恢复，等于没有备份。mysqldump 这种逻辑备份方式虽然朴素，参数用对、定时挂上、每月演练一次，对几十 GB 以内的库完全够用。 ## 一、备份命令怎么写 ``` mysqldump -uroot -p --single-transaction --routines --triggers blog | gzip > /backup/blog_$(date +%F).sql.gz ``` --single-transaction 让 InnoDB（MySQL 的默认存储引擎）表在一致性快照下导出，不锁表，业务无感。--routines 和 --triggers 把存储过程、触发器带上，漏了这两个参数，恢复完才会发现少了东西。多库建议按库分开导，恢复哪个导哪个，比全库一个文件灵活。导大表前看一眼磁盘余量，备份文件通常是数据量的几分之一，心里先有数。 ## 二、挂上定时任务 cron 里每天凌晨三点跑： ``` 0 3 * * * /usr/local/bin/backup_mysql.sh >> /var/log/backup.log 2>&1 ``` 脚本里检查 mysqldump 的退出码，失败立刻发通知。定时任务最大的敌人是静默失败，跑没跑、成没成，必须有人或机器知道。cron 的环境变量很精简，脚本里全部用绝对路径——手动能跑、cron 跑不了，是备份脚本最经典的坑。 ## 三、恢复演练怎么做 每月固定一天，把备份恢复到临时实例验证，另一台机器或容器都行： ``` gunzip < blog_2026-10-01.sql.gz | mysql -uroot -p -h 127.0.0.1 blog_test ``` 恢复完查三样：表数量和行数对不对、最新一条业务数据在不在、用应用账号连上去跑几个核心查询。演练耗时超过能接受的恢复时间，说明策略要调整，比如缩短备份周期或换物理备份。演练结果记个简单台账：日期、备份文件名、恢复耗时、抽查结论，下次演练对着上次找差距。 ## 四、异地存放与保留策略 备份和数据库放同一块盘，盘坏了一锅端。rsync 或 scp 把每天的备份传到另一台机器，保留策略按天数滚动：7 天内的日备加 4 周的周备，是常见组合。清理动作写进脚本，别靠人记。传输备份用专用的低权限账号，只给写入备份目录的权限，机器失守时备份也不至于被顺手清光。 把"恢复演练"写进日历，比把"备份成功"写进日志重要。前者验证的是真有退路，后者只说明脚本跑过。