播面

pg_dump、pg_dumpall 和 pg_basebackup 都是 PostgreSQL 官方提供的备份工具，但它们在备份原理（逻辑 vs 物理）、备份范围（单库 vs 全局）以及使用场景上有着本质的区别。

以下是这三种工具的详细区别和对比：

1. pg_dump（单库逻辑备份）

• 原理：逻辑备份。它通过执行 SQL 查询来提取数据，并生成可以重建数据库的 SQL 脚本或自定义格式的归档文件。
• 备份范围：单个数据库。它只能备份连接时指定的那个数据库。
• 是否包含全局对象：否。它不会备份角色（用户）、密码、表空间等全局对象，因为这些属于整个数据库集群（Instance），而不是单个数据库。
• 输出格式：支持纯文本（SQL 脚本）、自定义格式（.custom，支持压缩和部分恢复）、目录格式和 Tar 格式。
• 核心优势：
  • 可以跨平台、跨操作系统、跨 PostgreSQL 大版本恢复。
  • 极其灵活，支持只备份特定的表（-t）、排除特定的表（-T）、只备份表结构（-s）或只备份数据（-a）。
• 适用场景：日常备份单个业务数据库、将数据迁移到另一个数据库或新版本、只需要部分表的数据时。

2. pg_dumpall（全集群逻辑备份）

• 原理：逻辑备份。它实际上是 pg_dump 的一个包装器。它会先导出全局对象，然后对集群中的每个数据库依次调用 pg_dump。
• 备份范围：整个 PostgreSQL 集群（所有数据库）。
• 是否包含全局对象：是。它会备份所有的角色（用户）、组、表空间以及所有数据库。
• 输出格式：仅支持纯文本（SQL 脚本）。不支持 pg_dump 那种自定义压缩格式。
• 核心优势：
  • 一次性备份整个实例的所有内容，不用担心遗漏用户权限和表空间。
  • 同样支持跨平台、跨版本恢复。
• 适用场景：PostgreSQL 跨大版本升级（例如从 PG 12 升级到 PG 15）、整体迁移整个数据库服务器到新机器。

3. pg_basebackup（全集群物理备份）

• 原理：物理备份。它不生成 SQL 语句，而是直接在底层复制 PostgreSQL 的数据目录（$PGDATA）和数据文件。它通过流复制协议与数据库通信。
• 备份范围：整个 PostgreSQL 集群（不能只备份单个数据库或单张表）。
• 是否包含全局对象：是（因为是底层文件级别的物理拷贝，所有东西都在里面）。
• 输出格式：纯文件目录拷贝，或者 Tar 归档包。
• 核心优势：
  • 速度极快：恢复时不需要像逻辑备份那样重新执行 SQL 和重建索引，只需解压文件即可，非常适合 TB 级别的超大数据库。
  • 支持 PITR（时间点恢复）：结合 WAL（预写日志），可以把数据库恢复到过去的任意一个时间点。
  • 主备同步：用于快速搭建从库（Standby / Replica）。
• 局限性：
  • 不能跨平台或跨版本：备份的数据文件必须在相同的操作系统架构和相同的 PostgreSQL 大版本上恢复。
• 适用场景：搭建主从复制架构、配置高可用环境、企业级灾备方案（结合 WAL 归档实现数据零丢失和 PITR）。

💡 核心区别对比总结表

🛠️ 生产环境建议：如何选择？

1. 如果你只是想备份/迁移某个业务系统的数据库：
   👉 使用 pg_dump（建议使用 -Fc 自定义格式，方便压缩和灵活恢复）。
2. 如果你要重装服务器或跨大版本升级 PG，且数据量不是特别大：
   👉 使用 pg_dumpall。
3. 如果你要搭建主从复制集群（搭建备库）：
   👉 使用 pg_basebackup。
4. 如果你的数据库非常大（数百GB或TB级），且要求极高的灾难恢复能力（比如要能恢复到昨天下午3点5分）：
   👉 使用 pg_basebackup 进行全量物理备份，并开启 WAL 日志归档（通常配合第三方工具如 pgBackRest 或 WAL-G 使用）。