为一个数十 TB 的数据库做备份与灾难恢复

Question

IT Interview Practice · Accepted Answer

**把周期性快照与持续的 WAL 归档结合以实现时间点恢复（point-in-time recovery），跨机房/跨地域复制，并用定期的恢复演练对照明确的 RPO/RTO 目标来验证它。**一个你从未恢复过的备份是一种希望，而非一个计划。

## 架构

```text
Primary DB ──snapshot (daily)──▶ Object store (S3) ──cross-region replicate──▶ DR region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (continuous, PITR to any second)
                                          │
                          restore drill ──┴──▶ verified restore ─▶ measure RTO, checksum RPO
```

## 工作原理

- **快照（Snapshots）**是卷/集群的完整副本（例如每日 EBS 快照或 `pg_basebackup`）。它们是你恢复所*基于*的基线——但只恢复到昨晚会丢失一天的写入。
- **WAL / binlog 归档**把自上次快照以来的每个变更持续流式送到对象存储。恢复 = 快照 + 重放 WAL 到任意选定的秒。这就是 **PITR（时间点恢复，point-in-time recovery）**——恢复到 10:32:04，即一次糟糕的 `DELETE` 之前的那一刻。
- **异地 / 跨地域。**与 DB 在同一地域的备份会随该地域一同消亡。复制到第二个地域（S3 跨地域复制），使一次地域性中断或勒索软件不会同时端掉两者。
- **恢复演练。**定期恢复到一个临时环境，测量它耗时多久（**RTO**）和你会丢失多少数据（**RPO**），并与生产做校验和（checksum）比对。

## RPO 与 RTO

- **RPO（恢复点目标，Recovery Point Objective）** = 你能承受丢失多少数据。每 5 分钟归档一次 WAL → RPO ≈ 5 分钟。同步 replica → RPO ≈ 0。
- **RTO（恢复时间目标，Recovery Time Objective）** = 你必须多快恢复。从 S3 恢复 20TB 可能需要数小时；一个热备（warm standby）replica 能把 RTO 降到数分钟。

## 面试视角

面试官考察你是否知道**仅有快照还不够**（快照之间存在数据丢失）、你能否**用数字定义 RPO/RTO**，以及你是否**测试恢复**。出色的回答会强调未经测试的备份恰恰在需要时失效，并从*业务*的 RPO/RTO 而非便利性来选择策略。一个陷阱：把 read replica 当作备份——复制也会忠实地复制一条 `DROP TABLE`。

## 权衡与故障

- **成本与 RTO。**一个跨地域的热备提供分钟级 RTO 但使基础设施成本翻倍；从 S3 冷恢复便宜但慢。购买业务实际需要的档位。
- **备份负载。**对一个繁忙的 20TB DB 做快照会增加 I/O；从 replica 上做快照。
- **静默损坏。**WAL 可能归档一个损坏的页；定期的全量恢复 + 校验和能捕获它。
- **保留与合规。**为法律需求保留足够的历史（例如 35 天 PITR + 每月归档）；用 Glacier 实现廉价的长期保存。
- **何时不该用：**一个很小的 DB 每晚 `pg_dump` 到 S3 就够了——在数据丢失能用真金白银来衡量之前，完整的 WAL + 跨地域热备属于过度设计。

架构

工作原理

RPO 与 RTO

面试视角

权衡与故障

相关问题