备份恢复、PITR 与高可用运维

一句话定义

备份恢复体系由「物理/逻辑备份 + 日志归档 + 恢复演练」三件套构成：全量备份提供基线，WAL 归档支持任意时点恢复（PITR），而 RPO/RTO 指标与定期演练把「有备份」升级为「能恢复」。

为什么重要

「有备份但恢复失败」是真实世界最痛的数据库事故形态——备份未演练等于没有备份。
误删库（DROP TABLE 无 WHERE 的 DELETE）比硬件故障更常见，PITR 是唯一解药。
RPO/RTO 是与业务方对齐容灾期望的通用语言，也是 kp-023 复制与 kp-020 日志体系的验收标准。

前置知识

kp-020（WAL/Redo/Undo——备份与恢复的物理基础）。

核心概念

物理备份：拷贝数据文件/页（pg_basebackup、InnoDB 热备工具），恢复快、跨版本难。
逻辑备份：导出 SQL/行数据（pg_dump、mysqldump），可读可迁移、大库慢。
全量 + 增量：基线备份 + WAL/binlog 归档。
PITR（Point-in-Time Recovery）：把基线恢复后重放归档日志到指定时间戳/LCN。
RPO（Recovery Point Objective）：最多容忍丢多少数据（时间维度）；RTO（Recovery Time Objective）：最多容忍多久的停服。
备份三二一原则：3 份副本、2 种介质、1 份异地。
恢复演练：在隔离环境真实执行恢复并校验数据一致性。

原理与机制

一致性快照的来源：物理备份依赖引擎的备份模式（PG 的 pg_start_backup 显式进入备份态并记录起始 LSN，拷贝期间归档不中断；MySQL 的 XtraBackup 拷贝 + 应用日志达成一致点）。PITR 的机制完全复用 kp-020 的崩溃恢复：把基线当作「带起点 LSN 的检查点」，从该 LSN 起重放归档日志，停在目标时间戳——因此归档的连续性（无缺口、校验和完整）是整个体系的命门。恢复目标三类：最新（崩溃恢复）、指定时间戳（误操作前一刻）、指定事务/GTID（精确跳过某条误操作）。副本 ≠ 备份：复制保护「硬件故障」，但 DELETE 的误操作会被原样复制到所有从库；备份保护「逻辑错误」。演练设计要点：随机抽取备份集 → 隔离环境恢复 → 用行数/校验和/抽样业务查询比对 → 记录 RTO 实测值；每季度一次，结果进风险台账。

实例或案例

一个可执行的基线方案（PostgreSQL 为例）：每日凌晨 pg_basebackup 全量 + 持续 WAL 归档到对象存储，保留 14 天 → RPO 可达分钟级（取决于归档间隔），RTO 取决于恢复数据量（实测 500GB 约 2~4 小时）。误删表演练：记录误操作时间戳 10:32:15 → 恢复基线到隔离实例 → recovery_target_time = '10:32:14' 重放 → 抽取误删表导回生产，全程约 40 分钟。MySQL 对应方案：XtraBackup 全量 + binlog 归档，mysqlbinlog --start-datetime --stop-datetime 重放。

常见误区

把从库当备份：逻辑误操作与恶意删除会被复制放大，从库救不了数据正确性。
备份从未恢复过：未演练的备份在真实事故中的失败率惊人（归档缺口、密码丢失、版本不兼容都可能出现）。
只备份数据库忽略配置与账号：恢复出空库无法连接（pg_hba、my.cnf、权限表同样是资产）。

自测题

RPO 与 RTO 分别由什么决定？答：RPO 由归档/复制频率与保留策略决定（能回溯到多近的点）；RTO 由恢复速度决定（备份体量、恢复带宽、演练熟练度）。
为什么必须单独做物理备份而不能只靠复制？答：复制同步的是操作结果，逻辑错误（误删、脏数据、勒索加密）会同步到全部副本；只有独立时间点的备份才能回退逻辑错误。

公式或模型

RPO ≈ 归档间隔 + 故障发现延迟；RTO ≈ 恢复数据量 / 恢复吞吐 + 验证时间。备份窗口估算：备份时长 ≈ 数据量 / 备份吞吐，500GB / 100MB/s ≈ 1.4 小时。

图示

PITR = 一致性基线 + 连续日志归档 + 指定时间戳停止重放

直观类比

备份体系像保险与消防的合体：全量备份是灭火器（平时闲置、必须定期试喷）；WAL 归档是楼梯间应急灯（时刻在线）；演练是消防演习——没演习过的消防预案只是墙上的装饰画。

与其他知识点的关系

kp-020 提供恢复的机制地基；kp-023 的复制与备份构成「高可用 + 可恢复」双保险；kp-030 把 RPO/RTO 作为运维成熟度评分项；kp-032 的合规要求规定保留期限。

前置知识点

相关知识点