1. 概述

备份是数据库的生命线。PostgreSQL 备份分两大类，理解它们的区别是面试和实战的基础：

对比 MySQL：MySQL 逻辑备份用 mysqldump（对应 pg_dump），物理备份用 Percona XtraBackup（对应 pg_basebackup/pgBackRest）。PG 的 PITR 基于统一的 WAL（见 WAL与检查点机制），而 MySQL 的时间点恢复需结合全量备份 + binlog 重放，机制相似但日志体系不同。

2. 逻辑备份：pg_dump / pg_restore

2.1 pg_dump（单库）

# 自定义格式（推荐！支持并行、压缩、选择性恢复）
pg_dump -U postgres -d mydb -F c -f mydb.dump

# 纯 SQL 格式（可读、可直接 psql 执行）
pg_dump -U postgres -d mydb -f mydb.sql

# 常用选项
pg_dump -d mydb --schema-only  -f schema.sql   # 只结构
pg_dump -d mydb --data-only    -f data.sql     # 只数据
pg_dump -d mydb -t orders -t users -f part.dump # 指定表
pg_dump -d mydb -F d -j 4 -f dumpdir/          # 目录格式 + 4并行(大库快)

格式说明：-F c(custom 自定义)、-F d(directory 目录，支持并行)、-F t(tar)、-F p(plain SQL 默认)。生产推荐 custom 或 directory 格式，因为支持压缩、并行和选择性恢复。

2.2 pg_dumpall（整个实例）

# 备份所有库 + 全局对象（角色、表空间）
pg_dumpall -U postgres -f all.sql
# 只备份全局对象（角色/权限），常与 pg_dump 配合
pg_dumpall --globals-only -f globals.sql

注意：pg_dump 不含角色和权限等全局对象，完整迁移需配合 pg_dumpall --globals-only。这是常见遗漏点。

2.3 恢复

# 恢复 custom/directory 格式（用 pg_restore）
pg_restore -U postgres -d mydb -c mydb.dump          # -c 先清理再恢复
pg_restore -U postgres -d newdb -j 4 mydb.dump       # 并行恢复
pg_restore -d mydb -t orders mydb.dump               # 只恢复某表

# 恢复纯 SQL 格式（直接用 psql）
psql -U postgres -d mydb -f mydb.sql

3. 物理备份：pg_basebackup

复制整个数据目录的字节级副本，适合大库和搭建从库。

pg_basebackup -h localhost -U replicator -D /backup/base -F tar -z -P -X stream
# -F tar 打包  -z 压缩  -P 显示进度  -X stream 同时流式获取备份期间产生的WAL

• 速度快（不解析数据，直接拷文件）。
• 要求恢复端 PG 大版本一致、CPU 架构一致。
• 是搭建流复制从库的标准手段（见 主从复制与高可用）。

4. PITR：时间点恢复（进阶重点）

PITR（Point-In-Time Recovery） = 一份基础物理备份 + 持续归档的 WAL 日志，可恢复到备份之后的任意时刻（如"误删数据前一秒"）。

4.1 开启 WAL 归档

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'   # 归档每个WAL段

4.2 恢复流程

# 1) 停库，用基础备份替换数据目录
# 2) 在数据目录创建 recovery 配置（PG 12+ 用 postgresql.conf + 标志文件）

# postgresql.conf 中设置恢复目标
restore_command = 'cp /archive/%f %p'       # 从归档取回 WAL
recovery_target_time = '2026-07-27 14:30:00' # 恢复到这个时刻（误操作前）

# 3) 创建 recovery.signal 触发恢复，然后启动
touch $PGDATA/recovery.signal
pg_ctl start
# PG 会重放 WAL 到指定时间点后停止

恢复目标还可用 recovery_target_xid（事务号）、recovery_target_lsn、recovery_target_name（还原点）。

5. 备份策略与工具

• 小库：定期 pg_dump（自定义格式）+ 异地存储。
• 大库/关键业务：物理备份 + WAL 归档做 PITR，定期全量 + 持续增量。
• 生产推荐工具：
  • pgBackRest：功能最全，支持增量/差异备份、并行、压缩、加密、云存储、保留策略。
  • Barman：备份管理与 PITR 一体化。
• 3-2-1 原则：3 份副本、2 种介质、1 份异地。
• 定期演练恢复：没验证过的备份等于没有备份。

6. 面试高频问答

Q1：逻辑备份和物理备份的区别？ 逻辑备份（pg_dump）导出 SQL/数据，灵活、可跨版本跨平台、可选表，但大库慢、恢复需重建索引；物理备份（pg_basebackup）拷贝数据文件，快、适合大库，但要求同版本同架构。

Q2：pg_dump 会备份用户和权限吗？ 不会。pg_dump 只备份单个库的对象，角色/权限等全局对象要用 pg_dumpall --globals-only 单独备份，完整迁移需两者配合。

Q3：什么是 PITR？依赖什么实现？ 时间点恢复，依赖一份基础物理备份 + 持续归档的 WAL 日志，重放 WAL 到指定时刻，可恢复到误操作前任意时间点。

Q4：pg_dump 的哪种格式最好？为什么？ custom（-F c）或 directory（-F d）格式，支持压缩、并行备份/恢复、选择性恢复单表；纯 SQL 格式只能整体顺序执行。

Q5：怎么保证备份可靠？ 遵循 3-2-1 原则、开启 WAL 归档做 PITR、用 pgBackRest 等工具管理增量与保留策略，并定期演练恢复验证备份可用。

7. 下一步

学习 主从复制与高可用，构建高可用架构。