被提问最多的一些PostgreSQL备份的问题回复

PostgreSQL 的备份前几天有同学问，问了一个问题，说PG的备份特别的慢，我说不会呀？然后引出PG的备份原理，这里我们指的是物理备份,不是pg_dump。

在备份中有一些概念和新版本中的一些特性，并不是使用者都清楚的。比如，如果不用pg_basebackup 命令能不能进行物理备份。答案是当然可以。

PG本身是支持低级API的方式来进行数据库的备份，pg_basebackup仅仅是封装了和流程化了低级API的中我们人工可以进行的手动的操作。

PG_备份原理

PG_备份原理

从上图我们看到，两个函数，在对PG备份的时候，我们执行pg_stat_backup ，来标记备份的起点，期间我们可以去拷贝数据文件，和日志文件等等，在备份结束后，运行pg_stop_backup()来记住备份的终点的位置，并生成backup_label文件，记录备份的起止点，时间线等元数据。

SELECT pg_start_backup('label', true);
-- 执行文件系统级别的备份（如 rsync、tar） -- 复制整个数据目录
SELECT pg_stop_backup();

在这个期间，创建了 backup_label 强制写入检查点 标记wal起点，在执行pg_stop_backup（）会记录wal 终点，并且清理备份的状态。

我记得上次还有人问，归档日志的作用是什么，归档的日志的作用就是基于全部拷贝的文件，之后的日志二者相加后只要日志存在，可以一直将数据库恢复到任意的全备之后的时刻的数据库状态。

但这里我们要强调一点，这里也经常有人问，流式 wal是什么，流式wal的意思是在进行pg备份期间通过pg_basebackup 命令对数据库进行备份时采用 replication的协议，将 wal直接传输到备份目录。

优点也显而易见，除了可以进行备份，对于搭建从节点等也是非常的方便。

日志wal的获取方式差异

日志wal的获取方式差异

那么这里有一个问题，在使用pg_basebackup的命令来备份数据库的时候，我们选择--wal-method 是选择 stream 还是 fetch。

这里我们建议，如果是备份的情况下，我们需要选择 --wal-method=fetch 这样速度会更快，且更稳定

bash
# Stream 模式
pg_basebackup -D /var/lib/postgresql/backups/base_20260116 \
  -Fp -Xs --wal-method=stream -P \
  -U repl_user -h 127.0.0.1 -p 5432

# Fetch 模式
pg_basebackup -D /var/lib/postgresql/backups/base_20260116 \
  -Fp -Xs --wal-method=fetch -P \
  -U repl_user -h 127.0.0.1 -p 5432

两种 wal获取的方式

两种 wal获取的方式

这是一些备份中容易忽略或容易弄错的地方，数据库恢复的PITR的问题。

1 restore_command 要不要配置

有人说要配置，有人说不要配置，这里统一回复，如果你使用了归档，则需要配置，为什么因为你恢复的全量数据库，在wal目录中未必有你所有的恢复需要的wal日志，而如果没有的情况下，你必然是要从归档的目录把需要的wal拉回来。

# postgresql.conf
archive_mode = on
archive_command = 'cp %p /archive/%f'
restore_command = 'cp /archive/%f %p'

所以 restore_command 是必须要配置的。

2 注意版本的差异，在PG11的时候数据库恢复的信息是写入到 recovery.conf里面的，但是到了PG12 -14 以及以后的版本，都写入到postgresql.conf中，并在恢复中产生一个文件recovery.signal 且文件的属相是600.

版本之间的差异如下 PG14

# 在 postgresql.conf 中添加 
recovery_target_time = '2026-01-16 14:00:00' 
restore_command = 'cp /archive/%f %p'
# 放置恢复信号文件 touch $PGDATA/recovery.signal

# postgresql.conf 中添加 
recovery_target_lsn = '0/3000020' 
recovery_target_timeline = 'latest' 
restore_library = 'my_restore_plugin' 
# 启动恢复 touch $PGDATA/recovery.signal

关于一个数据备份恢复的问题，归档到底放哪里的问题，这就与数据归档中的恢复有关，比如你的恢复是从 A 到 B实例，那么你如果是这样的设定，一定不能将归档的信息放置在自己的主机上，必须是一个公用的可访问的磁盘系统。

数据归档的存放地

数据归档存放地

数据归档存放地

比如我们可以使用 AWS的S3作为数据库归档的方式之一。

# postgresql.conf
archive_mode = on
archive_command = 'aws s3 cp %p s3://pg-archive-bucket/%f'
restore_command = 'aws s3 cp s3://pg-archive-bucket/%f %p'

因为如果找不到需要的归档的WAL 系统会报错如下

FATAL: could not restore file "00000001000000000000000A" from archive

pgrman和pgbaserest差异

除此以外备份软件中，还可以考虑pg_probackup, Barman, WAL-G等软件。