使用 pg_basebackup + WAL 归档进行备份与 PITR（不使用 pgBackRest）

不安装额外工具，用 PostgreSQL 自带工具做物理备份：用 archive_command 持续归档 WAL，用 pg_basebackup 每晚做 base backup，用 pg_archivecleanup 管理保留期。恢复到指定时间 / 事务 / restore point（recovery.signal、restore_command、recovery_target_*），时间线以及定期恢复演练；最终得到已归档的 WAL、每晚的备份和一条经过验证的恢复路径。替代方案：需要增量/并行/加密备份、S3 和现成的保留期管理时，请看 pgBackRest 指南；迁移表/数据库或找回单个表，请用逻辑备份（pg_dump，不支持 PITR）。

架构: 1 台服务器；流复制或 Patroni 环境下归档目录由所有节点共享 (NFS)

场景

• 配置 WAL 归档和每晚 base backup — 首次部署：用 archive_command 持续归档 WAL、pg_basebackup 脚本、/etc/cron.d 调度、保留期和 WAL 清理。archive_mode 需要一次短暂重启。
• 恢复到指定时间点（PITR：时间、xid、LSN、restore point） — 数据被误删/误改（DROP、DELETE、TRUNCATE），或服务器/磁盘丢失：还原 base backup，并把归档中的 WAL 回放到目标位置。整个集簇停机并回到目标点；目标点之后的变更全部丢失。
• 恢复演练（在单独目录中，不触碰生产库） — 用于证明备份确实可以打开（建议每月一次）：校验最新的 base backup (pg_verifybackup)，解压到单独目录，配合归档在单独端口上启动；测量耗时 (RTO)。不触碰生产库。
• 清理旧的 base backup 和 WAL 归档 — 归档盘或备份盘快满了，或者保留策略发生变化：删除旧的 base backup，用 pg_archivecleanup 删除最旧备份之前的 WAL（先 dry-run）。数据库保持运行。

开始之前

• PostgreSQL … 已安装并正在运行 (pg-install)；数据目录为 …。
• … 和 … 位于与数据盘分离的磁盘/NFS 共享上，并已持久挂载 (fstab)…，且在所有 PostgreSQL 服务器上路径相同（failover 后新 primary 必须写入同一个归档）…。空间：（保留的备份数 + 1）× 压缩后的数据量 + 每日 WAL 量 × 保留天数。
• 没有配置其他归档/备份工具（pgBackRest、Barman、WAL-G）；如果两个工具把同一份 WAL 送到不同位置，两边都会不完整。
• 时钟已通过 NTP 同步（PITR 目标时间按服务器时钟解释）。
• 已为 archive_mode 变更安排了短暂的重启窗口。
• 应用已停止；已确认目标点之后的所有变更都会丢失。… 恢复后需要重建 standby/replica。…

指南阶段

• WAL 归档与 base backup 部署 — 准备归档和备份目录 · 编写 WAL 归档脚本 · 赋予脚本执行权限并测试 · 写入 PostgreSQL 归档参数 · 重启 PostgreSQL · 将归档参数写入 Patroni (edit-config) …
• 恢复演练 — 准备演练目录并选择最新备份 · 解压并校验备份 (pg_verifybackup) · 配合归档启动演练实例 · 验证数据 · 关闭并清理演练实例
• 保留期与 WAL 清理 — 备份、归档大小以及所需的最旧 WAL · 删除保留范围之外的 base backup · 先用 dry-run 显示 WAL 清理 · 清理 WAL 归档 · 确认归档仍在正常工作