[!info] related notes

• 课程 MOC：BodySense 数据库工程深化课程 MOC
• 前置：第 17 课
• 项目：BodySense 云原生基础设施规划

BodySense 数据库第 18 课：Backup、Restore、PITR、Replication 与 RPO / RTO

[!abstract] 本课目标 “有备份”只有在真的能恢复并满足 RPO/RTO时才有意义。

从零建立概念：先问“我要防哪一种数据灾难”

数据库灾难不只一种：

机器硬盘坏
数据库进程崩溃
主库不可用
误 DELETE
错误 migration
表逻辑损坏
账号被攻击后恶意删除
整个区域不可用
几小时后才发现数据错误

不同机制防不同事故。

所以：

Backup、Replication、PITR、High Availability 不能用一句“都有副本”混在一起。

Crash Recovery 和 Backup 先区分

上一课 WAL Crash Recovery：

同一数据库实例意外停止
→ 用本地 data files + WAL
→ 恢复到一致状态

Backup：

在线实例/文件本身已经不可信或不存在
→ 从独立保存的副本恢复

如果整个磁盘一起坏了，本地 WAL 也没了，Crash Recovery 就没有材料。

Logical Backup：导出逻辑对象和数据

PostgreSQL 常见：

pg_dump
pg_dumpall
pg_restore

逻辑备份更像：

schema objects
+
rows/data
→ logical archive

优点：

可选择 table/schema
跨机器恢复方便
可用于版本迁移场景
可检查逻辑对象

代价：

大数据库 dump/restore 可能很慢
不天然提供任意时间点恢复
恢复吞吐可能成为 RTO 瓶颈

Physical Backup：保存数据库物理基线

Physical backup 保存 PostgreSQL cluster data files 的一致基础状态。

典型：

pg_basebackup
storage snapshot（需满足 PostgreSQL 一致性要求）
managed database physical backup

它和 WAL 配合最自然。

Replication：为了 Availability / Read Scale，不是历史保险箱

Primary：

produces WAL

Standby/Replica：

receive WAL
→ replay
→ stay near current primary state

如果 Primary 硬件坏：

promote/fail over replica

可以降低服务中断时间。

但是：

DROP TABLE users

也是合法 transaction。

Replica 会忠实复制。

所以：

Replication 防“节点故障”，不天然防“逻辑错误”。

Synchronous vs Asynchronous Replication

Async

Primary commit 可以在 Replica 尚未确认持久化前返回。

优点：

lower commit latency

风险：

Primary sudden loss
→ some latest commits not yet replayed/received

可能产生非零 RPO。

Synchronous

Commit 等待指定 standby 达到一定确认级别。

优点：

stronger failover durability

代价：

network/standby latency enters commit path
standby failure may impact availability

仍然是业务取舍。

WAL Archiving：把连续历史保存到独立存储

正常 WAL segment 会在主库循环复用。

如果希望 PITR：

completed WAL
→ archive to durable external storage

形成连续历史。

它不能只偶尔成功。

如果中间缺一个必需 WAL segment：

base backup
+ incomplete WAL chain
→ cannot replay across the gap

所以要监控 archive failure / lag。

PITR：为什么可以恢复到“误删前 1 分钟”

PITR = Point-In-Time Recovery。

材料：

Base Backup at T0
+
WAL from T0 onward

恢复：

restore base backup
→ replay WAL
→ stop at target time / LSN / transaction

例如：

15:30 accidental DELETE

可恢复到：

15:29:59

然后从恢复实例导出需要的数据。

这比“回到昨晚 02:00 全量备份”损失小得多。

RPO / RTO 从零解释

RPO — Recovery Point Objective

最多允许恢复到多旧的数据点，也就是最多接受丢多少最近数据。

例：

RPO = 5 min

事故后允许最多损失最后约 5 分钟。

RTO — Recovery Time Objective

从事故开始到业务恢复可用，最多允许多久。

RTO = 30 min

就意味着不能设计一个需要 8 小时手工 restore 的流程。

两者不是同一件事

每分钟 backup
→ RPO 很小
但 restore 需要 6h
→ RTO 很差

也可能：

Replica failover 1 min
→ RTO 很好
但 async lag 10 min
→ RPO 可能较差

Backup Retention：保留多久也是设计

如果只有：

latest backup

而逻辑 corruption 两周后才发现：

latest backup already contains corruption

所以要设计：

hourly/daily/weekly
retention duration
off-site / cross-region
encryption
immutability
access control

根据业务和成本决定。

Restore Drill：Backup 成功日志不是证据终点

真正证据链：

backup created
→ artifact exists
→ restore into isolated environment
→ PostgreSQL starts
→ migrations/schema expected
→ key counts/invariants validate
→ application can connect
→ record duration

只有走完才知道：

backup is recoverable
RTO is measured

不是猜。

BodySense 为什么尤其需要考虑 Data Class

不同数据恢复优先级可能不同：

User account
BodyState history
Diagnosis/Treatment
Runtime Event
Job ledger
derived cache
analytics

例如 Redis Cache 可以重建，但 PostgreSQL Health history 可能需要更严格 RPO。

Disaster Recovery 方案应从 data classification 和业务 contract 推导。

1. Backup 与 Replication 不是同一个东西

Backup
→ 历史独立副本

Replication
→ 另一份接近当前状态的在线副本

误删一张表时，replica 也可能立刻复制误删；因此 replication 不能替代 backup。

2. Logical vs Physical

Logical：

pg_dump / pg_restore
→ schema + logical rows
→ 跨环境恢复灵活

Physical：

base backup / storage-level copy
→ cluster files
→ 与 WAL/PITR/standby 更紧密

3. PITR

Base Backup
+ continuous WAL archive
→ replay until target timestamp/LSN

可以恢复到误操作之前，而不只是最近一次每日备份。

4. RPO / RTO

RPO = 最多能接受丢多少数据
RTO = 最多能接受恢复多久

“每天备份一次”若业务 RPO 是 5 分钟，显然不满足需求。

5. Restore Drill

备份文件存在不代表可恢复。真正验收至少要：

• 在隔离环境恢复；
• 验证 migration/schema identity；
• 验证关键业务行/约束；
• 记录耗时；
• 证明应用能连接恢复后的数据库。

Prediction

[!question]

1. 有 streaming replica 是否还需要 backup？
2. 每天凌晨 2 点 pg_dump，下午 6 点数据库损坏，最大理论数据损失可能多少？
3. PITR 为什么需要连续 WAL archive？
4. Backup job 显示 success 是否足以通过 DR 验收？
5. RPO=0 与 RTO=0 是否现实且免费？

[!success]- Answer / 解析 1. 需要。 Replica 会复制逻辑错误/误删，也可能同时受区域/凭证/软件故障影响。

2. 接近 16 小时。 若没有增量/WAL 等其他恢复来源。

3. Base backup 只提供起点，目标时间点之间发生的 transaction 必须通过 WAL 重放。

4. 不足。 必须做 restore drill；坏备份、缺依赖、权限/schema 漂移都可能直到恢复时才暴露。

5. 通常不现实。 越接近零，复制、同步提交、多区域和自动 failover 成本/复杂度越高。

BodySense Lab

阅读现有 data-durability-backup 计划，写出当前 PostgreSQL：

backup mechanism
off-host location
restore procedure
claimed RPO
claimed RTO
last real restore evidence

没有真实证据的字段写 unknown，不要猜。

L4 Gate

能把一个“数据库坏了怎么办”的回答具体化为 Backup + WAL + Restore Drill + RPO/RTO，而不是只说“有主从/每天备份”。