开发者在使用 pg_dump 时的十大错误（以及如何避免）
Source: Dev.to
引言
数据库备份是防止数据丢失的最后一道防线，但许多开发者在不知情的情况下用常见的 pg_dump 错误破坏了备份策略。这些错误往往在灾难来临时才被发现——那时已经为时已晚。本文将逐一介绍最常见的陷阱，并展示如何构建坚如磐石的备份工作流。
错误 1：未测试恢复
创建备份却从未验证它们是否真的可以恢复，就像买了保险却不看保单条款。
如何避免
- 在预演环境中定期进行恢复测试。
- 将此过程自动化（至少每月一次）。
- 编写恢复步骤文档，使团队中的任何人都能在紧急情况下执行。
错误 2：对大数据库使用纯文本格式
默认的纯文本 SQL 格式（.sql）会生成巨大的文件，并且不支持并行恢复。对于几 GB 以上的数据库，这意味着备份和恢复时间异常缓慢。
推荐格式
| 格式 | 压缩 | 并行恢复 | 适用场景 |
|---|---|---|---|
Plain (.sql) | 否 | 否 | 小型数据库、版本控制 |
Custom (-Fc) | 是 | 是 | 大多数生产环境 |
Directory (-Fd) | 是 | 是 | 大型数据库、选择性恢复 |
Tar (-Ft) | 否 | 否 | 归档兼容性 |
如何避免
- 对任何大于 1 GB 的数据库使用 custom（
-Fc）或 directory（-Fd）格式。 - 这些格式会自动压缩，并可通过
pg_restore -j <jobs>实现并行恢复。
错误 3：未备份角色、权限或表空间
pg_dump 不会包含数据库角色、权限或表空间定义。在全新服务器上恢复转储时，如果缺少相应的用户，数据库可能无法使用。
如何避免
# 导出全局对象（角色、表空间等）
pg_dumpall --globals-only > globals.sql
# 导出数据库本身
pg_dump -Fc mydb > mydb.dump将这两个文件一起保存，作为备份流程的一部分。
错误 4：在高流量时段运行 pg_dump
在繁忙的主库上执行 pg_dump 可能导致表锁、查询变慢，并产生不一致的快照。
如何避免
- 在低流量窗口安排备份。
- 从只读副本进行转储时使用
--no-synchronized-snapshots。 - 更倾向于对副本而非主库进行备份。
错误 5：包含与目标环境不匹配的所有权和权限信息
在转储中嵌入所有权和权限指令，会在目标环境的用户配置不同（例如在开发、预演和生产之间迁移）时导致恢复失败。
有用的参数
| 参数 | 用途 | 何时使用 |
|---|---|---|
--no-owner | 省略 OWNER TO 命令 | 跨环境恢复 |
--no-privileges | 省略 GRANT/REVOKE 语句 | 权限设置不同的情况 |
--no-comments | 省略 COMMENT 命令 | 更简洁的转储 |
如何避免
- 对可移植的备份使用
--no-owner --no-privileges。 - 在恢复后根据目标环境手动设置相应权限。
错误 6：存储未压缩的备份
未压缩的备份占用大量存储空间，传输时间也更长。一个 50 GB 的数据库压缩后可能只有 5 GB，节省约 10 倍空间。
如何避免
# Custom 格式（默认压缩）
pg_dump -Fc mydb > mydb.dump
# 通过 gzip 管道的纯文本格式
pg_dump mydb | gzip > mydb.sql.gz
# 使用 -Z（0–9）进行最高压缩
pg_dump -Fc -Z 9 mydb > mydb_maxcomp.dump错误 7：忽视仅模式（schema‑only）备份
只备份数据或完整数据库会错失仅模式转储的价值。仅模式备份对于版本控制、文档编写和快速环境搭建非常有用。
如何避免
# 仅模式转储
pg_dump --schema-only -Fc mydb > mydb_schema.dump将模式转储存入版本控制系统，以便随时间追踪数据库演进。
错误 8：在备份脚本中嵌入密码
硬编码密码会产生安全漏洞，并使凭证轮换变得困难。脚本往往会被提交到版本控制，导致敏感信息泄露。
如何避免
- 使用权限为
600的.pgpass文件。 - 使用环境变量 (
PGPASSWORD) 或连接服务文件 (pg_service.conf)。 - 切勿将凭证提交到代码仓库。
# 示例 .pgpass 条目
hostname:port:dbname:username:password
chmod 600 ~/.pgpass错误 9：没有明确的保留策略
无限期保存所有备份会浪费存储和成本，而保存太少又会限制恢复选项。许多团队从未制定保留策略。
如何避免
实施分层保留策略并自动清理：
| 频率 | 保留时长 |
|---|---|
| 每日 | 7 天 |
| 每周 | 4 周 |
| 每月 | 12 个月 |
使用脚本或备份工具按照此计划删除旧文件。
错误 10：依赖手动执行 pg_dump
手动执行不可避免地会出错：有人忘记、休假或误以为别人已经执行。手动流程难以扩展，也无法在团队变动时保持可靠。
如何避免
- 使用 cron、systemd 定时器或专用备份工具实现全自动化。
- 实施监控/告警，在备份失败或未按计划运行时及时通知。
结论
虽然掌握 pg_dump 参数和脚本技巧是可行的，但现代 PostgreSQL 备份工具（例如 Postgresus、pgBackRest）可以消除许多这些陷阱。它们自动处理压缩、调度、保留策略和恢复测试，适用于个人开发者和企业团队。
本列表中的每一个错误都曾导致真实团队的数据丢失。好消息是：这些问题都可以预防。无论是优化你的 pg_dump 脚本，还是采用专用备份方案，关键是构建一个无需时刻关注的可靠系统。测试恢复、自动化流程，切勿在未验证之前假设备份是有效的。