运维转数据库：备份恢复的四个检查项
从运维转到数据库岗，第一年容易把注意力放在 SQL 上，低估备份恢复。
SQL 优化决定系统跑得快不快，备份恢复决定出事时能不能退回去。
这篇把我自己用的四个检查项整理出来。如果你刚开始接手数据库，可以拿去对照。
我是满小满，做了四年数据库运维，从运维岗转过来。
下面这些是我日常在用的做法，不涉及具体产品和机构。
一、四个检查项
我一开始也觉得，备份嘛，文件在就行。后来被现实教训过一次，才知道不是。
现在我判断备份，一般只看四个问题：
| 检查项 | 要回答的问题 | 检查方法 | 常见误区 |
|---|---|---|---|
| 备份是否完成 | 任务成功了吗，文件完整吗 | 看退出码、日志末尾、文件大小和校验值 | 任务显示成功，实际只备了一半 |
| 备份链是否完整 | 全量、增量、日志能不能接上 | 列出备份链，按时间点做一次恢复 | 有全量就够了 |
| 恢复是否可计时 | 真出事时，业务能等多久 | 在测试库计时，记录卡点 | 备份快，恢复也快 |
| 恢复后是否可用 | 数据完整吗，业务能接受吗 | 行数、金额汇总、关键表抽查 | 能启动就算恢复成功 |
前两个问题回答「有没有」，后两个回答「敢不敢用」。
我以前只盯着前两个，后来才知道，真出事时，后两个才要命。
只做前两项，容易在真出事时发现「备份在，但恢复不了」；只做后两项，容易忽略备份链本身不完整。
二、一张恢复演练记录表
| 项目 | 记录内容 |
|---|---|
| 演练时间 | 日期、参与人 |
| 恢复目标 | 哪个库、恢复到哪个时间点 |
| 备份组合 | 使用了哪几份全量、增量、日志 |
| 耗时 | 开始时间、完成时间、总时长 |
| 卡点 | 哪一步最慢、哪一步报错 |
| 校验 | 行数、金额汇总、边界数据 |
| 改进 | 下次先改什么 |
这张表我贴在值班手册第一页，改了好几次才稳定下来。
它的作用不是留档，是让下一次演练能对比：耗时有没有变化、卡点有没有减少、校验项有没有覆盖到关键业务。
三、三个常见误区
这三个误区，我听着都挺熟悉。
误区一：把「备份成功」当成「恢复成功」。
备份任务成功，只说明脚本跑到了最后一行。
文件能不能打开、备份链完不完整、恢复要多久，都是另外的事。
误区二：只保留最新一份。
保留策略要按「最晚发现时间」倒推。
如果一个问题第四天才发现，只保留三天备份，就已经没有可回退的点了。
误区三：恢复后只看能不能启动。
数据库能启动，不代表数据对。
至少要核对行数、金额汇总和边界数据；关键业务表还要抽查最新和最老记录。
四、如果你刚转岗，我会先做这三件小事
- 列出所有库、实例、负责人、备份方式和保留天数。
- 选一个测试库，按真实流程做一次恢复，记录耗时和卡点。
- 把最近一次故障按「现象—假设—验证—结论」写成一页纸。
这三件事不需要等权限、等预算，也不需要改生产。
做完之后，至少能回答一个问题：如果现在真出事，我们第一步做什么。
五、小结
备份恢复不是「有文件」，是「能在约定时间内恢复到一个确定的时间点，并且数据可用」。
四个检查项、一张记录表、三个误区，可以先从第一项开始对照。
如果你正在做第一次恢复演练，可以从这四个问题开始；有更细的校验方法，欢迎在评论区补充。
- 点赞
- 收藏
- 关注作者
评论（0）