PostgreSQL：如何制定备份策略（全量+增量+差异备份）

文章目录

• • 一、备份的基本概念与分类
  • • [1.1 为什么需要备份？](#1.1 为什么需要备份？)
    • [1.2 PostgreSQL 备份类型](#1.2 PostgreSQL 备份类型)
  • [二、核心机制：WAL 与连续归档（Continuous Archiving）](#二、核心机制：WAL 与连续归档（Continuous Archiving）)
  • • [2.1 WAL（Write-Ahead Logging）原理](#2.1 WAL（Write-Ahead Logging）原理)
    • [2.2 连续归档（Continuous Archiving）](#2.2 连续归档（Continuous Archiving）)
  • [三、全量备份：物理 vs 逻辑](#三、全量备份：物理 vs 逻辑)
  • • [3.1 物理全量备份（推荐用于生产）](#3.1 物理全量备份（推荐用于生产）)
    • • 方法一：pg_basebackup（官方工具）
      • 方法二：文件系统快照（LVM/ZFS/Btrfs）
    • [3.2 逻辑全量备份（适用于跨版本迁移或部分表备份）](#3.2 逻辑全量备份（适用于跨版本迁移或部分表备份）)
  • 四、增量与差异备份的实现
  • • [4.1 PostgreSQL 原生方案：WAL 归档即"增量"](#4.1 PostgreSQL 原生方案：WAL 归档即“增量”)
    • [4.2 第三方工具：pgBackRest（推荐）](#4.2 第三方工具：pgBackRest（推荐）)
    • • 架构优势
      • 配置示例（/etc/pgbackrest/pgbackrest.conf）
      • 执行备份
  • 五、备份策略设计（核心）
  • • [5.1 RPO 与 RTO 目标](#5.1 RPO 与 RTO 目标)
    • [5.2 典型策略模板](#5.2 典型策略模板)
    • • [场景 1：中小业务（RPO=1小时，RTO=1小时）](#场景 1：中小业务（RPO=1小时，RTO=1小时）)
      • [场景 2：高要求业务（RPO=5分钟，RTO=15分钟）](#场景 2：高要求业务（RPO=5分钟，RTO=15分钟）)
      • [场景 3：超大数据库（TB 级）](#场景 3：超大数据库（TB 级）)
    • [5.3 保留策略（Retention Policy）](#5.3 保留策略（Retention Policy）)
  • 六、恢复操作详解
  • • [6.1 逻辑备份恢复](#6.1 逻辑备份恢复)
    • [6.2 物理备份 + WAL 恢复（PITR）](#6.2 物理备份 + WAL 恢复（PITR）)
    • • [步骤 1：停止 PostgreSQL](#步骤 1：停止 PostgreSQL)
      • [步骤 2：清理原数据目录](#步骤 2：清理原数据目录)
      • [步骤 3：还原全量备份](#步骤 3：还原全量备份)
      • [步骤 4：创建 recovery.signal](#步骤 4：创建 recovery.signal)
      • [步骤 5：配置 recovery_target（可选）](#步骤 5：配置 recovery_target（可选）)
      • [步骤 6：启动数据库](#步骤 6：启动数据库)
    • [6.3 使用 pgBackRest 恢复](#6.3 使用 pgBackRest 恢复)
  • 七、监控与验证
  • • [7.1 备份监控项](#7.1 备份监控项)
    • [7.2 定期恢复演练](#7.2 定期恢复演练)
    • [7.3 关键视图](#7.3 关键视图)
  • 八、高级技巧与最佳实践
  • • [8.1 使用复制槽（Replication Slot）保护 WAL](#8.1 使用复制槽（Replication Slot）保护 WAL)
    • [8.2 加密与压缩](#8.2 加密与压缩)
    • [8.3 备份到云存储](#8.3 备份到云存储)
    • [8.4 避免常见错误](#8.4 避免常见错误)

PostgreSQL 作为企业级关系型数据库，其数据安全与可恢复性至关重要。制定科学、可靠的备份策略是保障业务连续性的核心环节。

---

一、备份的基本概念与分类

1.1 为什么需要备份？

• 防止人为误操作（DROP TABLE、UPDATE 无 WHERE）
• 应对硬件故障、磁盘损坏
• 满足合规性要求（如 GDPR、等保）
• 支持灾难恢复（DR）与时间点恢复（PITR）

1.2 PostgreSQL 备份类型

类型	工具	原理	是否支持 PITR	是否需停机
逻辑备份	pg_dump / pg_dumpall	导出 SQL 或自定义格式	否（仅到备份时刻）	否
物理全量备份	pg_basebackup / 文件系统快照	拷贝整个数据目录	是（需配合 WAL）	否（热备份）
WAL 归档（增量基础）	archive_command	持续归档 WAL 日志	是	否
差异备份	第三方工具（如 pgBackRest）	基于上次全量的变更页	是	否

注意：PostgreSQL 原生不直接支持"差异备份"或"增量备份"，但可通过 WAL 归档 + 全量备份实现等效的 PITR（时间点恢复），这在效果上等同于"无限粒度的增量"。

---

二、核心机制：WAL 与连续归档（Continuous Archiving）

2.1 WAL（Write-Ahead Logging）原理

• 所有数据变更先写入 WAL 日志，再写入数据文件；
• WAL 保证事务的原子性和持久性；
• 流复制和 PITR 均依赖 WAL。

2.2 连续归档（Continuous Archiving）

通过配置 archive_mode = on 和 archive_command，将已完成的 WAL 文件（16MB/个）复制到安全位置：

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'cp %p /backup/wal/%f'

• %p：WAL 文件完整路径
• %f：WAL 文件名（如 0000000100000000000000A1）

归档 WAL 是实现 PITR 的关键。没有 WAL 归档，物理备份只能恢复到备份结束时刻。

---

三、全量备份：物理 vs 逻辑

3.1 物理全量备份（推荐用于生产）

方法一：pg_basebackup（官方工具）

pg_basebackup -h primary_host -U backup_user \
  -D /backup/full_$(date +%Y%m%d) \
  -Ft -z -P -X stream

• -Ft：输出为 tar 格式
• -z：gzip 压缩
• -X stream：同时流式传输 WAL（避免备份期间 WAL 被清理）

方法二：文件系统快照（LVM/ZFS/Btrfs）

• 几乎零性能影响；

• 需要存储层支持；

• 示例（LVM）：

  lvcreate -L1G -s -n snap_data /dev/vg/data
  mount /dev/vg/snap_data /mnt/snap
  rsync -a /mnt/snap/ /backup/full_$(date +%Y%m%d)/
  umount /mnt/snap
  lvremove /dev/vg/snap_data

物理备份优势：恢复速度快、保留所有内部结构（如 OID）、支持 PITR。

3.2 逻辑全量备份（适用于跨版本迁移或部分表备份）

# 单库备份
pg_dump -h localhost -U postgres -Fc mydb > /backup/mydb_$(date +%Y%m%d).dump

# 全集群备份（含角色、表空间）
pg_dumpall -h localhost -U postgres --globals-only > /backup/globals.sql
pg_dumpall -h localhost -U postgres > /backup/all.sql

• -Fc：自定义格式，支持并行恢复（pg_restore -j）
• 逻辑备份无法恢复到任意时间点，仅能恢复到备份完成时刻。

---

四、增量与差异备份的实现

4.1 PostgreSQL 原生方案：WAL 归档即"增量"

严格来说，PostgreSQL 的增量备份 = 一次物理全量备份 + 持续 WAL 归档。

• 全量备份提供基础数据集；
• WAL 归档记录此后所有变更；
• 恢复时：先还原全量，再重放 WAL 到目标时间点。

因此，无需单独做"每日增量"，只需确保 WAL 归档不间断。

4.2 第三方工具：pgBackRest（推荐）

pgBackRest 是专为 PostgreSQL 设计的备份工具，支持：

• 全量（full）
• 差异（differential）：基于最近一次全量的变更
• 增量（incremental）：基于最近一次任意备份（全量/差异/增量）的变更

架构优势

• 块级校验（checksum）
• 并行压缩与传输
• 备份加密
• 自动 WAL 管理
• 支持本地/远程/云存储

配置示例（/etc/pgbackrest/pgbackrest.conf）

[global]
repo1-path=/backup/pgbackrest
repo1-retention-full=2
start-fast=y
compress-level=3

[mycluster]
pg1-path=/var/lib/pgsql/14/data
pg1-host=pg-primary
pg1-host-user=postgres

执行备份

# 全量
pgbackrest --stanza=mycluster --type=full backup

# 差异（基于最近全量）
pgbackrest --stanza=mycluster --type=diff backup

# 增量（基于最近任意备份）
pgbackrest --stanza=mycluster --type=incr backup

pgBackRest 的差异/增量基于数据文件的 checksum，仅传输变更块，效率远高于原生方案。

---

五、备份策略设计（核心）

5.1 RPO 与 RTO 目标

• RPO（Recovery Point Objective）：可容忍的最大数据丢失量（如 5 分钟）
• RTO（Recovery Time Objective）：可容忍的最大恢复时间（如 30 分钟）

策略需围绕这两个指标制定。

5.2 典型策略模板

场景 1：中小业务（RPO=1小时，RTO=1小时）

• 每日 02:00 执行物理全量备份（pg_basebackup）
• 开启 WAL 归档，每 5 分钟同步一次 WAL 到远程存储
• 保留 7 天全量 + 对应 WAL

场景 2：高要求业务（RPO=5分钟，RTO=15分钟）

• 每周日 02:00 全量（pgBackRest full）
• 周一至周六 02:00 差异备份（diff）
• 每小时增量备份（incr）
• WAL 实时归档（archive_command + rsync to remote）
• 保留 4 周全量 + 差异 + 增量 + WAL

场景 3：超大数据库（TB 级）

• 使用文件系统快照做全量（秒级完成）
• WAL 归档到高速 NAS
• 结合 pgBackRest 做远程压缩备份
• 逻辑备份仅用于关键小表（每日）

5.3 保留策略（Retention Policy）

• 全量：保留 2~4 份
• 差异/增量：保留至下一个全量
• WAL：保留至最老全量所需的时间点之后

pgBackRest 通过 repo1-retention-full 自动清理旧备份及无用 WAL。

---

六、恢复操作详解

6.1 逻辑备份恢复

# 恢复单库
pg_restore -h localhost -U postgres -d mydb -j4 /backup/mydb.dump

# 恢复全局对象
psql -U postgres -f /backup/globals.sql

6.2 物理备份 + WAL 恢复（PITR）

步骤 1：停止 PostgreSQL

sudo systemctl stop postgresql-14

步骤 2：清理原数据目录

rm -rf /var/lib/pgsql/14/data/*

步骤 3：还原全量备份

tar -xzf /backup/full_20260210.tar.gz -C /var/lib/pgsql/14/data

步骤 4：创建 recovery.signal

touch /var/lib/pgsql/14/data/recovery.signal

步骤 5：配置 recovery_target（可选）

在 postgresql.auto.conf 或 postgresql.conf 中添加：

restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2026-02-10 18:30:00'
# 或 recovery_target_xid = '123456'
# 或 recovery_target_name = 'before_deploy'

步骤 6：启动数据库

sudo systemctl start postgresql-14

数据库将重放 WAL 至目标时间点，然后自动转为正常模式（若未设置 standby_mode = on）。

6.3 使用 pgBackRest 恢复

# 恢复到最新
pgbackrest --stanza=mycluster restore

# 恢复到指定时间点
pgbackrest --stanza=mycluster --type=time "--target=2026-02-10 18:30:00" restore

pgBackRest 自动处理 WAL 获取和 recovery 配置。

---

七、监控与验证

7.1 备份监控项

• 备份是否成功（exit code）
• 备份大小是否异常（突增/突减）
• WAL 归档延迟（pg_stat_archiver）
• 磁盘空间使用率

7.2 定期恢复演练

• 每月至少一次在隔离环境执行完整恢复；
• 验证数据一致性（如 checksum 表、业务校验脚本）；
• 记录恢复时间，评估是否满足 RTO。

7.3 关键视图

-- WAL 归档状态
SELECT * FROM pg_stat_archiver;

-- 复制槽（防止 WAL 过早清理）
SELECT * FROM pg_replication_slots;

---

八、高级技巧与最佳实践

8.1 使用复制槽（Replication Slot）保护 WAL

SELECT pg_create_physical_replication_slot('backup_slot');

在 archive_command 中无需担心 WAL 被主库清理，但需监控槽的 lag 避免磁盘爆满。

8.2 加密与压缩

• pgBackRest 支持 AES-256 加密；
• 原生备份可用 gzip/pigz 压缩；
• 逻辑备份可用 pg_dump -Z9。

8.3 备份到云存储

• pgBackRest 支持 S3、Azure、GCS；
• 原生方案可通过 archive_command 调用 aws s3 cp。

8.4 避免常见错误

• 仅做逻辑备份而无 WAL 归档 → 无法 PITR；
• 未测试恢复流程 → 灾难时发现备份无效；
• WAL 归档路径与数据目录同一磁盘 → 磁盘故障导致双丢；
• 未清理旧备份 → 磁盘耗尽。

---

总结：PostgreSQL 备份策略的核心是：

1. 以物理全量备份为基础；
2. 以 WAL 归档为增量手段；
3. 通过 PITR 实现任意时间点恢复；
4. 借助 pgBackRest 等工具提升效率与可靠性。

无论选择原生方案还是第三方工具，都必须：

• 明确 RPO/RTO 目标；
• 自动化备份任务（cron 或 systemd timer）；
• 定期验证恢复能力；
• 将备份与高可用（流复制）结合，形成完整数据保护体系。