数据库备份恢复策略怎么定？
五个经典回答示范
我的备份策略：分层——每日全量或增量加 binlog 连续归档，达到任意时点恢复能力（PITR）；频率与 RPO 对齐——核心库 RPO 分钟级用 binlog 加半同步；存储——本机保留短期、异地保留长期、加密存放；最重要的是演练——每月做恢复演练，备份不演练等于没备份。验证——每份备份恢复到临时实例跑校验查询。
我讲一次恢复实战：开发误 truncate 了生产订单表。流程：立即停止该表写入保护 binlog；从最近全量恢复影子实例；binlog 重放到误操作前一秒；反向导出该表数据回灌生产，全程 40 分钟。之后推动的改进：权限收敛（DDL 双人审批）、延迟从库（延迟 1 小时的备库专防误操作）、恢复 SOP 文档化加演练。误操作恢复的关键是 binlog 完整性——这是平时备份策略决定的。
资深视角：备份恢复体系按业务连续性设计。指标先行——RPO（能丢多少数据）与 RTO（多久恢复）由业务定，不同库分级不同投入；技术组合——物理备份（xtrabackup 快）加逻辑备份（mysqldump 可读可迁移）加 binlog 流水，快照作为补充；治理——备份成功率监控与告警（失败必须当天处理）、容量增长趋势、恢复演练制度化（演练发现问题才算有效）；边界认知——备份防误删与故障，容灾防机房级事件，两回事。
追问『全量还是增量』：数据量小直接每日全量简单可靠；TB 级用周日全量加每日增量加 binlog；『恢复演练怎么做』：自动化脚本随机挑备份恢复到临时实例、跑数据校验（行数与关键表 checksum）、记录恢复时长对照 RTO；『云上数据库还要备份吗』：要——云厂商防 infra 故障，误操作与逻辑损坏要靠自己备份，跨区域独立保存。
『数据库有主从了不用备份，从库就是备份，每天 mysqldump 脚本挂着就行成功失败没细看，恢复没试过不过应该不难。』——点评：主从防硬件故障不防误操作——drop 命令照样同步到从库；备份失败没人看是常态事故源；『应该不难』的恢复在真实故障里每个环节都可能卡死。
- 打开 模拟练习，选择「运维/DBA」方向，限时 3 分钟作答本题。
- 对照上方答题框架，逐点检查：哪些要素没覆盖、哪里表达啰嗦。
- 用自己项目的真实经历替换框架中的占位内容，重讲一遍并录音回听。
这类题在真实面试中常被追问细节，
建议进入限时模式练一遍。