# 时间点恢复 —— 数据库的时间机器（PITR） > 高可用解决"机器坏了"，时间点恢复解决"数据错了"。Pigsty 基于 pgBackRest 提供开箱即用的 PITR 能力，让您可以将集群回滚至恢复窗口内的任意时刻，为人为失误与软件缺陷兜底。 --- LLMS index: [llms.txt](/llms.txt) --- > 当您不小心删除了数据、表、甚至整个数据库时，时间点恢复（Point-in-Time Recovery，PITR）让您可以回到过去。 > > —— 这个曾经只有资深 DBA 才能施展的『魔法』，在 Pigsty 的标准配置中零配置开箱即用。 ---------------- ## 复制不是备份 [**高可用**](/docs/concept/ha) 可以在硬件故障时自动切换主库，让服务免于中断。但它有一个天然的盲区：**复制不是备份**。 流复制会以毫秒级的延迟，把主库上发生的一切忠实地同步到所有从库 —— 包括那条忘了加 `WHERE` 的 `DELETE`， 和那句敲错了目标库的 `DROP TABLE`。故障切换应对的是"机器坏了"；而当"数据错了"的时候，每一个副本上的数据都错得整整齐齐。 数据库的灾难大体可以分为这两类。前者靠冗余解决：多个副本、自动切换，这是高可用的职责范围。 后者的唯一解药是 **历史**：基础备份与 WAL 归档让数据库回到错误发生之前。这正是时间点恢复所做的事情。 | 威胁 | [**高可用**](/docs/concept/ha) | [**延迟集群**](/docs/pgsql/config/cluster#延迟集群) | **时间点恢复** | |:-----------------|:---------------------------:|:-------------------------------------------:|:------------:| | 硬件故障，实例宕机 | ✔ 自动切换 | ✘ | ✔ 但 RTO 较长 | | 误删数据 / 误删表 / 误删库 | ✘ 错误被复制 | ✔ 延迟窗口内 | ✔ 恢复窗口内任意时刻 | | 软件缺陷批量污染数据 | ✘ 错误被复制 | ✔ 延迟窗口内 | ✔ 可反复尝试不同时间点 | | 整个集群 / 机房级灾难 | ✘ | ✘ | ✔ 需使用远程备份仓库 | {.full-width} 三者并非互相替代，而是互相补位：高可用负责秒级止血，延迟集群提供快速反悔窗口，而 PITR 是所有防线失守之后的最终兜底。 ---------------- ## 时间机器的原理 PITR 并不神秘。数据库本质上是一台状态机：**基础备份** 是某个时刻状态的完整快照， **WAL**（预写式日志）则是此后每一次状态变更的完整历史。拥有一份快照，再加上从快照开始的完整历史， 就可以把数据库重放到这段历史所覆盖的 **任意时刻** —— 快照决定了您能回到多早，归档的进度决定了您能回到多近。

基础备份 ＋ WAL 归档 ＝ 时间点恢复

这两样原料的生产在 Pigsty 中都是自动编排的：集群初始化时默认尝试执行首次全量备份，主库持续将 WAL 段文件推送至备份仓库归档； 关于快照、历史、恢复目标与时间线的完整模型，请参阅 [**工作原理**](/docs/concept/pitr/mechanism/)。 ---------------- ## 开箱即用 在 Pigsty 的标准配置中，PITR 默认启用：每套 PostgreSQL 集群都带有备份仓库、WAL 归档与恢复工具， 由 [**pgBackRest**](https://pgbackrest.org/) 驱动。您也可以用几行声明式配置对备份策略进行深度定制： ```yaml pg-meta: hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } } vars: pg_cluster: pg-meta pgbackrest_method: minio # 备份写入 Silo / S3 兼容对象存储（默认为 local 本地仓库） pg_crontab: [ '00 01 * * * /pg/bin/pg-backup full' ] # 每天凌晨一点执行全量备份 ``` 默认使用主库本地磁盘作为备份仓库（`/pg/backup`），保留最近两个全量备份；每日全备时，恢复窗口约为 24～48 小时。 切换到专用 [**Silo**](/docs/minio) 集群或外部 S3 对象存储后，备份获得独立于数据库主机的故障域与 AES-256 加密； 按时间保留十四天并每周全备时，恢复窗口约为 14～21 天。只要存储管够，恢复窗口丰俭由人。 恢复同样是声明式的：指定恢复目标，剧本完成停库、还原、重放与重建高可用，业务数据由人验证。 ```bash ./pgsql-pitr.yml -l pg-meta -e '{"pg_pitr": { "time": "2026-07-11 10:00:00+08", "action": "promote" }}' ``` 这个设计与 [**声明式配置**](/docs/concept/iac/) 的理念一脉相承：备份策略是集群定义的一部分， 而"回到过去"也不过是一个 [**参数**](/docs/concept/iac/parameter)。 ---------------- ## 收益与代价 PITR 为数据安全提供的是 **完整性** 与 **可用性** 的跃升： * **RPO**（最大数据损失）：通常降至分钟级，只丢失最后尚未归档的 WAL。 * **RTO**（恢复耗时）：从 ∞（永久丢失）降至几十分钟到几小时，取决于备份大小与磁盘/网络带宽。 | 单实例配置策略 | 事件 | RTO | RPO | |:--------------|:-----------:|:----------------|:-------------------| | 什么也不做 | 主机与本地数据同时丢失 | **永久丢失** | **全部丢失** | | 基础备份 | 主机与本地数据同时丢失 | 取决于备份大小与带宽（几小时） | 丢失上次备份后的数据（几小时到几天） | | 基础备份 + WAL 归档 | 主机与本地数据同时丢失 | 取决于备份大小与带宽（几小时） | 丢失最后尚未归档的数据 | {.full-width} 而它的代价，则主要落在另外三处： * **机密性**：备份本身是额外的数据泄露面，需要加密与访问控制的保护（Pigsty 的远程仓库预设启用 AES-256 加密）。 * **资源**：备份占用存储空间，归档占用网络带宽。zstd 压缩与块级增量可以降低成本，但不能替代容量规划与实测。 * **复杂度**：备份需要管理、监控，以及最容易被忽略的一环 —— 恢复演练。 也要清醒地认识 PITR 的局限：单靠"单机 + PITR"，故障时的 RTO 与 RPO 都显著逊色于高可用集群。 所以在严肃的生产环境中，两者应当组合使用 —— 高可用应对硬件故障，PITR 应对删库跑路。 ---------------- ## 接下来 * [**工作原理**](/docs/concept/pitr/mechanism/)：快照与历史、恢复窗口、恢复目标与时间线 —— 建立 PITR 的心智模型 * [**实现架构**](/docs/concept/pitr/arch/)：pgBackRest 引擎、仓库抽象、归档链路，以及"备份跟随主库"的工程细节 * [**策略权衡**](/docs/concept/pitr/tradeoff/)：故障域、空间与窗口、备份频率 —— 如何为您的场景设计备份策略 * [**声明式恢复**](/docs/concept/pitr/restore/)：`pg_pitr` 参数、`pgsql-pitr.yml` 剧本与 `pig pitr` 命令行工具 * [**典型场景**](/docs/concept/pitr/scenarios/)：误删数据、发布事故、机房灾难 —— 事故发生时如何决策 具体操作手册请参阅任务层文档 [**PGSQL 备份恢复**](/docs/pgsql/backup/)。 --- Section pages: - [时间点恢复的工作原理](/docs/concept/pitr/mechanism/): 快照与历史、恢复窗口、恢复目标与时间线：理解 PITR 的四个核心概念，建立正确的心智模型。 - [时间点恢复的实现架构](/docs/concept/pitr/arch/): Pigsty 以 pgBackRest 为引擎实现 PITR：仓库抽象、归档链路、调度机制，以及"备份跟随主库"的工程设计。 - [时间点恢复的策略权衡](/docs/concept/pitr/tradeoff/): 备份是一份保险：备在哪里决定容灾等级，保留多久决定恢复窗口，多久备一次决定恢复速度 —— 三个问题定义一份备份策略。 - [声明式恢复](/docs/concept/pitr/restore/): 恢复不该是深夜里的十几步手工操作：用 pg_pitr 参数声明想回到的时刻，由 pgsql-pitr.yml 剧本或 pig 命令行工具编排执行。 - [时间点恢复的典型场景](/docs/concept/pitr/scenarios/): 误删数据、发布事故、审计取证、机房灾难 —— 事故发生时如何选择恢复目标与恢复方式，以及为什么要把事故排练成例行演练。