MySQL数据库备份，3个坑不在命令上

mysqldump 敲得再熟，也救不回一份打不开的备份文件。命令这东西门槛不高，是全库导还是分库导、加不加 –single-transaction，搜一下就有答案。麻烦的地方在别处：文件躺在那儿看着挺正常，真出事要往回倒的时候，导不进去，或者导进去了站是空的。mysql数据库备份这件事，难点基本都在命令之外。

mysql数据库备份最常见的坑：文件在，恢复不了

验证的办法笨但管用：隔一段时间挑最近那份，拿到一台临时实例上真导一遍，导完看看表数量对不对，再随便挑几张表 count 一下，顺便记一下恢复花了多久。别在原库上试，手一抖就是二次事故。压缩过的文件先 gzip -t 过一遍，坏包当场就能发现，不用等到救火那天。

数据带走了，环境没带走

第二类坑更隐蔽：数据本身没丢，但它认不出新家。跨大版本回导最典型，5.7 导出来的往 8.0 上灌，字符集、sql_mode、默认认证插件全在变。8.0 默认认证插件换成 caching_sha2_password，老客户端连上去直接懵。反着来更难受，新版导回老版基本等于重做一遍。

还有 mysqldump 默认不带的东西。触发器是带的，存储过程、函数、事件调度器要显式加 –routines –events，不加就静悄悄漏掉，等业务报错才发现少了一段逻辑。账号和授权表在 mysql 库，恢复完发现应用连不上，多半是这个原因。再就是 my.cnf 里那几行，max_connections、innodb_buffer_pool_size、字符集，跟数据一起记下来，不然换台机器性能表现完全是两回事。版本差异这块以官方文档为准，别照抄几年前的老教程。

一致性这回事，参数只解决一半

备份最怕的不是慢，是导出来的东西前后对不上。InnoDB 表加 –single-transaction 能拿到一个相对一致的快照，但它只对事务引擎有效；库里混着 MyISAM 表的时候，这个参数帮不了你，该锁还是得锁。表多、写入又频繁，备份窗口挑在业务低峰，这点比调参数实在。

打算做主从、或者以后想按时间点恢复的，还得让备份带上 binlog 位点。老版本是 –master-data，新版本改成了 –source-data，照着旧教程抄会直接报错。这个参数需要 RELOAD 权限，账号权限给不全的时候 dump 会停下来，日志里翻得到。另外 binlog 的保留时间要盖住至少两次全备之间的间隔，不然想做按时间点恢复，中间那段是空的。

顺带一句，密码别直接写在命令行里，history 一查全在。用 –defaults-extra-file 单独放一个权限 600 的配置文件，注意这个参数要放在最前面，放后面不生效。

备份和数据库躺在同一块盘上

这算不上技术坑，是常识坑。备份文件放在数据库同一台机器、同一块盘，甚至同一个机房——误删、磁盘坏、勒索加密，一次全带走。较真一点的做法是异地一份、本地一份，本地那份也别跟库同盘，扔到对象存储或者另一台机器上都行。

还有个特别常见的：备份文件放在网站根目录下。名字猜得到，路径能拼出来，等于把整库挂到公网让人下载。目录权限收紧、别放在 web 能访问的位置，这两条做到就不难。

定时任务在跑，但没人看它跑成什么样

cron 里写一行 mysqldump，看着就完成了，实际能出问题的地方一堆。cron 环境的 PATH 跟登录 shell 不一样，mysqldump 找不到命令，任务默默失败；日期格式化里的 % 在 crontab 里要转义，写 date +%Y%m%d 不转义就出错。脚本里 mysqldump 退出码非 0 就该发告警，光往日志里写一行没人看的字不算数。

保留策略也得有人管。只增不删，磁盘撑满了，先挂的可能是数据库本身。留几份、按日期命名、老的定期清掉，这些写进脚本比记在脑子里靠谱。

落地的话动作不用多：下次备份跑完，别急着关窗口，把那份文件拿到临时实例上导一次，看表数和几张关键表的数据对不对。能过这一关，命令怎么敲反倒是最不用操心的事。