印刻数据库

外观

PostgreSQL 备份类型选择 ​

全量备份 ​

全量备份是指备份数据库的完整内容，包括所有表、索引、序列、视图、函数等数据库对象以及它们的数据。

全量备份的特点 ​

  • 优点：

    • 恢复速度快，只需恢复一个备份文件
    • 恢复过程简单，不需要依赖其他备份
    • 备份文件独立完整，不受其他备份影响

  • 缺点：

    • 备份时间长，尤其是对于大型数据库
    • 占用存储空间大
    • 对系统资源消耗大，可能影响生产系统性能

全量备份的实现方式 ​

使用 pg_basebackup 进行物理全量备份 ​

bash
# 基本用法
pg_basebackup -h localhost -U repl -D /backup/$(date +%Y%m%d_%H%M%S) -Ft -z -P

# 使用表空间映射
pg_basebackup -h localhost -U repl -D /backup/$(date +%Y%m%d_%H%M%S) -Ft -z -P -T /tablespace1=/backup/tablespace1 -T /tablespace2=/backup/tablespace2

使用文件系统级备份 ​

bash
# 使用 tar 命令备份数据目录
pg_ctl -D /var/lib/pgsql/13/data stop
 tar -czf /backup/$(date +%Y%m%d_%H%M%S).tar.gz /var/lib/pgsql/13/data
pg_ctl -D /var/lib/pgsql/13/data start

全量备份的适用场景 ​

  • 数据库规模较小，备份时间可接受
  • 对恢复速度要求较高
  • 希望备份文件独立完整，便于管理
  • 作为增量备份或差异备份的基础

增量备份 ​

增量备份是指仅备份自上次备份（可以是全量备份或增量备份）以来更改的数据。

增量备份的特点 ​

  • 优点：

    • 备份时间短，只备份更改的数据
    • 占用存储空间小
    • 对系统资源消耗相对较小

  • 缺点：

    • 恢复过程复杂，需要恢复多个备份文件（基础全量备份 + 所有后续增量备份）
    • 恢复速度慢，需要按顺序应用多个备份
    • 备份依赖关系复杂，某个增量备份损坏可能影响后续所有备份

增量备份的实现方式 ​

使用 pg_basebackup + WAL 归档 ​

bash
# 1. 配置 WAL 归档
# 在 postgresql.conf 中设置
wal_level = replica
archive_mode = on
archive_command = 'cp %p /archive/%f'

# 2. 执行基础全量备份
pg_basebackup -h localhost -U repl -D /backup/base -Ft -z -P

# 3. 定期备份 WAL 归档文件
rsync -a /archive/ /backup/incremental/$(date +%Y%m%d_%H%M%S)/

使用第三方工具 ​

可以使用第三方工具如 Barman、pgBackRest 或 WAL-G 来实现增量备份：

bash
# 使用 pgBackRest 执行增量备份
pgbackrest --stanza=main --log-level-console=info backup --type=incr

增量备份的适用场景 ​

  • 数据库规模较大，全量备份时间过长
  • 对备份窗口要求严格
  • 存储空间有限
  • 希望减少备份对生产系统的影响

差异备份 ​

差异备份是指仅备份自上次全量备份以来更改的数据。

差异备份的特点 ​

  • 优点：

    • 备份时间比全量备份短，比增量备份长
    • 占用存储空间比全量备份小，比增量备份大
    • 恢复过程比增量备份简单，只需恢复基础全量备份 + 最后一个差异备份
    • 恢复速度比增量备份快

  • 缺点：

    • 恢复速度比全量备份慢
    • 随着时间推移，差异备份文件会越来越大
    • 对系统资源消耗比增量备份大

差异备份的实现方式 ​

使用 pgBackRest 执行差异备份 ​

bash
# 执行全量备份作为基础
pgbackrest --stanza=main --log-level-console=info backup --type=full

# 执行差异备份
pgbackrest --stanza=main --log-level-console=info backup --type=diff

使用 Barman 执行差异备份 ​

bash
# 执行全量备份
barman backup main

# 执行差异备份
barman backup main --wait --job-id 1 --type=diff

差异备份的适用场景 ​

  • 数据库规模较大，全量备份时间过长
  • 希望恢复过程比增量备份简单
  • 对恢复速度要求较高，但可以接受比全量备份慢
  • 希望备份依赖关系比增量备份简单

WAL 归档备份 ​

WAL（Write-Ahead Log）归档备份是指备份 PostgreSQL 生成的事务日志，用于时间点恢复（PITR）。

WAL 归档备份的特点 ​

  • 优点：

    • 可以恢复到任意时间点
    • 备份粒度细，最小可以恢复到单个事务
    • 对生产系统影响小，WAL 文件通常较小

  • 缺点：

    • 不能单独使用，需要结合全量备份
    • 恢复过程复杂，需要先恢复全量备份，再应用所有后续 WAL 文件
    • 长时间保留 WAL 文件会占用大量存储空间

WAL 归档备份的配置 ​

sql
-- 在 postgresql.conf 中配置 WAL 归档
wal_level = replica  -- 或 logical
archive_mode = on
archive_command = 'cp %p /archive/%f'  -- 基本配置
-- 更可靠的配置，使用 rsync 和错误检查
archive_command = 'rsync -a %p archive@backup-server:/archive/%f && echo success > /tmp/archive_success'
archive_timeout = 300  -- 每 5 分钟强制切换 WAL 文件，确保及时归档

WAL 归档备份的适用场景 ​

  • 需要时间点恢复能力
  • 希望能够恢复到任意时间点
  • 对数据丢失容忍度低
  • 作为全量备份的补充，提供更细粒度的恢复能力

逻辑备份 ​

逻辑备份是指备份数据库对象的逻辑定义和数据，而不是物理文件。

逻辑备份的特点 ​

  • 优点：

    • 备份文件可读性强，可以直接查看
    • 可以跨版本恢复，支持不同 PostgreSQL 版本之间的迁移
    • 可以选择性备份，只备份特定数据库、表或对象
    • 恢复时可以重新组织数据，优化存储结构

  • 缺点：

    • 备份和恢复速度慢，尤其是对于大型数据库
    • 备份文件通常比物理备份大
    • 恢复时需要重新构建索引和约束，耗时较长
    • 不能恢复到精确的时间点

逻辑备份的实现方式 ​

使用 pg_dump 进行单数据库备份 ​

bash
# 备份整个数据库
pg_dump -h localhost -U postgres -d mydb -F t -f /backup/mydb_$(date +%Y%m%d_%H%M%S).tar

# 只备份特定表
pg_dump -h localhost -U postgres -d mydb -t users -t orders -F t -f /backup/mydb_tables_$(date +%Y%m%d_%H%M%S).tar

# 只备份数据，不备份模式
pg_dump -h localhost -U postgres -d mydb --data-only -F t -f /backup/mydb_data_$(date +%Y%m%d_%H%M%S).tar

使用 pg_dumpall 进行全集群备份 ​

bash
# 备份所有数据库和全局对象
pg_dumpall -h localhost -U postgres -f /backup/all_databases_$(date +%Y%m%d_%H%M%S).sql

逻辑备份的适用场景 ​

  • 需要跨版本迁移数据
  • 只需要备份特定数据库、表或对象
  • 希望备份文件可读性强，便于查看和修改
  • 数据库规模较小，备份和恢复时间可接受
  • 需要在恢复时重新组织数据

备份类型选择策略 ​

选择合适的备份类型需要考虑多种因素，包括数据库规模、备份窗口、恢复时间目标（RTO）、恢复点目标（RPO）、存储空间、系统资源等。

1. 考虑数据库规模 ​

  • 小型数据库（< 100GB）：可以使用全量备份为主，结合 WAL 归档
  • 中型数据库（100GB - 1TB）：可以使用全量备份 + 差异备份，结合 WAL 归档
  • 大型数据库（> 1TB）：建议使用全量备份 + 增量备份，结合 WAL 归档

2. 考虑备份窗口 ​

  • 备份窗口充裕（> 24小时）：可以使用全量备份为主
  • 备份窗口有限（< 8小时）：建议使用增量备份或差异备份
  • 备份窗口非常严格（< 2小时）：必须使用增量备份

3. 考虑恢复时间目标（RTO） ​

  • RTO 要求高（< 1小时）：建议使用全量备份为主
  • RTO 要求中等（1-4小时）：可以使用全量备份 + 差异备份
  • RTO 要求宽松（> 4小时）：可以使用全量备份 + 增量备份

4. 考虑恢复点目标（RPO） ​

  • RPO 要求高（< 5分钟）：必须配置 WAL 归档，结合全量备份
  • RPO 要求中等（5-30分钟）：建议配置 WAL 归档，结合全量备份
  • RPO 要求宽松（> 30分钟）：可以只使用全量备份

5. 考虑存储空间 ​

  • 存储空间充足：可以使用全量备份为主
  • 存储空间有限：建议使用增量备份或差异备份
  • 存储空间紧张：必须使用增量备份

6. 考虑系统资源 ​

  • 系统资源充足：可以使用全量备份为主
  • 系统资源紧张：建议使用增量备份或差异备份

不同版本的备份支持 ​

PostgreSQL 9.6 及以下版本 ​

  • 支持基本的全量备份（pg_basebackup）
  • 支持 WAL 归档，但配置选项相对简单
  • 增量备份和差异备份需要依赖第三方工具
  • 逻辑备份功能相对简单

PostgreSQL 10 及以上版本 ​

  • 增强了 pg_basebackup 功能，支持并行备份
  • 支持更灵活的 WAL 归档配置
  • 引入了逻辑复制，增强了逻辑备份能力
  • 支持更多的备份格式和选项

PostgreSQL 13 及以上版本 ​

  • 进一步增强了 pg_basebackup 功能，支持压缩备份
  • 支持更细粒度的 WAL 归档控制
  • 引入了增量备份的实验性支持
  • 增强了逻辑备份的性能

生产环境最佳实践 ​

1. 采用混合备份策略 ​

  • 定期执行全量备份（如每周一次）
  • 定期执行增量备份或差异备份（如每天一次）
  • 配置 WAL 归档，确保可以进行时间点恢复
  • 根据业务需求调整备份频率

2. 验证备份的完整性和可恢复性 ​

  • 定期测试备份的恢复过程，确保备份可用
  • 使用 pg_verifybackup 工具验证全量备份的完整性
  • 定期检查 WAL 归档文件的完整性

3. 备份存储策略 ​

  • 将备份存储在与生产数据库不同的物理位置
  • 考虑使用异地备份，防止本地灾难
  • 定期将备份复制到离线存储，防止勒索软件攻击
  • 实施备份 retention 策略，定期清理过期备份

4. 监控备份过程 ​

  • 监控备份作业的执行状态
  • 设置备份失败告警
  • 监控备份存储空间使用情况
  • 记录备份执行日志，便于审计

5. 文档化备份策略 ​

  • 详细记录备份策略，包括备份类型、频率、存储位置等
  • 记录恢复过程，便于在灾难发生时快速恢复
  • 定期更新备份文档，反映最新的备份策略

常见问题（FAQ） ​

Q1: 全量备份和增量备份的主要区别是什么？ ​

A1: 全量备份备份数据库的完整内容，恢复简单但备份时间长、占用空间大；增量备份只备份自上次备份以来更改的数据，备份时间短、占用空间小但恢复过程复杂。

Q2: 差异备份和增量备份的主要区别是什么？ ​

A2: 差异备份只备份自上次全量备份以来更改的数据，恢复时只需要基础全量备份 + 最后一个差异备份；增量备份备份自上次备份（可以是全量或增量）以来更改的数据，恢复时需要基础全量备份 + 所有后续增量备份。

Q3: 逻辑备份和物理备份的主要区别是什么？ ​

A3: 物理备份备份数据库的物理文件，恢复速度快但不支持跨版本恢复；逻辑备份备份数据库对象的逻辑定义和数据，支持跨版本恢复但恢复速度慢。

Q4: 如何选择合适的备份类型？ ​

A4: 选择备份类型需要考虑数据库规模、备份窗口、恢复时间目标、恢复点目标、存储空间和系统资源等因素。建议采用混合备份策略，结合全量备份、增量/差异备份和 WAL 归档。

Q5: 备份频率应该如何设置？ ​

A5: 备份频率应该根据业务需求和数据变更频率来设置。一般来说，全量备份可以每周执行一次，增量/差异备份可以每天执行一次，WAL 归档应该持续启用。对于数据变更频繁的系统，可以适当增加备份频率。