把 PostgreSQL 备份导入另一台 VPS 时，pg_restore 可能提示旧角色不存在。先看失败语句是在设置属主，还是在恢复权限，两种报错需要不同的处理。
看失败语句在做什么
从恢复日志找到首个错误。ALTER ... OWNER TO指向属主恢复；GRANT或REVOKE则涉及权限。跳过源属主不会一并跳过原授权。
确认手里的备份格式
对自定义、目录或 tar 归档可用pg_restore -l backup.dump核对目录。纯文本 SQL 用 psql 执行，不能直接套用 pg_restore 参数。先确认归档来自可信来源。恢复会执行其中的 SQL。
根据需求决定保留还是重建
需要保留原权限关系时，先在目标端准备对应角色和成员关系，并使用具备必要权限的账号。允许重新设计属主时，可在事先建好的空测试库执行pg_restore --exit-on-error --no-owner -d restore_test backup.dump。恢复角色仍须具备创建对象的权限。
单独处理旧角色的授权
目标明确要重建授权时，可另加--no-acl跳过归档中的 GRANT 和 REVOKE，再按目标环境补授权。未重建应用权限前，不要切换生产连接。
用应用账号验收权限
可以在萤光云或LightNode的独立数据库恢复并比对对象、行数与扩展，再用应用角色验证预期读写，并确认无权访问的对象仍受限。恢复报错后检查目标是否留下半成品。没有事务保护时，前面成功执行的语句可能已提交。
FAQ
普通 pg_dump 会带全局角色吗？ 不会，角色是集群级对象。
no-owner 会跳过数据吗？ 不会。
no-acl 会补齐新权限吗？ 不会，需要重新授权。
直接对正式库运行 clean 可以吗？ 会删除待恢复对象，应先在隔离库演练。
上游扩展需要提前确认吗？ 需要确认目标环境支持并允许安装。
温馨提示
恢复测试库应与生产库隔离。回放前确认连接目标、备份可读性以及应用账号权限，不要把恢复日志里的敏感连接信息发到公开渠道。
