PostgreSQL pg_dump 怎么恢复？格式、角色与错误中止
拿到 PostgreSQL 备份后，第一步是确认它由什么工具、以什么格式生成，以及准备恢复到哪里。后缀名不能完全代表格式，重命名也不会改变文件内容。本文以 PostgreSQL 16 的逻辑备份为例，恢复操作只针对已确认的独立测试目标。
记录版本和备份范围
核对源服务器、导出客户端和目标服务器的版本，确认目标所需扩展、字符集及运行环境。不要用旧客户端直接读取更高版本服务器，再把失败当作权限问题。跨版本恢复应先做兼容性演练，而不是仅依据 SQL 看起来通用。
pg_dump 主要针对单个数据库，集群级角色等对象需要另外安排。备份中有表和数据，不表示相关登录身份、外部文件和全部应用配置都已包含。pg_dump 官方文档
根据格式选择恢复工具
自定义格式可以由 pg_restore 读取，例如备份时使用 pg_dump -Fc。恢复前可先查看目录清单：
pg_restore --list /srv/backups/site.dump
这个步骤有助于确认对象范围，但不能证明数据已经完整或一定可恢复。普通文本 SQL 则应由 psql 执行，不能把它强行交给 pg_restore。只恢复可信来源的备份，因为其中的定义和语句可能执行具有实际影响的操作。
备份文件、角色口令和连接配置需要限制访问，不应放入网站目录。准备恢复目标前确认剩余空间，逻辑备份压缩后的体积并不等于恢复完成所需的存储。
在空目标中明确所有者策略
假设已经按正确编码与模板准备好空测试库 site_restore，并希望由受控恢复账号持有对象、不沿用旧权限，可以采用如下演练形式：
pg_restore --exit-on-error --no-owner --no-acl --dbname=site_restore /srv/backups/site.dump
--no-owner 和 --no-acl 是本次测试的显式选择，不代表正式恢复应一律丢弃原所有者与授权。需要保留原权限时，应先创建必要角色并检查角色映射；扩展或特殊对象还可能需要额外权限。pg_restore 文档
不要添加清理旧对象的选项后直接对生产库运行。目标名称、连接主机和当前身份都要再次核对，尤其是在管理员电脑保存了多个连接环境时。
错误中止不等于全部自动回滚
--exit-on-error 会在遇到错误时停止继续恢复，但之前已经提交的对象可能仍在。除非采用并满足单事务恢复条件，不能假定一次失败后目标自动回到空库状态。
恢复大数据库时，并行度、单事务方式和锁资源之间有取舍，应先在相近规模环境测量。不要为了提速随意跳过约束、索引或权限错误，否则会得到看似能查询但结构不完整的数据库。
文本 SQL 恢复同样要明确遇错中止，并检查退出状态。失败后保留日志和目标状态，重新准备清楚的测试目标或按验证过的计划处理，不能反复向同一个半成品库叠加恢复。
用业务验证恢复结果
检查对象、关键数据、索引、约束、序列及角色访问，再运行必要的统计信息更新和应用测试。行数相近只说明部分数据存在，不能证明所有关联与应用行为都正确。
测试应用应关闭真实邮件、付款、回调和重复任务，防止恢复演练影响生产。记录读取备份、导入和业务验收的耗时，确认是否满足恢复目标。正式切换前保留原服务与数据；若需要回退，先处理切换后产生的新写入，而不是简单把连接地址改回去。