当前位置：首页 > news >正文

PostgreSQL备份指南：逻辑与物理备份详解

news 2025/9/2 13:27:13

PostgreSQL 提供了强大且灵活的备份机制，主要分为两大类：逻辑备份 和 物理备份。理解它们的特点和适用场景对于制定可靠的备份恢复策略至关重要。

一、逻辑备份 (Logical Backup)

原理： 备份数据库的逻辑结构和数据本身（如 SQL 语句 CREATE TABLE, INSERT）。它不直接复制磁盘上的文件块。
核心工具：
- pg_dump: 最常用工具，备份单个数据库。
  - pg_dump mydb > mydb.sql: 生成 SQL 脚本文件。
  - pg_dump -Fc mydb > mydb.dump: 生成自定义格式的压缩归档文件（更小更快，需 pg_restore 恢复）。
- pg_dumpall: 备份整个 PostgreSQL 集群（所有数据库），包括全局对象（如用户、角色、表空间定义）。
  - pg_dumpall > alldb.sql: 生成包含全局对象和所有数据库的 SQL 脚本。
优点:
- 可移植性高： SQL 脚本或格式化的转储文件通常可以在不同 PostgreSQL 主版本（甚至有时跨小版本）之间恢复。
- 粒度细： 可以备份/恢复单个数据库、单个表、甚至特定数据。
- 恢复灵活： SQL 脚本可以在任何支持 SQL 的客户端执行；自定义格式归档可用 pg_restore 进行选择性恢复（如表、索引、数据）。
- 备份文件较小： 特别是使用自定义格式 (-Fc) 时，压缩效果通常很好（与原始数据量相比）。
- 无需文件系统级别访问： 通过数据库连接执行。
- 通常不需要超级用户权限： 可以备份用户有访问权限的内容。
缺点：
- 备份/恢复速度较慢： 对于非常大的数据库，生成 SQL 或读取 SQL 执行插入会比较耗时。
- 非时间点恢复： 默认只能恢复到备份完成时刻的状态（除非结合 WAL 归档，见 PITR）。
- 可能阻塞： pg_dump 默认使用 ACCESS SHARE 锁，通常不会阻塞读取，但长时间运行的备份可能与某些 DDL 操作冲突（如 ALTER TABLE）。使用 -j N (并行转储) 或 --snapshot (需要 9.2+, 配合导出快照) 可以改善。
适用场景： 中小型数据库备份、跨版本迁移/升级、需要恢复特定对象或数据的场景、开发/测试环境搭建。

二、物理备份 (Physical Backup / File System Level Backup)

原理： 直接复制 PostgreSQL 存储数据的物理文件（PGDATA 目录及其子目录，如 base/, global/ 等）和相关的表空间文件。本质是磁盘块副本。
核心方法：
1. 简单冷备份 (Offline Backup):
  - 停止 PostgreSQL 服务 (pg_ctl stop)。
  - 使用操作系统命令 (cp, rsync, tar, 文件系统快照如 LVM/ZFS/Btrfs/NTFS VSS) 复制完整的 PGDATA` 目录和所有表空间链接指向的目录。
  - 启动 PostgreSQL 服务 (pg_ctl start)。
  - 缺点： 需要停机时间。
2. 基础热备份 (Online Backup / pg_basebackup):
  - 无需停止数据库。
  - 使用 pg_basebackup 工具（PostgreSQL 9.1+ 核心工具）。
    - 连接到主服务器（或开启了备份模式的备库）。
    - 执行 pg_basebackup -D /path/to/backup_directory -Ft -Xs -P -U replicauser (常用选项示例)。
      - -D: 备份目标目录。
      - -Ft: 生成 tar 格式输出（默认是原样复制文件结构 -Fp）。
      - -Xs: 在备份过程中启用流传输所需的 WAL 文件 (fetch 或 stream，推荐 stream)。
      - -P: 显示进度。
      - -U: 连接用户（需有 REPLICATION 权限或超级用户）。
  - 该工具利用了 PostgreSQL 的流复制协议，创建一个基础备份（data 目录的快照）。
  - 关键： pg_basebackup 备份期间数据库仍可读写。备份完成后，数据目录恢复到一个一致性状态（就像在备份开始时刻冻结了一样）。
优点:
- 速度快： 文件系统级别的复制通常比逻辑导出快得多，尤其对于大型数据库。
- 时间点恢复 (PITR) 的基础： 结合归档的 WAL 日志文件，可以将数据库恢复到基础备份之后的任意时间点（是实现零数据丢失容灾的关键）。
- 备份文件较大： 基本等于数据库文件在磁盘上的大小（加上可能需要的 WAL 归档）。
缺点：
- 可移植性差： 备份文件高度依赖底层文件系统、操作系统和 PostgreSQL 的确切小版本。通常只能在相同或非常相似的环境（大版本一致）中恢复。不能跨大版本恢复。
- 粒度粗： 通常备份/恢复的是整个集群（所有数据库）。选择性恢复特定对象非常困难且容易出错。
- 需要文件系统级别访问： 操作备份文件需要操作系统的权限。
- pg_basebackup 需要配置： 确保连接用户有权限、pg_hba.conf 允许复制连接、wal_level 至少设置为 replica 或 logical。
物理备份的核心：WAL 归档与 PITR
- 物理备份本身通常只能恢复到备份完成时的状态。
- 时间点恢复 (Point-In-Time Recovery - PITR) 允许恢复到基础备份之后的任意事务点（时间戳、特定事务 ID、还原点名称）。这是实现高可用和最小化数据丢失的关键。
- 实现 PITR 的关键步骤：
  1. 启用 WAL 归档 (wal_level = replica或logical): 让 PostgreSQL 在切换 WAL 段文件时将其复制到一个安全的归档位置（archive_command）。
    - archive_command = 'cp %p /path/to/wal_archive/%f' (示例，实际中常用 rsync, scp, 或专用工具上传到云存储)。
  2. 创建基础备份： 使用 pg_basebackup（推荐）或手动创建的热/冷备份。
  3. 持续归档 WAL： 确保在基础备份之后产生的所有 WAL 文件都被安全存档。
  4. 恢复：
    - 停止 PostgreSQL。
    - 清理目标 PGDATA 目录（或新建一个）。
    - 将基础备份复制到 PGDATA。
    - 在 PGDATA 下创建 recovery.signal 文件（PostgreSQL 12+）或 recovery.conf 文件（旧版本），配置恢复参数：
      - restore_command: 指定如何从归档位置获取 WAL 文件 (cp /path/to/wal_archive/%f %p)。
      - recovery_target_time: （可选）指定要恢复到的时间点 (e.g., '2024-04-03 14:30:00 CEST')。
      - recovery_target_name: （可选）指定要恢复到的命名还原点 (pg_create_restore_point('before_important_change'))。
      - recovery_target_inclusive: （可选）控制在指定目标之前还是之后停止。
    - 启动 PostgreSQL。服务器会进入恢复模式：应用基础备份之后的所有归档 WAL 文件，直到达到指定的恢复目标（或没有更多 WAL）。完成后会自动重命名 recovery.signal 并正常启动。
适用场景： 大型数据库备份、要求快速恢复时间 (RTO)、要求最小化数据丢失 (RPO) 达到接近零、作为流复制和高可用集群的基础、灾难恢复。

备份策略建议（结合使用）

定期基础备份 (Physical): 使用 pg_basebackup 每天或每周做一次全量物理备份。
持续 WAL 归档 (Physical): 必须开启并确保可靠性，这是实现 PITR 的核心。
定期逻辑备份 (Logical): 使用 pg_dump 或 pg_dumpall 每天或每周做一次全库或关键库的逻辑备份。这是物理备份的补充，提供更细粒度的恢复选项和额外的安全层（防止物理备份本身的潜在损坏）。
测试恢复： 最重要且最易被忽视的步骤！ 定期（至少每次备份策略变更后）从备份中进行恢复测试演练，验证备份的有效性和恢复流程的可行性。包括测试 PITR 到特定时间点。

其他工具和方案

pgBackRest: 强大的开源备份工具，专为 PostgreSQL 设计。支持全量/增量/差异物理备份、并行备份/恢复、加密、压缩、远程备份操作、集中化管理。非常推荐用于生产环境。
Barman (pgBarman): 另一个流行的开源备份管理器，提供基于 Python 的命令行工具，简化物理备份、WAL 归档和 PITR 流程。
文件系统/存储快照： 如果底层存储（如 LVM, ZFS, btrfs, SAN/NAS 快照功能）支持，可以快速创建 PGDATA 的瞬时一致性快照，然后从这个快照进行备份（可视为一种高效的离线物理备份方法）。需确保 PostgreSQL 处于可安全快照的状态（通常需要 pg_start_backup() / pg_stop_backup() 或利用 pg_basebackup 的协调）。
云托管服务 (RDS, Cloud SQL, Azure DB for PostgreSQL 等): 这些服务通常内置了自动化备份功能（通常结合了物理备份和 PITR），并管理了 WAL 归档。你需要了解服务商的具体 SLA、保留策略和恢复流程。
基于复制的备份： 可以设置一个专用的只读副本（备库），然后在备库上执行 pg_basebackup 或逻辑备份 (pg_dump)，避免影响主库性能。也可以利用备库上的文件系统快照。