# 时间点恢复的策略权衡

> 备份是一份保险：备在哪里决定容灾等级，保留多久决定恢复窗口，多久备一次决定恢复速度 —— 三个问题定义一份备份策略。

---

LLMS 索引： [llms.txt](/zh/llms.txt)

---

备份本质上是一份保险：**保费** 是存储空间、网络带宽与管理成本，**保额** 是灾难来临时能挽回多少数据、多快恢复服务。
和所有保险一样，这里没有免费的午餐 —— 更长的恢复窗口意味着更多的空间，更快的恢复意味着更频繁的备份。

设计备份策略，就是回答三个问题：**备在哪里？保留多久？多久备一次？**


----------------

## 备在哪里：故障域决定容灾等级

备份仓库的位置是第一个、也是最重要的决定，因为它直接划定了备份能扛住哪个级别的灾难。

**本地仓库**（`pgbackrest_method: local`）把备份放在主库本地磁盘上。它简单、快速、没有外部依赖，
恢复时走本地 I/O 速度最快 —— 但备份与数据共享同一个故障域：磁盘损毁、主机报废、机器被勒索加密时，
备份大概率与数据一同陪葬。它能对抗的是 **逻辑错误**（误删、缺陷），而不是 **物理灾难**。

**远程仓库**（`pgbackrest_method: minio` 或云上 S3）把备份放进独立的故障域。
数据库主机全灭，备份依然健在；配合 AES-256 加密与 Silo 多节点纠删码，
还能对抗仓库侧的磁盘故障，并降低备份介质泄露造成的明文暴露风险。
代价是恢复速度受网络带宽制约，以及多维护一个组件。

| 场景       | 推荐仓库                  | 理由                       |
|:---------|:----------------------|:-------------------------|
| 开发、测试、演示 | `local`               | 零依赖，坏了重建，无须容灾            |
| 生产环境     | `minio`（专用 Silo 集群）   | 独立故障域，加密，多节点纠删码          |
| 云上部署     | S3 / OSS 等对象存储        | 免维护，天然异地，成本低廉            |
| 高合规要求    | S3 版本控制 + 已配置保留期的对象锁定 | 防篡改、防勒索：锁定版本在保留期内不可被永久删除 |
{.full-width}

一个经常被忽略的角度：备份仓库同时是 **安全资产**。防勒索的关键不是"有备份"，
而是"攻击者拿到数据库主机的最高权限后，依然无法销毁备份" ——
这正是对象存储的版本控制与对象锁定（WORM）的价值所在，详见 [**备份仓库**](/docs/pgsql/backup/repository/)。


----------------

## 保留多久：空间与窗口

恢复窗口的长度由保留策略决定，而保留策略的成本是刚性的：**窗口越长，空间越大**，没有配置技巧可以绕开。

以一个 100 GB、每日变更 10 GB 的数据库为例（未计压缩）：

* **每日全量，保留两份**（本地仓库默认思路）：约 200 GB 备份 + 两天 WAL 归档 ≈ **2～3 倍** 数据库大小，
  换来一至两天的恢复窗口。
* **每周全量 + 每日增量，按时间保留十四天**（远程 `minio` 仓库预设）：稳态低点约三份全量 + 十二份增量 +
  十四天 WAL，下一次全量前增至十八份增量与二十一天 WAL；恢复窗口约 **十四至二十一天**。

实际占用通常显著低于这个粗估：zstd 压缩往往能将备份压缩数倍，块级增量（`block: y`）
使增量备份只存储文件内部真正变化的数据块。但数量级的规律不变 —— 为备份仓库规划 **数倍于数据库** 的空间是基本前提。

窗口应该多长？一个实用的标尺是：**窗口必须覆盖"错误从发生到被发现"的延迟**。
误删表通常几分钟内就会被发现，一天的窗口绰绰有余；而缓慢污染数据的软件缺陷、
要到月底对账才暴露的错误，则需要以周计的窗口。"本地一两天、远程至少两周"正是对这两类需求的回应。


----------------

## 多久备一次：频率与恢复速度

恢复耗时（RTO）由两段组成：**还原基础备份** 的时间加上 **重放 WAL** 的时间。
备份大小决定前者，备份 **频率** 决定后者 —— 距离恢复目标最近的那个基础备份越新，需要重放的 WAL 就越少。

WAL 重放是单进程的，而且重放高峰期写入的 WAL 可能比还原备份本身还慢。
对写入繁忙的库，如果恢复目标恰好落在下一次备份之前，"每周全量"可能需要重放接近一周的 WAL —— 这正是增量备份的价值：
以极小的空间代价（块级增量下通常只有全量的百分之几），把"需要重放的历史"每天清零一次。

经验法则：**备份窗口允许的前提下，宁可提高备份频率，不要拉长重放距离**。


----------------

## 两种预设策略

Pigsty 把上述权衡沉淀为两套开箱即用的预设，多数场景可以直接采用或微调：

两套配置是 **候选仓库**：`pgbackrest_method` 每次选择其中一个，v4.5.0 模板只把被选项渲染为 `repo1`。
同时保留 `local` 与 `minio` 两个字典项不等于双仓备份；真正的 pgBackRest 多仓方案需要额外的显式配置与独立验证。

**标准策略：本地仓库 + 每日全量**。配置简单，恢复走本地磁盘速度最快，适合开发测试与容灾要求有限的场景：

```yaml
pgbackrest_method: local               # 备份到主库本地 /pg/backup（默认值，可省略）
pg_crontab: [ '00 01 * * * /pg/bin/pg-backup full' ]   # 每日凌晨一点全量备份
# 保留最近两个全量备份，恢复窗口约一至两天
```

**生产策略：Silo / S3 远程仓库 + 周全量日增量**。独立故障域，AES-256 加密，十四至二十一天窗口，适合严肃生产环境：

```yaml
pgbackrest_method: minio               # 备份到专用 Silo 集群（或外部 S3）
pg_crontab:                            # 周一全量，其余每日增量
  - '00 01 * * 1 /pg/bin/pg-backup full'
  - '00 01 * * 2,3,4,5,6,7 /pg/bin/pg-backup'
# 按时间至少保留 14 天；周全备时恢复窗口约 14～21 天
```

空间估算与保留策略的可视化推演，请参阅任务层文档 [**备份策略**](/docs/pgsql/backup/policy/)。


----------------

## 没有演练过的备份，不算备份

最后一个权衡维度不在配置里，而在流程里。备份系统最危险的状态，是"看起来一直在正常运行"：
监控绿灯长明，仓库稳步增长，而没有人知道这些备份 **能不能恢复、恢复要多久**。

把恢复演练纳入例行运维：定期用 [**克隆恢复**](/docs/pgsql/backup/cluster/) 把备份还原成一套新集群 ——
这既是对备份完整性的端到端验证，也是对 RTO 的实测校准，而且不触碰生产集群；演练目标集群仍会被覆盖。
恢复的具体机制与工具，请继续阅读 [**声明式恢复**](/docs/concept/pitr/restore/)。