数据库全量备份——这3个误区最要命

全量备份听着最省心——整库一个文件，出事往回倒一遍就完事。真到要恢复的那天，问题往往不在命令敲错，而在几个谁都觉得这还用问的地方。数据库全量备份这件事，我头几年踩的雷基本都落在下面这几类里，顺手把周边的小坑一起说了，都是今天就能改的。

把数据目录拷走，是最像备份的假备份

停库再拷当然没事，可线上谁敢停。于是有人直接 cp -r /var/lib/mysql 到另一个目录，文件都在，大小也对得上，看着踏实。InnoDB 有脏页、有 redo，运行中这么拷出来的东西是半截的——运气好能起来，运气不好启动就报错，最坑的是起来了但少了几个事务，你不主动查根本发现不了。要热备就用 mysqldump 加 –single-transaction，InnoDB 下能拿到一致性快照；库大、要快要稳，就上 xtrabackup 这类物理备份。真不是新旧之争，是场景问题。

数据库全量备份落在同一块盘上，等于没备

见过太多 /data/backup 跟数据库在同一块云盘、同一个挂载点，甚至就在库目录旁边。盘坏了备份陪着一起走。不过更常见的不是硬件坏，是手滑 rm -rf，是有人进来把整个目录加密了勒索。备份得挪出去：另一块盘、另一个账号下的对象存储、本地再留一台机器。老话讲 3-2-1，三份副本、两种介质、一份异地，小站做不到三份，至少守住“不跟源数据同命运”这一条，这条成本几乎为零，收益最大。

跑成功，不等于能恢复

日志里一行 Completed，很多人就把监控页面关了。0 字节的文件、磁盘写满写一半、管道压缩中途断掉而外层脚本没接退出码——这些都能留下一个看着正常的备份。判断有没有备份只有一个标准：恢复出来能查到你最后写进去的那条数据。做法不复杂，每季度挑一份最新的扔进临时实例恢复，核对表数量、几张核心表的行数、自增 id 的最大值，再随手查一条最近的业务数据。跑得通，再谈别的。

只备数据，周边全漏了

mysqldump 默认不带存储过程、触发器、事件，要加 –routines –triggers –events。账号权限在 mysql 库里，业务表的备份里压根没有，恢复完发现应用连不上，这种场面见过不止一次。还有字符集和 sql_mode，源库跟目标库不一致，导进去就是一堆乱码或者严格模式报错。my.cnf 也顺手留一份，几十行的文件，关键时刻省你半天。binlog 位点同样要记，–source-data=2 会把位置信息写进 dump，做时间点恢复全靠它。

全量天天跑，binlog 却只留几天

一次全量只能把你送回备份那一刻，中间那段路得靠 binlog 补。有人全量做得很勤，binlog 过期时间却设得极短，真出事才发现只回得到昨天凌晨。全量加上连续的 binlog，才叫能恢复到任意时间点。留多久看你敢丢多久的数据，具体参数以官方文档和服务商说明为准，别拍脑袋定。

频率、保留、加密，别拿一套参数糊到底

订单类的库一天一备明显不够，丢一小时的单子就是事故；个人博客一周一次都嫌多。保留做分层，日备留一段、周备留长点、月备留更久，看盘和合规要求定。还有一处最容易忽略：备份文件是明文 .sql，里面全是手机号和地址，随手丢进公共读的存储桶，等于自己往外送。桶权限收紧，能加密就加密，谁下载谁留痕。

全量和增量混着用，别只会一招

全量做多了占空间也占 IO，于是有人上增量或者差异，结果恢复的时候要按顺序一层层套，链条越长越容易断，中间少一个文件就全废。稳妥的做法是全量打底、增量补位，并且定期做一次只靠全量的“纯恢复”验证，确认底是干净的。规模不大就别折腾，老老实实每天全量，简单的东西不容易出错。

一份能照着改的检查清单

写清楚是逻辑备份还是物理备份；备份文件不在源库同一块盘、同一个账号下；每次跑完校验大小和退出码，失败要能告警到人；每季度恢复演练一次并写记录；表结构、账号权限、配置文件、binlog 位点一起备；保留策略按业务分层写进文档；备份文件加密，桶权限最小化；换人接手能看懂，而不是只存在某个人脑子里。

三句话收尾。拷数据目录不算备份，压得再小也没用；备份跟源库分开存，是成本最低的一条命；能恢复才算数，没验过的备份只能叫希望。今天有空的话，先去把 backup 目录从数据盘挪走，再挑一份最近的备份恢复试试——这两步花不了多少时间，比改十行备份脚本都值。