Azure PostgreSQL灵活服务器能否使用pg_dumpall实现备份恢复

你通过排除Azure内置系统库方式生成的pg_dumpall转储文件，可以正常在Azure PostgreSQL灵活服务器上完成恢复，不存在平台层面的兼容性限制，实际操作需要注意以下细节：

导出环节注意事项 #

• 执行导出时必须加--exclude-database=azure_maintenance参数跳过平台专用运维库，建议同时把所有azure_前缀的内置库（比如azure_sys）都加入排除列表，这类库是平台托管运维专用，不存储任何用户业务数据，本身也不对普通用户开放完整读写权限，强行导出只会触发权限报错。
• 导出使用的pg_dumpall客户端版本，必须和源、目标端PostgreSQL大版本完全一致，禁止用高版本客户端导出低版本实例数据，避免出现语法兼容问题。执行导出的账号用Azure默认创建的服务器管理员账号即可，该账号默认拥有所有用户自建库的读取权限，不需要额外提权。
• 导出时建议加上--no-role-passwords参数，因为Azure托管环境下用户没有权限直接修改pg_authid系统表读取密码哈希，加这个参数可以避免导出过程中触发角色密码读取的权限报错。

恢复环节注意事项 #

• 恢复前先手动在目标实例上创建好转储文件里涉及的所有业务登录角色，注意Azure托管环境不支持创建SUPERUSER属性的角色，转储文件里如果出现ALTER ROLE xxx SUPERUSER这类语句，要提前手动删除，否则执行恢复时会直接报权限错误。
• 恢复用psql客户端直连目标实例的postgres库执行即可，参考命令：psql -h <目标实例FQDN> -U <服务器管理员账号> -d postgres -f <本地转储文件路径>。恢复前建议先清空目标实例上的同名业务库，避免对象重名导致的创建冲突。
• 如果源实例启用了PostgreSQL扩展（比如postgis、pg_stat_statements等），需要先在目标实例上手动创建好对应扩展，再执行恢复操作，否则转储里的扩展相关对象会创建失败。
• 恢复完成后建议抽样核对核心业务表的行数、索引、存储过程、权限配置，确认数据完整性。

补充说明 #

Azure官方虽然没有专门针对pg_dumpall方案出支持声明，但本身没有对逻辑备份恢复做任何限制，官方自带的平台级备份属于物理备份，适合整实例时间点恢复场景；pg_dumpall属于逻辑备份，更适合跨大版本迁移、单对象粒度数据找回、长期离线归档这类场景，两者可以搭配使用。

内容的提问来源于stack exchange，提问作者Usman Khawar