Source: Dev.to

生产级 PostgreSQL 的 7 种 pg_dump 备份策略

在生产环境中，可靠且可恢复的备份是必不可少的。pg_dump 是 PostgreSQL 官方提供的逻辑备份工具，灵活且易于使用。下面列出 7 种常用的 pg_dump 备份策略，帮助你根据业务需求选择最合适的方案。

---

1. 纯文本（Plain）备份

• 命令

  pg_dump -U <user> -h <host> -p <port> -d <database> > db_backup.sql

• 特点

  • 默认输出为可直接在 psql 中执行的 SQL 脚本。
  • 易于阅读和手动编辑。
  • 不支持并行导出，导出大型数据库时速度较慢。

• 适用场景

  • 小型数据库或需要快速查看备份内容的情况。

---

2. 自定义（Custom）格式备份

• 命令

  pg_dump -U <user> -h <host> -p <port> -d <database> -Fc -f db_backup.dump

• 特点

  • 生成二进制文件，仅能通过 pg_restore 进行恢复。
  • 支持 选择性恢复（单表、单模式等）。
  • 支持压缩（默认 9 级），文件体积更小。

• 适用场景

  • 需要灵活恢复或在 CI/CD 流程中使用的生产环境。

---

3. 目录（Directory）格式备份

• 命令

  pg_dump -U <user> -h <host> -p <port> -d <database> -Fd -j 4 -f /path/to/backup_dir

• 特点

  • 将每个表、每个对象分别存放为独立文件。
  • 与 -j（并行）选项配合，可显著提升大库的导出速度。
  • 同样只能通过 pg_restore 恢复。

• 适用场景

  • 大型数据库、需要并行导出或想要对单个对象进行增量恢复的场景。

---

4. 并行（Parallel）导出

• 命令（适用于自定义或目录格式）

  pg_dump -U <user> -h <host> -p <port> -d <database> -Fd -j 8 -f /backup/dir

• 说明

  • -j <num> 指定并行工作线程数。
  • 仅在 自定义 (-Fc) 或 目录 (-Fd) 格式下有效。

• 收益

  • 对多核机器可将备份时间从数小时缩短至数十分钟。

---

5. 使用压缩（-Z）选项

• 命令（对纯文本或自定义格式均可）

  pg_dump -U <user> -h <host> -p <port> -d <database> -Z 9 -f db_backup.sql.gz

• 特点

  • -Z 后接压缩级别（0‑9），默认 6。
  • 对纯文本备份使用 gzip 压缩，文件体积显著减小。

• 注意

  • 对自定义格式 (-Fc) 已内置压缩，-Z 会被忽略。

---

6. 排除大表或不需要的数据

• 命令

  pg_dump -U <user> -h <host> -p <port> -d <database> \
    --exclude-table-data=public.large_table \
    -Fc -f db_backup_partial.dump

• 用途

  • 当某些表（如日志、审计表）体积庞大且不需要备份时，可使用 --exclude-table-data 只保留结构。
  • 也可以使用 --exclude-table 完全排除表（包括结构）。

• 适用场景

  • 需要快速备份、且对历史数据容忍度高的业务。

---

7. 结合 --no-owner 与 --no-privileges 进行跨环境迁移

• 命令

  pg_dump -U <user> -h <host> -p <port> -d <database> \
    --no-owner --no-privileges -Fc -f db_backup_portable.dump

• 解释

  • --no-owner：在恢复时不尝试创建原始所有者。
  • --no-privileges（或 --no-acl）：不导出权限信息。

• 优势

  • 生成的备份在 不同的用户或角色 环境中更易恢复，适合 开发/测试 环境的快速同步。

---

选择合适的策略

---

小结

• pg_dump 本身已经非常强大，关键在于根据业务需求挑选合适的 输出格式 与 附加选项。
• 对于 生产环境，推荐使用 自定义或目录格式 并配合 并行导出，这样既能保证备份速度，又能在恢复时灵活选择所需对象。
• 记得定期 验证备份（使用 pg_restore --list 或实际恢复到测试库），确保备份可用性。

温馨提示：无论采用哪种策略，都应配合 WAL 归档 与 基于时间点的恢复（PITR），实现完整的灾难恢复方案。

介绍

手动偶尔运行 pg_dump 并不是备份策略——这是一场赌博。生产数据库需要系统化的方法，以考虑数据增长、恢复时间目标和运营现实。业余与生产级备份的区别在于策略：了解 什么、何时、何地、以及 多频繁 创建备份。

1. 计划完整备份与轮换

任何生产环境备份策略的基础都是自动化、计划好的完整备份，并结合智能的轮换策略。这可确保最近的备份始终可用，同时防止存储无限增长。

轮换策略（祖父‑父亲‑儿子）

示例 PowerShell 脚本（每日凌晨 2 点运行）

# daily_backup.ps1
$timestamp = Get-Date -Format "yyyy-MM-dd_HHmmss"
pg_dump -F c -Z 6 -h localhost -U postgres -d production_db -f "backup_$timestamp.dump"

Windows 任务计划程序 – 操作：powershell.exe
参数：-File "C:\backups\scripts\daily_backup.ps1"

没有自动化，备份的一致性就取决于人的记忆——而人在忙碌时期往往会忘记备份，而这正是备份最关键的时候。

2. 部署前安全备份

每一次涉及数据库的部署都应在任何更改执行之前立即触发备份。这为您提供了几分钟前的恢复点，而不是几小时前的。

备份矩阵

示例代码片段

# CI/CD 流水线中的部署前备份
$release   = $env:RELEASE_VERSION
$timestamp = Get-Date -Format "yyyyMMdd_HHmmss"
pg_dump -F c -Z 6 -d production_db -f "pre_deploy_${release}_${timestamp}.dump"

# 迁移前针对特定表的目标备份
pg_dump -F c -d production_db -t users -t orders -f "pre_migrate_critical_tables.dump"

将备份触发器集成到部署流水线中，可消除“有人已经做备份了吗？”的疑问。备份成为一个必需的步骤，直到完成才会放行部署。

3. 大型数据库的并行转储策略

当数据库超过约 50 GB 时，单线程的 pg_dump 可能非常慢。并行转储利用多个 CPU 核心同时转储多个表，在现代多核服务器上可将备份窗口缩短 60‑80 %。使用目录格式（-F d），将备份拆分为每表一个文件。

示例命令

# Parallel dump with 4 workers
pg_dump -F d -j 4 -Z 6 -h localhost -U postgres -d large_db -f backup_dir/

# Parallel restore (matching job count)
pg_restore -F d -j 4 -h localhost -U postgres -d restored_db backup_dir/

# Verify backup directory contents
ls -l backup_dir/
# Expected: toc.dat, 3456.dat.gz, 3457.dat.gz, …

提示： 从 CPU 核心数 – 2 的工作进程数开始（为 PostgreSQL 和操作系统留出余量）。在 16 核服务器上，-j 12 或 -j 14 通常能够在不影响数据库稳定性的前提下最大化吞吐量。

4. Schema‑and‑Data 分离策略

将 schema（模式）备份与 data（数据）备份分离，可实现更快的恢复工作流和更好的版本控制实践。仅模式备份体积很小（千字节），不受数据库大小影响，可与应用代码一起存放在 Git 中。随后可以更频繁地创建仅数据备份，因为它们跳过了相对静态的模式定义。

备份矩阵

示例片段

# 用于版本控制的模式备份
pg_dump -d production_db --schema-only -O --no-privileges -f schema.sql

# 仅数据备份（假设目标恢复环境已有模式）
pg_dump -F c -d production_db --data-only -f data_backup.dump

# 恢复工作流：先恢复模式，再恢复数据
psql -d new_db -f schema.sql
pg_restore -d new_db --data-only data_backup.dump

这种分离在微服务架构中尤为突出——每个服务拥有自己的模式，却共享同一个数据存储。

继续阅读完整指南中的其余三种策略，构建坚如磐石、面向生产的 PostgreSQL 备份方案。

5. 多目标备份策略

将所有备份存放在单一位置会形成单点故障。多目标策略会将备份复制到多个存储系统——本地磁盘用于快速访问，云存储用于异地保护，必要时还可以使用次要区域实现灾难恢复。如果任意单一存储系统出现故障，备份仍可在其他位置获取。

# Backup to local storage first
$backupFile = "backup_$(Get-Date -Format 'yyyyMMdd').dump"
pg_dump -F c -Z 6 -d production_db -f "C:\backups\local\$backupFile"

# Copy to S3 (primary cloud)
aws s3 cp "C:\backups\local\$backupFile" "s3://company-backups/postgres/$backupFile"

# Copy to secondary region (geographic redundancy)
aws s3 cp "C:\backups\local\$backupFile" "s3://company-backups-dr/postgres/$backupFile" --region us-west-2

# Copy to network storage (NAS)
Copy-Item "C:\backups\local\$backupFile" "\\nas\backups\postgres\"

存储层级

• 本地存储 – 对常见恢复场景提供最快的恢复时间。
• 主要云存储 – 针对本地灾难提供异地保护。
• 次要区域 – 实现地理冗余，真正的灾难恢复。

多目标方法会增加复杂性和存储成本，但相较于因相关故障导致的数据丢失风险，这种保护值得投入，尤其是对任何无法承受损失的数据。

6. 选择性表备份策略

并非所有表都需要同等的备份关注。选择性备份策略将关键业务数据放在更频繁的备份中，而对日志表、缓存和临时数据则降低紧迫性。这样可以缩短备份时间、降低存储成本，并且能够更快地恢复真正重要的数据。

# Critical tables – backup every hour
pg_dump -F c -d production_db \
    -t users -t orders -t payments -t subscriptions \
    -f critical_hourly.dump

# Standard tables – backup daily
pg_dump -F c -d production_db \
    -T logs -T sessions -T cache -T analytics_events \
    -f standard_daily.dump

# Exclude large, regenerable tables from full backups
pg_dump -F c -d production_db \
    -T 'public.*_log' -T 'public.*_cache' -T audit_trail \
    -f production_backup.dump

• 确定包含不可替代业务数据的表（例如用户、交易、订单）。
• 将可以重新生成的表（缓存、计算聚合、搜索索引）进行分类。
• 创建分层备份计划，使备份频率与数据关键性相匹配。

该策略需要对数据模型进行前期分析，但能够在更快的备份和更有针对性的恢复流程中收获回报。当灾难发生时，几分钟内恢复关键表远胜于等待数小时完成完整数据库恢复。

7. 加密备份策略

生产备份包含敏感数据——客户信息、财务记录、身份验证凭证。加密备份策略确保即使备份文件被泄露，这些数据仍然受到保护。加密应在备份离开服务器之前完成，而不是在存储时事后才考虑。

# Backup with OpenSSL encryption (AES‑256)
pg_dump -F c -d production_db | \
    openssl enc -aes-256-cbc -salt -pbkdf2 -out backup_encrypted.dump.enc

# Decrypt and restore
openssl enc -d -aes-256-cbc -pbkdf2 -in backup_encrypted.dump.enc | \
    pg_restore -d restored_db

# Using GPG for key‑based encryption
pg_dump -F c -d production_db | \
    gpg --encrypt --recipient backup@company.com -o backup.dump.gpg

将加密密钥与备份文件分开存储——最好放在机密管理器或硬件安全模块中。与备份文件一起存放密钥的加密备份几乎没有实际安全性。记录你的密钥管理流程，并定期测试解密，以免在真正的紧急情况下才发现密钥问题。

更简便的路径：Postgresus

手动实现这七种策略需要大量的脚本编写、调度和监控基础设施。Postgresus 是最流行的 PostgreSQL 备份 工具，通过一个几分钟即可配置的网页界面提供所有这些策略。它能够处理：

• 调度与轮换
• 多目标存储（S3、Google Drive、Dropbox、NAS）
• AES‑256‑GCM 加密
• 实时通知

适用于希望在不管理复杂脚本的情况下获得生产级备份的个人和企业团队。

选择您的策略组合

大多数生产环境受益于组合多种策略，而不是仅依赖单一策略。合适的组合取决于您的数据库规模、恢复时间目标（RTO）以及合规性要求。

以定时全量备份为基础，然后随着需求的演变逐步叠加其他策略。每种策略针对特定的故障模式——它们共同构成深度防御，能够处理从意外删除到数据中心灾难的各种情况。

结论

生产环境级别的 PostgreSQL 备份需要的不仅仅是偶尔执行一次 pg_dump 命令。本文介绍的七种策略——计划的完整备份、部署前的安全备份、并行转储、模式/数据分离、多目标存储、选择性表备份以及加密——涵盖了从日常保护到灾难恢复的全部备份需求。你不必立刻全部实现这七种策略，但经过深思熟虑的组合能够为现代应用提供所需的弹性。

…但你应该有一个明确的计划，说明哪些策略适用于你的情况，以及何时会加入更多策略。
实施恰当备份策略的成本以“小时”为单位衡量；而丢失生产数据的代价则以职业、生意，甚至公司为单位衡量。