压缩等级升高导致备份打不开，主因是pg_dump格式跨版本不兼容：-Fc格式强绑定主版本，跨版本须用-Fp；同一主版本内可调-Z参数，但需验证CPU负载、压缩耗时及恢复解析能力。

压缩等级改高了，备份文件打不开？先看 pg_dump 版本兼容性边界

跨版本恢复失败，八成不是压缩问题，而是 pg_dump 生成的备份格式本身不被目标库识别。瀚高数据库（hgdb）沿用 postgresql 的逻辑备份机制，pg_dump -fp 输出纯 sql 脚本时，压缩等级（如 -z 9）只影响传输/存储体积，不影响内容语义；但若用 -fc（自定义格式），其内部结构与主版本强绑定——v9.2 备份的 .dump 文件，在 v8.6 上执行 pg_restore 会直接报错 unrecognized data block type: 17 或类似 catalog 不匹配提示。

• 同一主版本内（如 HGDB V8.6 → V8.7）可安全调整 -Z 0 到 -Z 9，解压行为由客户端工具决定，不影响恢复逻辑
• 跨主版本（V8 → V9）必须用 -Fp 格式，且目标库需支持源库所有语法（例如 V9 新增的 GENERATED ALWAYS AS IDENTITY 在 V8 中会报错）
• 不要对 -Fc 备份文件手动改后缀或用外部工具解压——pg_restore 依赖其二进制头校验，破坏即不可恢复

生产环境调压缩等级前，必须验证的三件事

压缩等级看似只是 -Z 后面一个数字，但在高并发写入的生产库上，它会实质性影响备份窗口和 I/O 压力。V8.6 默认 -Z 6，若盲目升到 -Z 9，CPU 使用率可能飙升 40%，导致备份期间慢查询堆积、连接数耗尽。

• 查当前负载：SELECT * FROM pg_stat_activity WHERE state = 'active' AND backend_type = 'client backend';，确保无长事务阻塞
• 测压缩耗时：在从库或低峰期用 time pg_dump -Z 9 -Fp -f /tmp/test.sql mydb 对比 -Z 1 耗时，确认是否超出备份窗口容忍阈值
• 验恢复路径：把压缩后的备份拷到目标环境，用 pg_restore -l backup.dump | head -20 检查归档清单能否正常解析，避免恢复时才发现格式异常

跨服务器恢复时，pg_restore 报 “permission denied” 怎么办

这不是权限配置错了，而是备份文件生成时的用户上下文没带过去。HGDB 的 pg_dump 默认以当前连接用户导出对象所有权，若备份时用 hgdb 用户，恢复到另一台服务器时，目标库中若不存在同名角色，pg_restore 会卡在 SET OWNER 步骤并报错 role "hgdb" does not exist，看起来像权限不足。

• 加 --no-owner 参数跳过所有权设置：pg_restore --no-owner --dbname=mydb backup.dump
• 或提前在目标库建好对应角色：CREATE ROLE hgdb WITH LOGIN;，再配好密码和权限
• 绝对不要用 sudo -u postgres pg_restore 强行覆盖——这会导致表归属混乱，后续 DML 可能因权限拒绝而失败

增量备份链断裂？别急着重做全量，先检查归档日志状态

用 pg_dump 做逻辑备份本身不产生归档日志，但很多团队误把物理备份（如 xtrabackup）和逻辑备份混用。如果你依赖的是基于 LSN 的增量方案，而某次 pg_dump 过程中恰好关闭了 archive_mode = on，后续的 pg_restore --incremental（实际是 xtrabackup 的参数，pg_dump 并不支持）就会找不到基础备份点。

• 确认备份类型：file 开头的 .sql 或 .dump 是逻辑备份，没有“增量恢复”概念；只有 xtrabackup 生成的 xbstream 流或目录才支持 --incremental-basedir
• 查归档状态：SELECT pg_is_in_recovery(), current_setting('archive_mode');，确保生产库始终开启归档
• 逻辑备份要做“伪增量”，只能靠时间戳字段 + WHERE updated_at > '2026-03-10' 手动过滤，不能依赖工具自动识别变更

备份压缩等级和跨版本恢复，真正卡住人的从来不是命令怎么写，而是搞不清 pg_dump 和 pg_restore 各自管哪一段——前者只管“怎么存”，后者只管“怎么读”，中间隔着版本、格式、角色三层墙。