备份策略
备份策略要回答三个问题：何时 备份（调度计划）、何处 存放（备份仓库）、 保留多久（保留策略）。本页给出两套久经考验的预设策略及其量化推演 —— 背后的权衡逻辑请参阅概念层文档 策略权衡。
备份频率与恢复速度直接相关：恢复时需要从最近的基础备份开始重放 WAL 日志到目标时间点， 备份越频繁，需要重放的 WAL 越少，恢复越快；而保留策略与仓库空间直接相关：窗口越长，占用空间越大。
每日全量备份
对于生产数据库，建议从最简单的每日全量备份策略开始。Pigsty 随附的标准 pigsty.yml 集群示例采用这一策略，
配合默认的 local 本地仓库（保留最近 2 个全量备份）使用：
pg_crontab: [ '00 01 * * * /pg/bin/pg-backup full' ]
pgbackrest_method: local # 选择备份仓库方法：`local`、`minio` 或其他自定义仓库
pgbackrest_repo: # pgbackrest 仓库配置: https://pgbackrest.org/configuration.html#section-repository
local: # 使用本地 POSIX 文件系统的默认 pgbackrest 仓库
path: /pg/backup # 本地备份目录，默认为 `/pg/backup`
retention_full_type: count # 按数量保留全量备份
retention_full: 2 # 使用本地文件系统仓库时，保留2个，最多3个全量备份
假设您的数据库大小为 100GB，每天写入 10GB 数据，备份耗时 1 小时。
下图将「恢复窗口」与「存储空间占用」合并到同一时间轴（0~108h）上推演该策略的稳态行为：
恢复窗口在 24～48 小时 之间循环，备份占用约为 2 个全量备份加上 1～2 天的 WAL 归档。
在实践中，您需要准备至少 3～5 倍 数据库大小的备份磁盘，才能从容使用该默认策略。
全量 + 增量备份
如果使用 MinIO / S3 作为集中式备份仓库，存储空间不再受本地磁盘限制， 此时可以用「周全量 + 每日增量」配合两周保留策略，换取更长的恢复窗口：
pg_crontab: # 周一凌晨1点全量备份，其余每日增量备份
- '00 01 * * 1 /pg/bin/pg-backup full'
- '00 01 * * 2,3,4,5,6,7 /pg/bin/pg-backup'
pgbackrest_method: minio
pgbackrest_repo: # pgbackrest 仓库配置: https://pgbackrest.org/configuration.html#section-repository
minio: # 可选的 minio 仓库
type: s3 # minio 兼容 S3 协议
s3_endpoint: sss.pigsty # minio 端点域名，默认为 `sss.pigsty`
s3_region: us-east-1 # minio 区域，默认 us-east-1，对 minio 无实际意义
s3_bucket: pgsql # minio 桶名，默认为 `pgsql`
s3_key: pgbackrest # pgbackrest 的 minio 用户访问密钥
s3_key_secret: S3User.Backup # MinIO 用户密钥
s3_uri_style: path # minio 使用路径风格 URI 而非主机风格
path: /pgbackrest # minio 备份路径，默认为 `/pgbackrest`
storage_port: 9000 # minio 端口，默认 9000
storage_ca_file: /etc/pki/ca.crt # minio CA 证书路径，默认 `/etc/pki/ca.crt`
block: y # 启用块级增量备份
bundle: y # 将小文件打包成单个文件
bundle_limit: 20MiB # 文件包大小限制，对象存储建议 20MiB
bundle_size: 128MiB # 文件包目标大小，对象存储建议 128MiB
cipher_type: aes-256-cbc # 为远程备份仓库启用 AES 加密
cipher_pass: pgBackRest # 仓库加密密码
retention_full_type: time # 按时间保留全量备份
retention_full: 14 # 按时间保留 14 天
同样假设数据库 100GB、每日增量与 WAL 均按 10GB 粗估，下图推演 30 天内恢复窗口与存储占用的变化：
retention_full_type: time 会确保至少留下一份年龄达到 14 天的全量备份，周全备时恢复窗口在 14～21 天 之间循环。
按这组未压缩假设，稳态占用约为 560～690GB，新全量完成、旧链过期前的瞬时峰值约为 790GB；
实际占用取决于 WAL 量、块级增量命中率与 zstd 压缩率。
空间规划
两套策略的空间需求可以按以下经验公式粗估（实际占用受压缩与块级增量影响，通常更低）：
| 策略 | 恢复窗口 | 空间粗估 | 建议预留 |
|---|---|---|---|
| 每日全量，保留 2 份（local） | 24～48 小时 | 2 × 全量 + 1～2 天 WAL | 数据库大小的 3～5 倍 |
| 周全量 + 日增量，按时间保留 14 天（minio） | 14～21 天 | 3 × 全量 + 12～18 份增量 + 14～21 天 WAL | 按实测压缩率与 WAL 量规划 |
注意 瞬时峰值：新的全量备份成功完成后，旧备份才会参与过期计算，因此仓库会短暂多出一份全量备份， 同时保留尚未清理的旧备份链与 WAL。空间规划必须覆盖这个峰值而非只看清理后的稳态。
WAL 归档的增长与写入负载成正比。批量导数、VACUUM FULL、大规模 UPDATE 都会瞬间产生大量 WAL，
如果备份仓库空间紧张，请在此类操作前后关注仓库水位（监控指标 开箱即用）。
应用策略变更
备份策略的三类变更，分别用对应的剧本任务应用：
./pgsql.yml -t pg_crontab -l pg-meta # 变更调度计划（pg_crontab）后：更新 crontab
./pgsql.yml -t pg_backup -l pg-meta # 变更仓库定义（pgbackrest_repo / pgbackrest_method）后：重新渲染配置并初始化 stanza
pg-backup full # 切换仓库后：立即执行一次全量备份，建立新仓库中的恢复起点
注意：切换 pgbackrest_method 到新仓库后，旧仓库中的备份不会自动迁移；
在新仓库完成首次全量备份之前，恢复窗口存在缺口。