pg_dump / pg_restore 常用组合：六条命令与四个坑

pg_dump 的命令行参数有几十个，日常真正用到的就六种组合。把它们记住，比每次翻文档快。

1. 六条命令

# 1) 全库，自定义格式（最常用的备份）
pg_dump -Fc -f db.dump mydb

# 2) 全库，目录格式，并行导出（唯一支持 -j 的格式）
pg_dump -Fd -j 4 -f db.dir mydb

# 3) 只导结构 / 只导数据
pg_dump -s -f schema.sql mydb
pg_dump -a -Fc -f data.dump mydb

# 4) 单表或单 schema
pg_dump -t orders -Fc -f orders.dump mydb
pg_dump -n public -Fc -f public.dump mydb

# 5) 恢复：自定义格式进已有库
pg_restore -d target -Fc db.dump

# 6) 恢复：目录格式并行，先清后建
pg_restore -d target --clean --if-exists -j 4 db.dir

目录格式和自定义格式都能被 pg_restore 选择性恢复：pg_restore -l db.dump 先列出条目，改动后通过 -L 回灌。官方的说法是这两种格式"允许选择与重排归档中的条目，支持并行恢复，且默认压缩"。

2. 四个坑

-j 用错格式。这条报错很直接：

pg_dump: error: parallel backup only supported by the directory format

-j 只在 -Fd 下有效。想并行导出就得接受"目录里一堆文件"这个形态。

目标库不是空的。并行恢复或重复恢复时会撞上已存在的对象：

pg_restore: error: could not execute query: ERROR:  relation "pgbench_accounts" already exists

两个选择：恢复到新库，或者加 --clean --if-exists——不加 --if-exists 时，重跑会刷出一串"对象不存在"的无害报错，把真正的错误淹掉。

owner 和权限带走。在 A 机器上导出的 dump，恢复到 B 机器时可能因为角色不存在而刷错。加 --no-owner --no-acl 可以避免，代价是恢复后要自己补权限。

序列和数据的关系。序列当前值属于数据，-s 只导结构时为 0；恢复到新库后如果不带数据部分，序列需要另设。这也是逻辑复制迁移时"序列不复制"的同一个坑。

3. 验证恢复是否成功

# 先看归档里有什么，再确认行数
pg_restore -l db.dump | head
psql -d target -c "select count(*) from pgbench_accounts;"

本机实测：-Fc 导出一个 200 万行库得到 567,189 字节（gzip 压缩，TOC 16 条），恢复到新库后行数一致；-Fd -j 2 导出目录里 5 个文件。

小结

记住两种格式的分工就不会踩坑：-Fc 是单文件、能选择条目但不能并行；-Fd 是目录、能并行、适合大库。恢复前先决定"覆写还是新库"，覆写就带 --clean --if-exists，新库就确保库是空的。

最后一句：pg_dump 适合迁移和小库备份，不适合大库的常规备份策略——官方文档明确说它在生产环境的定期备份上"通常不是正确选择"，那是物理备份加 WAL 归档的活。

数据来源与检索时间

检索时间 2026-11-10。

核验说明

• 第 1 节的命令语法与第 2 节的两条报错均为本机 18.6 实跑输出；-Fc 体积 567,189 字节、-Fd -j 2 生成 5 个文件、恢复后 200,000 行，都是实际数字。
• 未做：没有测 --no-owner --no-acl 的跨角色恢复（本机只有 postgres 一个角色），这条依据文档；没有测大库（GB 级）的并行恢复耗时。