时间点恢复的策略权衡

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

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

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

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

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

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

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

保留多久：空间与窗口

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

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

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

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

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

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

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

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

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

两种预设策略

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

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

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

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

pgbackrest_method: minio               # 备份到专用 MinIO 集群（或云上 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 天

空间估算与保留策略的可视化推演，请参阅任务层文档 备份策略。

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

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

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