时间点恢复

• 1: 时间点恢复的工作原理
• 2: 时间点恢复的实现架构
• 3: 时间点恢复的策略权衡
• 4: 时间点恢复的典型场景

pgbackrest_enabled: true          # 在 pgsql 主机上启用 pgBackRest 吗？
pgbackrest_clean: true            # 初始化时删除 pg 备份数据？
pgbackrest_log_dir: /pg/log/pgbackrest # pgbackrest 日志目录，默认为 `/pg/log/pgbackrest`
pgbackrest_method: local          # pgbackrest 仓库方法：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             # 使用本地文件系统仓库时，最多保留 3 个完整备份，至少保留 2 个
  minio:                          # pgbackrest 的可选 minio 仓库
    type: s3                      # minio 是与 s3 兼容的，所以使用 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  # pgbackrest 的 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`
    bundle: y                     # 将小文件打包成一个文件
    cipher_type: aes-256-cbc      # 为远程备份仓库启用 AES 加密
    cipher_pass: pgBackRest       # AES 加密密码，默认为 'pgBackRest'
    retention_full_type: time     # 在 minio 仓库上按时间保留完整备份
    retention_full: 14            # 保留过去 14 天的完整备份
  # 您还可以添加其他的可选备份仓库，例如 S3，用于异地容灾

s3:    # ------> /etc/pgbackrest/pgbackrest.conf
  repo1-type: s3                                   # ----> repo1-type=s3
  repo1-s3-region: us-west-1                       # ----> repo1-s3-region=us-west-1
  repo1-s3-endpoint: s3-us-west-1.amazonaws.com    # ----> repo1-s3-endpoint=s3-us-west-1.amazonaws.com
  repo1-s3-key: '<your_access_key>'                # ----> repo1-s3-key=<your_access_key>
  repo1-s3-key-secret: '<your_secret_key>'         # ----> repo1-s3-key-secret=<your_secret_key>
  repo1-s3-bucket: pgsql                           # ----> repo1-s3-bucket=pgsql
  repo1-s3-uri-style: host                         # ----> repo1-s3-uri-style=host
  repo1-path: /pgbackrest                          # ----> repo1-path=/pgbackrest
  repo1-bundle: y                                  # ----> repo1-bundle=y
  repo1-cipher-type: aes-256-cbc                   # ----> repo1-cipher-type=aes-256-cbc
  repo1-cipher-pass: pgBackRest                    # ----> repo1-cipher-pass=pgBackRest
  repo1-retention-full-type: time                  # ----> repo1-retention-full-type=time
  repo1-retention-full: 90                         # ----> repo1-retention-full=90

pg-pitr                                 # 恢复到WAL存档流的结束位置（例如在整个数据中心故障的情况下使用）
pg-pitr -i                              # 恢复到最近备份完成的时间（不常用）
pg-pitr --time="2022-12-30 14:44:44+08" # 恢复到指定的时间点（在删除数据库或表的情况下使用）
pg-pitr --name="my-restore-point"       # 恢复到使用 pg_create_restore_point 创建的命名恢复点
pg-pitr --lsn="0/7C82CB8" -X            # 在LSN之前立即恢复
pg-pitr --xid="1234567" -X -P           # 在指定的事务ID之前立即恢复，然后将集群直接提升为主库
pg-pitr --backup=latest                 # 恢复到最新的备份集
pg-pitr --backup=20221108-105325        # 恢复到特定备份集，备份集可以使用 pgbackrest info 列出

pg-pitr                                 # pgbackrest --stanza=pg-meta restore
pg-pitr -i                              # pgbackrest --stanza=pg-meta --type=immediate restore
pg-pitr -t "2022-12-30 14:44:44+08"     # pgbackrest --stanza=pg-meta --type=time --target="2022-12-30 14:44:44+08" restore
pg-pitr -n "my-restore-point"           # pgbackrest --stanza=pg-meta --type=name --target=my-restore-point restore
pg-pitr -b 20221108-105325F             # pgbackrest --stanza=pg-meta --type=name --set=20221230-120101F restore
pg-pitr -l "0/7C82CB8" -X               # pgbackrest --stanza=pg-meta --type=lsn --target="0/7C82CB8" --target-exclusive restore
pg-pitr -x 1234567 -X -P                # pgbackrest --stanza=pg-meta --type=xid --target="0/7C82CB8" --target-exclusive --target-action=promote restore

1 - 时间点恢复的工作原理

时间点恢复（PITR）的核心原理是：基础备份 + WAL 归档 = 任意时间点恢复能力。 在 Pigsty 中，这一能力由 pgBackRest 实现，并通过 定时备份 + WAL 归档 自动运行。

三要素

基础备份

基础备份是数据库在某一时刻的物理快照，是 PITR 的恢复起点。Pigsty 通过 pgBackRest 生成基础备份，并提供 pg-backup 脚本封装常用操作。

备份类型

Pigsty 的默认行为

• pg-backup 默认执行增量备份，若不存在全量备份会自动补一次全量。
• 备份任务通过 pg_crontab 配置，写入 postgres 用户的 crontab。
• 脚本会自动识别节点角色，只有主库实际执行，从库会直接退出。

备份频率越高，需要重放的 WAL 越少，恢复速度越快。 更多细节请参阅 备份机制 与 备份策略。

WAL 归档

WAL（Write-Ahead Log）记录了数据库的每一次变更。PITR 通过持续归档 WAL，确保能够把数据库从基础备份重放到指定时刻。

Pigsty 的归档链路

Pigsty 默认开启 WAL 归档，并将归档动作交给 pgBackRest：

• archive_mode = on
• archive_command = pgbackrest --stanza=<cluster> archive-push %p

pgBackRest 会持续接收 WAL 段文件，并依据保留策略自动清理过期归档。 恢复时，pgBackRest 负责通过 archive-get 拉取所需 WAL。

关键影响

• 归档延迟会缩短恢复窗口的右边界。
• 仓库不可用会导致归档中断，直接影响 PITR 能力。

更多细节请参阅 备份机制 与 备份仓库。

恢复目标与事务边界

PITR 的恢复目标由 PostgreSQL 的 recovery_target_* 系列参数定义，Pigsty 通过 pg_pitr 或 pg-pitr 进行封装。

目标类型

包含与排除

恢复目标默认是包含（inclusive）的。 若要回退到目标点之前，在 pg_pitr 中设置 exclusive: true，对应 PostgreSQL 的 recovery_target_inclusive = false。

事务边界

PITR 会保留目标点前的已提交事务，并回滚未提交事务。

gantt
    title 事务边界与恢复目标
    dateFormat X
    axisFormat %s
    section 事务 A
    BEGIN → COMMIT (已提交) :done, a1, 0, 2
    section 事务 B
    BEGIN → 未提交 :active, b1, 1, 4
    section 恢复
    恢复目标点 :milestone, m1, 2, 0

更多操作细节请参阅 恢复操作。

恢复窗口

恢复窗口由两个边界决定：

• 左边界：最早可用的基础备份
• 右边界：最新已归档的 WAL

窗口长短取决于备份频率、备份保留与 WAL 归档保留策略：

• local 仓库默认保留 2 个全量备份，窗口通常为 24～48 小时。
• minio 仓库默认按时间保留 14 天备份，窗口通常为 1～2 周。

具体策略配置请参阅 备份策略 与 备份仓库。

时间线

时间线（Timeline）用于区分不同历史分支。以下操作会生成新时间线：

1. PITR 恢复
2. 从库提升（Promote）
3. 故障切换（Failover）

gitGraph
    commit id: "初始状态"
    commit id: "写入数据"
    commit id: "继续写入"
    branch Timeline-2
    checkout Timeline-2
    commit id: "PITR 恢复点1"
    commit id: "新写入"
    branch Timeline-3
    checkout Timeline-3
    commit id: "PITR 恢复点2"
    commit id: "继续运行"
    checkout main
    commit id: "原时间线继续"

当仓库存在多个时间线时，可通过 timeline 指定目标；Pigsty 默认使用 latest。 更多细节请参阅 恢复操作。

2 - 时间点恢复的实现架构

Pigsty 使用 pgBackRest 作为 PostgreSQL 备份与恢复引擎，提供开箱即用的时间点恢复（PITR）能力。

本文从架构层面说明：备份由谁执行、数据流向哪里、仓库如何组织、故障切换后如何保持连续性。

概览

PITR 架构由三条主线构成：备份执行链路、WAL 归档链路、恢复执行链路。

更多执行细节见 备份机制 与 恢复操作。

组件与职责

数据流

flowchart TB
    subgraph cluster["PostgreSQL 集群"]
        direction TB
        primary["Primary<br/>PostgreSQL"]
        pb["pgBackRest"]
        cron["pg-backup / pg_crontab"]
    end
    repo["备份仓库<br/>local / minio / s3"]
    restore["恢复目标数据目录"]

    cron --> pb
    primary -->|base backup| pb
    primary -->|WAL archive| pb
    pb -->|backup/archive| repo
    repo -->|restore/archive-get| pb
    pb -->|restore| restore

要点：

• 备份 由 pg-backup 触发，执行 pgbackrest backup 将基础备份写入仓库。
• 归档 由 PostgreSQL 的 archive_command 触发，持续将 WAL 段写入仓库。
• 恢复 从仓库读取备份与 WAL，通过 pgbackrest restore 重建数据目录。

部署与角色

pgBackRest 安装在 所有 PostgreSQL 节点 上，但只有 主库 实际执行备份：

• pg-backup 会自动检测节点角色，从库执行时直接退出。
• 发生 故障切换 后，新主库自动接管备份与归档，备份连续性不受影响。

这使得备份链路与高可用拓扑解耦，避免因主从切换导致备份中断。

仓库与隔离

Stanza（集群标识）

pgBackRest 使用 stanza 隔离不同集群的备份，Pigsty 将其映射为 pg_cluster：

备份仓库
├── pg-meta/
│   ├── backup/
│   └── archive/
└── pg-test/
    ├── backup/
    └── archive/

仓库类型

Pigsty 通过 pgbackrest_method 选择仓库，通过 pgbackrest_repo 定义仓库参数：

生产环境建议使用远程仓库（MinIO/S3），以避免主机故障导致 数据与备份同时丢失。 详见 备份仓库。

配置映射

Pigsty 会将 pgbackrest_repo 定义渲染为 /etc/pgbackrest/pgbackrest.conf。 备份日志位于 /pg/log/pgbackrest/，恢复过程生成临时配置并记录恢复日志。

更多细节请参阅 备份机制。

可观测性

pgbackrest_exporter 会导出备份状态指标（最近备份时间、类型、大小等），默认启用，监听端口 9854。 您可以通过 pgbackrest_exporter_enabled 控制该组件。

相关文档

• 备份机制
• 备份策略
• 备份仓库
• 恢复操作

3 - 时间点恢复的策略权衡

设计 PITR 策略时，最核心的权衡来自三个维度： 备份仓库位置、恢复窗口长度、恢复速度与空间成本。

本文帮助您在这些维度之间做出可操作的选择。

本地 vs 远程

备份仓库的位置是 PITR 策略设计的第一步。

本地仓库

将备份存储在主库本地磁盘（pgbackrest_method = local）：

优势

• 配置简单，开箱即用
• 恢复速度快（本地 I/O）
• 无外部依赖

劣势

• 无异地容灾能力，主机故障时备份可能一同丢失
• 受限于本地磁盘容量
• 备份与生产数据位于同一故障域

远程仓库

将备份存储到 MinIO / S3 等对象存储（pgbackrest_method = minio|s3）：

优势

• 异地容灾，备份独立于数据库主机
• 容量几乎无限，多集群可共享
• 可配合加密、版本控制等安全策略

劣势

• 恢复速度受网络带宽影响
• 依赖对象存储的可用性
• 部署与运维成本更高

如何选择

仓库配置细节请参阅 备份仓库。

空间 vs 窗口

恢复窗口越长，所需存储空间越大。窗口长度由 备份保留策略 + WAL 归档保留 决定。

影响因素

直观示例

假设数据库 100GB，每天变更 10GB：

每日全量备份（保留 2 份）

• 全量备份：100GB × 2 ≈ 200GB
• WAL 归档：10GB × 2 ≈ 20GB
• 总计：约 2～3 倍数据库空间

周全量 + 每日增量（保留 14 天）

• 全量备份：100GB × 2 ≈ 200GB
• 增量备份：约 10GB × 12 ≈ 120GB
• WAL 归档：10GB × 14 ≈ 140GB
• 总计：约 4～5 倍数据库空间

空间与窗口的关系是刚性约束，无法通过配置“同时更长窗口 + 更少空间”。

策略选择

每日全量备份

最简单可靠的策略，也是 Pigsty 本地仓库的默认思路：

• 每天一次全量备份
• 保留 2 份备份
• 恢复窗口约 24～48 小时

适用场景：

• 数据库规模中小（< 500GB）
• 备份窗口充足
• 对存储空间不敏感

全量 + 增量备份

空间优化策略，适合大库或需要更长恢复窗口：

• 每周一次全量备份
• 其他日期执行增量备份
• 保留 14 天

适用场景：

• 数据库规模较大
• 使用对象存储
• 需要 1～2 周恢复窗口

flowchart TD
    A{"数据库大小<br/>< 100GB？"} -->|是| B["每日全量备份"]
    A -->|否| C{"数据库大小<br/>< 500GB？"}
    C -->|否| D["全量 + 增量备份"]
    C -->|是| E{"备份窗口<br/>充足？"}
    E -->|是| F["每日全量备份"]
    E -->|否| G["全量 + 增量备份"]

推荐配置

开发测试环境

pg_crontab:
  - '00 01 * * * /pg/bin/pg-backup full'
pgbackrest_method: local

• 恢复窗口：24～48 小时
• 特点：配置最简，成本最低

生产集群

pg_crontab:
  - '00 01 * * 1 /pg/bin/pg-backup full'
  - '00 01 * * 2,3,4,5,6,7 /pg/bin/pg-backup'
pgbackrest_method: minio

• 恢复窗口：7～14 天
• 特点：异地容灾，适合生产环境

关键业务

双仓库策略（本地 + 远程）：

pgbackrest_method: local
pgbackrest_repo:
  local: { path: /pg/backup, retention_full: 2 }
  minio: { type: s3, retention_full_type: time, retention_full: 14 }

• 本地仓库用于快速恢复
• 远程仓库用于异地容灾

更多配置细节请参阅 备份策略 与 备份仓库。

4 - 时间点恢复的典型场景

PITR 的价值不在于“回滚数据库”本身，而在于把不可逆的人为/软件错误变回可恢复的问题。 它覆盖的场景从“误删一张表”到“整个机房不可用”，本质上解决的是逻辑错误与灾难恢复。

整体认知（Overview）

PITR 解决以下问题：

一个简单的判断原则

• 只要写入已经造成业务错误，就应该考虑 PITR。
• 需要在线验证或只恢复部分数据 → 分支恢复。
• 必须尽快恢复服务 → 原地恢复（可接受停机）。

flowchart TD
    A["发现问题"] --> B{"能否停机？"}
    B -->|能| C["原地恢复<br/>最短恢复路径"]
    B -->|不能| D["分支恢复<br/>先验证后切换"]
    C --> E["恢复成功后重建备份"]
    D --> F["验证/导出/切流量"]

场景详情

误删/误更新数据（DML）

典型问题：

• DELETE 缺少 WHERE
• 错误的 UPDATE 覆盖关键字段
• 批处理脚本逻辑错误导致脏数据扩散

处理思路：

1. 止损：暂停相关应用或写入作业，防止数据继续被污染。
2. 定位时间点：结合日志、监控、业务反馈，确定错误发生时间。
3. 选择策略：
   • 能停机：原地恢复到错误之前
   • 不能停机：分支恢复，导出正确数据再合并回主库

恢复目标建议：

• 有明确事务：xid + exclusive: true
• 仅知道时间：time + exclusive: true

pg_pitr: { xid: "250000", exclusive: true }
# 或
pg_pitr: { time: "2025-01-15 14:30:00+08", exclusive: true }

误删表 / 误删库（DDL）

典型问题：

• DROP TABLE / DROP DATABASE
• 执行了错误迁移脚本
• 清理测试数据时误删生产对象

为何推荐分支恢复：

DDL 操作不可逆，原地恢复意味着全库回滚，风险高。 分支恢复可将误删对象导出并导回原库，影响最小。

推荐流程：

1. 创建分支集群并 PITR 到误删前
2. 校验表结构/数据正确性
3. pg_dump 导出目标对象
4. 导回生产库

sequenceDiagram
    participant O as 原集群
    participant B as 分支集群
    O->>B: 创建分支集群
    Note over B: PITR 到误删之前
    B->>O: 导出表/库并导回
    Note over B: 验证完成后销毁分支

批量错误 / 发布事故

典型问题：

• 某次版本发布写入错误数据
• ETL 或批处理作业造成全量污染
• 修复脚本执行失败或影响范围不清晰

处理原则：

• 优先分支恢复：先验证恢复点，再决定是否切流量
• 对比原库与分支库数据差异，确认影响范围

建议流程：

1. 确定错误发布的时间窗口
2. 分支恢复到“错误发生前”
3. 校验关键业务表
4. 决定导回部分数据，或整体切流量

这个场景通常需要结合业务复盘，因此分支恢复更安全、更可控。

数据审计 / 问题复盘

典型问题：

• 需要查看某一时刻的数据状态
• 排查“历史正确状态”以比对差异

推荐方式：分支恢复（只读）

优点：

• 不影响生产
• 可多次尝试不同时间点
• 适合审计、核对与取证

pg_pitr: { time: "2025-01-15 10:00:00+08" }  # 创建只读分支

机房级灾难 / 全量丢失

这是 PITR 的终极兜底场景。当高可用无法应对时（主从同时不可用、机房断电、勒索攻击），PITR 是最后防线。

关键前提：

必须使用远程仓库（MinIO/S3）。

本地仓库在主机故障时会与数据一同丢失，无法恢复。

恢复流程：

1. 准备新主机或新机房资源
2. 还原集群配置并指向远程仓库
3. 执行 PITR 恢复（通常 latest）
4. 验证数据后恢复服务

./pgsql-pitr.yml -l pg-meta   # 恢复到 WAL 归档末尾

原地恢复 vs 分支恢复

对于绝大多数生产场景，分支恢复是默认推荐策略。 只有在 必须尽快恢复服务 时，才建议原地恢复。

相关文档

• 恢复操作
• 备份机制
• 备份策略