引言

在数据库管理这个领域，备份与恢复可以说是最后一道防线了。PostgreSQL 提供的 pg_dump 和 pg_restore，是逻辑备份领域绕不开的核心工具。和物理备份不太一样，逻辑备份会把数据导出成 SQL 命令或者归档文件，这种形式赋予了它独特的跨版本兼容性和细粒度选择性恢复的能力。无论是做数据迁移，还是搭建开发环境，它都是个很趁手的工具。

第一部分：核心定位——为什么选择逻辑备份？

先得搞清楚一个基础问题：pg_dump 是在线备份工具。它借助 PostgreSQL 的 MVCC（多版本并发控制）机制，导出来的数据库快照具有一致性，而且不会长时间阻塞其他用户的读写操作。

它的核心优势就一个字：灵活。

• 跨版本与跨平台迁移：逻辑备份生成的 SQL 或归档文件，不受底层操作系统和 PostgreSQL 大版本的限制。这是做数据库升级时的首选方案，省心不少。
• 选择性恢复：你可以从全量备份里，只恢复某一个特定的表（-t）或模式（-n）。处理“误删表”这种事故时，这招特别高效，不用动整个数据库。

第二部分：备份策略——选对格式是成功的一半

pg_dump 的输出格式，直接决定了后续用什么样的恢复手段。主要就这三类：

1. 纯文本格式（Plain SQL, -Fp）

这是默认格式，生成一个包含重建数据库所需全部 SQL 命令的 .sql 文件。优点是人类可读，拿 psql 就能直接执行。但缺点也很明显——恢复时没法用并行能力，也不支持选择性恢复。

# 导出纯文本格式，使用INSERT语句替代COPY（用于兼容性比较差的场景）pg_dump -U postgres -Fp --inserts -f backup.sql mydb

2. 自定义格式（Custom, -Fc）

这是生产环境最推荐的格式。生成的是压缩的归档文件，体积小，而且必须配合 pg_restore 使用。这种格式最大的魅力在于，允许你对恢复过程进行“编排”：可以先恢复表结构，再恢复数据，甚至只恢复某一张表。

3. 目录格式（Directory, -Fd）

这种格式会创建一个目录，内部包含多个压缩文件。这是实现并行备份（-j）的前置条件。同样支持 pg_restore 的所有高级功能。

第三部分：性能加速与最佳实践

数据量一大，备份恢复的瓶颈往往就卡在 I/O 和 CPU 上了。下面这几个参数是性能调优的关键。

并行化与压缩

• 并行作业（-j）：在目录格式（-Fd）下，用 -j 参数可以开启多线程并行导出或恢复。建议值通常不超过数据库服务器的 vCPU 核数。
• 关闭压缩（-Z0）：在 pg_dump 阶段，如果服务器 CPU 资源紧张，建议把压缩级别设为 0（不压缩），把 CPU 资源省下来用于数据导出，能提升速度。

生产环境压测前的准备

在生产服务器上跑 pg_dump 会消耗大量资源。从微软 Azure 的实践指南里可以学到几点：

• 清理膨胀表：导出前，检查并清理（VACUUM）死元组过多的表，能显著减小导出体积。
• 使用 PITR 备用服务器：对于海量数据库，建议从生产环境创建一个时间点恢复（PITR）的只读副本，在这个副本上执行 pg_dump，彻底隔离开对主库的性能影响。

第四部分：恢复的艺术——pg_restore 的精细化控制

pg_restore 不仅仅是恢复数据，它更是一个强大的“恢复编排器”。

1. 恢复流程详解

常规恢复分两步：先恢复结构，再恢复数据，或者直接全量恢复。用 -C 参数可以强制在恢复前创建数据库（需要先连接到 postgres 或 template1 数据库）。

# 从自定义格式备份恢复，并自动创建目标数据库pg_restore -h localhost -U postgres -C -d postgres -j 4 mydb_backup.dump

需要留意的是：如果用 -d 指定了目标库名，且开启了 -C，目标库名必须和备份文件中的原始库名一致。这里的 -d 参数只用于发起初始连接。

2. 选择性恢复（TOC 清单）

这是 pg_restore 最强大的功能之一。你可以通过 -l 参数列出归档文件的内容清单（TOC），编辑这个文件后，只恢复指定的对象。

# 1. 导出清单文件pg_restore -l mydb_backup.dump > toc.txt# 2. 编辑 toc.txt，删除你不想恢复的条目行，或取消注释# 3. 仅恢复清单中标记的对象pg_restore -L toc.txt -d target_db mydb_backup.dump

3. 环境参数调优

恢复速度往往比备份要慢，因为需要重建索引和约束。在恢复前，调整目标数据库的以下参数可以带来极致速度：

• maintenance_work_mem：调大这个参数（比如 2GB），能加速索引创建。
• max_parallel_maintenance_workers：允许并行创建索引。
• autovacuum = off：恢复期间建议关闭自动清理，避免不必要的资源争抢。等恢复完成后再开启，并执行 ANALYZE。

第五部分：实战命令速查（可直接复制运行）

场景一：日常全量备份（最推荐）

目标：备份整个数据库，压缩存储，并支持后续任意选择性恢复。

# 使用自定义格式（-Fc），压缩级别中等（-Z6）pg_dump -h localhost -p 5432 -U postgres -Fc -Z6 -f /backup/mydb_$(date +%Y%m%d).dump mydb

• -Fc：自定义格式，必须用 pg_restore 恢复，但体积小且灵活。
• -Z6：压缩级别 1-9，6 是速度和压缩比的平衡点。
• 文件名带日期：方便归档管理。

场景二：超大规模数据库并行备份

目标：利用多核 CPU 加速备份，适用于 TB 级数据。

# 必须先使用目录格式（-Fd）pg_dump -h localhost -U postgres -Fd -j 4 -Z0 -f /backup/mydb_dir mydb

• -Fd：目录格式，备份后生成一个文件夹（/backup/mydb_dir）。
• -j 4：开启 4 个并行线程导出（建议不超过 CPU 核数）。
• -Z0：关闭压缩，把压缩压力从 CPU 转移到磁盘 I/O，通常更快。

场景三：仅备份特定 Schema 或表

目标：只备份 public 模式和 orders 表。

# 只备份 public 模式下的所有对象pg_dump -U postgres -n public -Fc -f public_only.dump mydb# 只备份 orders 和 users 两张表pg_dump -U postgres -t orders -t users -Fc -f tables_only.dump mydb

• -n：指定模式（Schema）。
• -t：指定表，可以重复使用多次。

场景四：全量恢复（最常见）

目标：把自定义格式备份完整恢复到新数据库。

# 第一步：创建空数据库（如果不存在）createdb -U postgres newdb# 第二步：全量恢复（-j 4 并行恢复）pg_restore -h localhost -U postgres -d newdb -j 4 /backup/mydb_20260708.dump

• -d newdb：指定目标数据库。
• -j 4：并行恢复，能大幅缩短恢复时间（仅目录和自定义格式支持）。

场景五：恢复到不同名称的数据库（含自动创建）

目标：从备份中恢复，并自动创建目标数据库，省去手动 createdb 的步骤。

pg_restore -h localhost -U postgres -C -d postgres /backup/mydb_20260708.dump

• -C：恢复时自动创建数据库（数据库名取自备份文件中的原始库名）。
• -d postgres：只用于建立初始连接，实际会创建并恢复到原始库名。

重点：如果备份的是 mydb，这条命令会自动创建 mydb 库并恢复数据。-d postgres 只是一个“跳板”。

场景六：紧急恢复单张表（误删表）

目标：从全量备份中只恢复 employees 表，不动其他数据。

pg_restore -h localhost -U postgres -d mydb -t employees /backup/mydb_20260708.dump

• -t employees：只恢复这张表（及其索引、约束）。
• 如果表已存在，默认会报错，需要先 DROP TABLE employees; 或使用 --clean 参数。

场景七：使用清单文件精细化恢复（高级）

目标：只恢复表结构，不恢复数据，或者只恢复部分对象。

# 1. 导出清单（TOC 目录）pg_restore -l /backup/mydb_20260708.dump > toc.txt# 2. 编辑 toc.txt，在不想恢复的条目前加上分号（注释掉）# 比如只保留所有 "SCHEMA" 和 "TABLE" 条目，删除 "TABLE DATA" 条目# 3. 按修改后的清单恢复pg_restore -L toc.txt -d newdb /backup/mydb_20260708.dump

• 典型用途：只恢复表定义（无数据）用于开发环境模拟，或者跳过某个损坏的索引。

场景八：跨大版本迁移（如 PG 12 → PG 16）

目标：通过逻辑备份无视版本差异迁移数据。

# 在旧库（PG 12）上导出pg_dump -h old_host -U postgres -Fc -f migrate.dump mydb# 在新库（PG 16）上恢复pg_restore -h new_host -U postgres -C -d postgres migrate.dump

不需要任何特殊参数，PostgreSQL 的 pg_restore 会自动处理系统表差异。

场景九：纯 SQL 文本备份（用于脚本或跨数据库迁移）

目标：生成一份可读的 SQL 文件，可用于其他数据库（比如 MySQL 需要手动调整语法）。

# 使用 INSERT 语句而非 COPY（兼容性更强）pg_dump -U postgres -Fp --inserts --column-inserts -f backup.sql mydb

• -Fp：纯文本格式（默认）。
• --inserts：使用 INSERT INTO 替代 COPY，方便跨数据库工具处理。
• --column-inserts：显式列出列名，增强兼容性。

恢复时直接用 psql：

psql -U postgres -d newdb < backup.sql

场景十：恢复前清理旧对象（覆盖恢复）

目标：如果目标库已有同名表，先删除再重建。

pg_restore -h localhost -U postgres -d mydb --clean --if-exists /backup/mydb_20260708.dump

• --clean：恢复前执行 DROP 语句。
• --if-exists：避免对象不存在时报错。

第六部分：最终建议与验证

备份完成后，有个很重要的步骤——模拟恢复一次，验证备份文件是否可用（不实际写数据）：

pg_restore --list /backup/mydb_20260708.dump | head -20

如果能正常打印出归档目录，说明文件头完整，基本可用。

有一点需要特别强调：备份只是数据安全的一半，另一半是定期恢复演练。只有真正在测试环境成功恢复过的备份，才算得上有效的备份。