pg_basebackup是PostgreSQL官方提供的在线物理备份工具，它以整个数据库集群的数据目录为对象，生成一份连续一致的物理副本。与通过SQL导出逻辑对象的备份方式不同，物理备份直接复制数据文件、WAL日志以及配置文件，恢复时只需替换数据目录就能得到一个完整的PostgreSQL实例。这种备份方式特别适合大型数据库、灾难恢复以及快速搭建只读副本。下面通过一张示意图说明物理备份在文件层面的复制关系。

物理备份与逻辑备份的根本差异

逻辑备份最典型的工具是pg_dump，它通过执行SQL查询获取数据库对象的定义和内容，并输出为文本格式或自定义归档格式。恢复时需要重新执行这些SQL语句来重建表、索引、约束等，这在数据量较小时非常灵活，可以选择性恢复某个表或模式。但是逻辑备份不包含数据目录中的物理文件信息，例如表空间路径、复制槽状态、统计信息文件等，因此无法完整还原整个集群的物理环境。

物理备份复制的是数据目录下的所有文件，包括base子目录中的表数据文件、global子目录中的数据库元数据、pg_wal目录中的WAL日志，以及postgresql.conf和pg_hba.conf等配置文件。因为文件层面直接复制，恢复速度远远快于逻辑备份，尤其是在几百GB甚至TB级别的数据库中。物理备份还能保留复制槽、表空间链接等细节，适合用来搭建流复制备库或进行时间点恢复。

执行基础备份时，pg_basebackup会先请求数据库开始一个基础备份点，然后扫描数据目录复制文件。由于备份期间数据库可能仍在写入，单纯复制文件会造成不一致。为此pg_basebackup利用流复制协议同时接收备份期间产生的WAL记录，最终将这些WAL与数据文件合并，得到一致性的快照。这个过程称为在线备份，不需要停库。

使用pg_basebackup进行基础备份

首先确保PostgreSQL的复制功能可用。需要修改pg_hba.conf，添加允许复制连接的规则，例如：

# 在pg_hba.conf中添加
host    replication     all             0.0.0.0/0            md5

同时postgresql.conf需要设置足够数量的max_wal_senders，通常不小于2，以及wal_level至少为replica。完成修改后重启数据库或重新加载配置。这些参数保证了pg_basebackup能够通过复制协议建立连接。

执行基础备份命令的典型形式如下：

pg_basebackup -h 127.0.0.1 -p 5432 -U replica -D /backup/base -Ft -Xs -P -R

参数解释：-h指定主机，-p端口，-U连接用户，-D目标目录，-Ft表示使用tar格式打包（不加t则plain格式直接复制文件），-Xs表示在备份过程中通过流复制接收WAL，与备份数据放在一起，-P显示进度，-R会在备份目录中生成standby.signal并写入primary_conninfo，方便后续直接作为备库启动。

plain格式与tar格式的区别很明显。-Fp（默认）直接复制文件，保持目录结构，适合本地备份或直接替换数据目录。-Ft将数据目录打包成base.tar、pg_wal.tar等tar文件，适合跨主机传输。实际生产中，如果需要直接恢复，plain格式更方便；如果只是临时保存或压缩存储，tar格式更节省空间。注意无论哪种格式，备份都需要在同一个文件系统内完成，防止跨文件系统复制导致权限或硬链接丢失。

备份验证与恢复演练

备份完成后不能直接认为万事大吉，首先要检查目标目录是否包含所有必要文件。PostgreSQL 13及以上版本提供了pg_verifybackup工具，可以对备份进行一致性校验：

pg_verifybackup /backup/base

如果备份是tar格式，需要先解压到临时目录再校验。校验通过说明备份文件与备份结束时数据库的状态一致。对于生产环境，建议每次备份后自动执行一次校验，并将结果记录到监控系统。

恢复步骤相对直接。假设当前数据目录为/var/lib/postgresql/14/main，恢复时先停止服务，然后备份原目录（即使已经损坏也建议保留），清空数据目录，将备份内容复制回去。如果是plain格式，直接cp -a复制；如果是tar格式，先解压。之后修改文件属主为postgres，启动服务。示例：

systemctl stop postgresql
mv /var/lib/postgresql/14/main /var/lib/postgresql/14/main_old
mkdir /var/lib/postgresql/14/main
cp -a /backup/base/* /var/lib/postgresql/14/main/
chown -R postgres:postgres /var/lib/postgresql/14/main
systemctl start postgresql

启动后检查日志，登录数据库执行一些查询确认数据完整。很多团队只在备份成功后就不管了，等到真正需要恢复时才发现备份不可用或者不知道如何操作。建议每季度或每月定期进行恢复演练，将备份恢复到测试环境，验证备份的可用性，同时记录操作步骤，形成文档。

常见问题与最佳实践

最常见的问题是权限不足。pg_basebackup使用的数据库用户必须有REPLICATION权限，否则无法启动复制协议。另一个常见错误是pg_hba.conf配置不对，导致连接被拒绝。还需要注意max_wal_senders的值，如果为0或者过小，备份时会报错。在PostgreSQL 10之前，wal_level需要设置为hot_standby或以上，否则流式备份无法获取WAL。

最佳实践中，将基础备份与WAL归档结合使用，才能真正实现时间点恢复。只有基础备份而没有归档，最多恢复到备份结束那一刻。配置archive_command，将WAL文件持续归档到安全位置。备份策略可以采用每周一次全量基础备份，每天增量归档的方式。同时监控备份目录大小和备份耗时，确保备份窗口不会影响业务。

物理备份适合全实例恢复，但恢复粒度较粗。如果需要恢复单个表或者某几条记录，物理备份无能为力。建议同时保留逻辑备份，例如每天使用pg_dump导出关键表结构或数据。两者结合，物理备份负责快速恢复整个集群，逻辑备份负责细粒度数据修复。通过合理的备份组合，才能让PostgreSQL的数据安全真正得到保障。