数据库备份与恢复演练：从策略设计到实战验证的完整指南
面向 DBA 和 IT 运维，说明数据库备份策略设计、备份类型选择、恢复演练方法和常见坑。基于盈尺在金融央企的数据库运维经验，强调"没演练过的备份等于没备份"。
备份策略不是"配个 cron 就完了"。要按 RPO/RTO 设计备份层级，定期做恢复演练，否则真出事时才发现备份不可用。
适用对象
- 备份要按 RPO（能容忍丢多少数据）和 RTO（能容忍停多久）设计，不是"全量+增量就完了"。
- 没演练过的备份等于没备份。至少半年做一次恢复演练，验证备份是否可恢复、恢复速度是否达标。
- 备份要异地。单机备份在主机故障时一起丢失，必须有异地副本或云端备份。
- 恢复演练要记录时间、步骤、问题和改进项，形成可追溯的运维证据。
先确认这类资料适合解决什么问题
备份策略不是"配个 cron 就完了"。要按 RPO/RTO 设计备份层级，定期做恢复演练，否则真出事时才发现备份不可用。
数据库备份是数据安全的最后一道防线，但很多团队的备份策略只停留在"配个 cron 定时任务导出"。真正的备份策略要按 RPO（Recovery Point Objective，能容忍丢失多少数据）和 RTO（Recovery Time Objective，能容忍停机多久）来设计。
备份类型选择：全量备份（完整数据快照，恢复最简单但耗时长）、增量备份（只备份上次全量后的变化，恢复需要全量+增量链）、日志备份（binlog/redo log，可恢复到任意时间点）。通常组合是"周期全量 + 日增量 + 持续日志"，实现 RPO 近似为零、RTO 可控。
Oracle 备份常用 RMAN（Recovery Manager），支持全量、增量、归档日志备份和恢复。RMAN 的增量累积备份可以显著减少备份时间和空间。MySQL 备份常用 mysqldump（逻辑备份）、xtrabackup（物理热备）或 binlog（时间点恢复）。物理备份恢复快但占用空间大，逻辑备份兼容性好但恢复慢。
本节判断
- 备份要按 RPO（能容忍丢多少数据）和 RTO（能容忍停多久）设计，不是"全量+增量就完了"。
先看哪些证据能支持下一步
恢复演练是备份策略中最容易被忽略的一环。"没演练过的备份等于没备份"——很多团队在真正故障时才发现备份格式不对、备份不完整、恢复工具版本不匹配、恢复时间远超预期。恢复演练至少每半年做一次，内容包括：从备份恢复到测试环境、验证数据完整性、记录恢复时间和步骤、发现并修复问题。
备份要异地。单机上的备份在主机硬件故障、磁盘损坏或勒索软件攻击时会一起丢失。至少要有一份异地副本（另一台服务器、NAS 或云端）。金融行业通常要求异地灾备，核心数据要在异地有一份实时或近实时的副本。
本节判断
- 没演练过的备份等于没备份。至少半年做一次恢复演练，验证备份是否可恢复、恢复速度是否达标。
从资料阅读进入可验证动作
恢复演练要留痕。记录演练时间、恢复耗时、遇到的问题、改进措施，形成运维证据链。合规审计（等保、金融监管）会检查备份策略和恢复演练记录，没有证据会被判定不合规。
盈尺在金融、央企的数据库运维中，备份策略和恢复演练是标准服务项。基于 DMP 平台可以配置 MySQL 的物理/逻辑备份定时任务，但恢复演练仍需 DBA 在测试环境执行并记录结果。
本节判断
- 备份要异地。单机备份在主机故障时一起丢失，必须有异地副本或云端备份。
- 恢复演练要记录时间、步骤、问题和改进项，形成可追溯的运维证据。
常见问题
备份多久做一次？
全量备份通常每周一次，增量每天一次，日志持续。具体频率按 RPO 要求和数据库变化量确定。
恢复演练多久做一次？
至少半年一次。金融行业建议季度做一次关键系统的恢复演练，半年做一次全量演练。
云上数据库还需要自己做备份吗？
云数据库（如 RDS）有自动备份，但建议额外做一份独立的备份（如导出到对象存储），避免云平台故障导致备份和数据库一起丢失。