关系型数据库备份与恢复：从全量备份到时间点恢复

数据库备份最容易被误解。很多团队以为有主从复制就安全，有云盘快照就安全，有每日备份就安全。真正的问题是：当误删、误更新、勒索、磁盘损坏、区域故障发生时，你能否在业务要求的时间内恢复到正确数据点。

备份不是文件，备份是恢复能力。

RPO 与 RTO

任何备份策略都要先定义：

• RPO：最多允许丢失多久数据。
• RTO：最多允许多久恢复服务。

如果核心交易库要求 RPO 5 分钟，只有每日全量备份显然不够。必须结合 binlog 或 WAL 做时间点恢复。

MySQL 备份

MySQL 常见备份方式：

• 逻辑备份：mysqldump、mydumper。
• 物理备份：Percona XtraBackup、存储快照。
• binlog：用于时间点恢复。

逻辑备份可读性强，适合小库和迁移，但大库恢复慢。物理备份适合大库，恢复速度更好。binlog 让你能从全量备份恢复到指定时间点。

生产建议：

• 定期全量物理备份。
• 持续保存 binlog。
• 备份文件跨区域保存。
• 定期恢复演练。
• 对备份加密和权限隔离。

PostgreSQL 备份

PostgreSQL 常见方式：

• 逻辑备份：pg_dump、pg_dumpall。
• 物理基础备份：pg_basebackup。
• WAL 归档：用于 PITR。

PITR 流程通常是恢复基础备份，再回放 WAL 到指定时间点。关键是 WAL 归档必须完整、可读，并与基础备份匹配。

如果 WAL 归档断档，时间点恢复能力就会中断。

复制不是备份

主从复制解决节点故障，不解决逻辑错误。一次错误的 DELETE 或 UPDATE 会复制到从库。延迟从库可以作为一种保护手段，但它仍然不是完整备份。

延迟从库适合快速应对误操作，但要有明确切换流程，并防止延迟被追平。

恢复演练

没有演练的备份不可信。演练要验证：

• 备份文件是否完整。
• 恢复流程是否可执行。
• 应用能否连接恢复库。
• 数据一致性是否通过校验。
• 实际 RTO 是否达标。
• 时间点恢复是否精确。

演练环境应与生产尽量接近，至少数据规模和版本要接近。

备份安全

备份通常包含最完整的数据，因此要按生产数据同等级保护：

• 加密存储。
• 独立账号和权限。
• 跨区域保存。
• 不可变保留策略。
• 删除权限严格控制。
• 访问审计。

很多数据泄露并不是生产库被攻破，而是备份文件暴露。

恢复后的校验

恢复后不要只看数据库能启动。还要校验：

• 表数量和行数。
• 关键业务数据抽样。
• 外键或业务约束。
• 应用核心流程。
• 复制拓扑是否重建。
• 缓存和搜索索引是否需要重建。

数据恢复是系统恢复的一部分，不是全部。

总结

关系型数据库备份恢复的核心是全链路可验证。全量备份、日志归档、时间点恢复、跨区域保存和恢复演练缺一不可。不要等事故发生时才第一次恢复。数据库的韧性，来自平时反复证明“我们真的能恢复”。