2 备份扩展 pg_probackup
2.1 介绍
pg_probackup是一个管理 PostgreSQL 数据库集群备份和恢复的实用程序。它旨在执行 PostgreSQL 实例的定期备份，使您能够在发生故障时恢复服务器。
该实用程序兼容：
-
PostgreSQL 9.6、10、11、12、13、14；
-
与其他备份解决方案相比，pg_probackup提供以下好处，可以帮助您实施不同的备份策略并处理大量数据：
- 增量备份：通过三种不同的增量模式，您可以根据您的数据流来规划备份策略。与进行完整备份相比，增量备份可让您节省磁盘空间并加快备份速度。通过应用增量备份来恢复集群也比通过重放 WAL 文件更快。
- 增量恢复：通过重用 PGDATA 中可用的有效未更改页面来加速从备份恢复。
- 验证：自动数据一致性检查和按需备份验证，无需实际数据恢复。
- 验证：使用checkdb命令 按需验证PostgreSQL实例。
- 保留：根据保留策略管理 WAL 归档和备份。您可以根据恢复时间或要保留的备份数量配置保留策略，以及指定特定备份的生存时间 (TTL)。过期的备份可以合并或删除。
- 并行化：在多个并行线程上 运行backup、 restore、merge、 delete、validate和checkdb进程。
- 压缩：以压缩状态存储备份数据以节省磁盘空间。
- 重复数据删除：如果这些文件在被复制到此增量链中的先前备份之一后没有更改，则通过从增量备份 中排除非数据文件（例如
_vm或）来节省磁盘空间。_fsm - 远程操作：备份 位于远程系统上的 PostgreSQL实例或远程恢复备份。
- 从备用服务器备份：通过从备用服务器进行备份来避免主服务器上的额外负载。
- 外部目录：备份位于PostgreSQL数据目录 (
PGDATA) 之外的文件和目录，例如脚本、配置文件、日志或 SQL 转储文件。 - 备份目录：以纯文本或JSON格式 获取备份列表和相应的元信息 。
- 存档目录：以纯文本或JSON格式 获取所有 WAL 时间线和相应元信息的列表 。
- 部分还原：仅还原指定的数据库。
- Catchup：为落后的备用服务器 克隆PostgreSQL实例以“赶上”主服务器。
-
为了管理备份数据，pg_probackup创建一个 备份目录。这是一个目录，用于存储所有带有附加元信息的备份文件，以及时间点恢复所需的 WAL 存档。您可以将不同实例的备份存储在单个备份目录的不同子目录中。
使用pg_probackup，您可以进行完整或增量 备份：
- 完整备份包含恢复数据库集群所需的所有数据文件。
- 增量备份在页面级别运行，仅存储自上次备份以来更改的数据。与进行完整备份相比，它可以让您节省磁盘空间并加快备份过程。通过应用增量备份来恢复集群也比通过重放 WAL 文件更快。pg_probackup支持以下增量备份模式：
- 增量备份。在这种模式下，pg_probackup读取数据目录中的所有数据文件，并仅复制自上次备份以来发生更改的那些页面。此模式可以施加等于完整备份的只读 I/O 压力。
- 页备份。在这种模式下，pg_probackup从上一次完整或增量备份开始扫描存档中的所有 WAL 文件。新创建的备份仅包含 WAL 记录中提到的页面。这要求自上次备份以来的所有 WAL 文件都存在于 WAL 存档中。如果这些文件的大小与数据库集群文件的总大小相当，加速会更小，但备份仍然占用更少的空间。您必须按照设置连续 WAL 归档以进行 PAGE 备份中的说明配置 WAL 归档。
- PTRACK 备份。在这种模式下，PostgreSQL 动态跟踪页面更改。它的运行不需要连续存档。每次更新关系页面时，都会在特殊的 PTRACK 位图中标记该页面。跟踪意味着数据库服务器操作的一些小开销，但显着加快了增量备份。
pg_probackup只能进行物理在线备份，在线备份需要 WAL 进行一致恢复。因此，无论选择何种备份模式（FULL、PAGE 或 DELTA），使用 pg_probackup进行的任何备份都必须使用以下 WAL 交付模式之一：
2.2 ptrack 支持
PTRACK通过以下选项提供的备份支持：
- 带有ptrack 扩展的 PostgreSQL 11、12、13、14
- Postgres Pro 标准版 11、12、13
- Postgres Pro 企业版 11、12、13
2.3 限制
- pg_probackup当前有以下限制：
- pg_probackup仅支持 PostgreSQL 9.5 及更高版本。
- Windows 系统不支持远程模式。
- 在 Unix 系统上，对于PostgreSQL 10 或更低版本，备份只能由启动PostgreSQL 服务器的同一操作系统用户进行。例如，如果PostgreSQL服务器由 user 启动
postgres，则该backup命令也必须由 user 运行postgres。要在使用 SSH 以远程模式进行备份时满足此要求 ，您必须将--remote-user选项设置为postgres. - 对于PostgreSQL 9.5，只有当备份角色是超级用户时才能运行
pg_create_restore_point(text)和pg_switch_xlog()执行，因此非超级用户角色备份 WAL 流量较低的集群可能比超级用户角色备份同一集群需要更长的时间。 - 从中进行备份的PostgreSQL服务器和恢复的服务器必须与 block_size 和 wal_block_size 参数兼容，并且具有相同的主要版本号。根据集群配置，PostgreSQL本身可能会应用额外的限制，例如 CPU 架构或libc / libicu版本。
2.4 安装和设置
安装
不推荐RPM安装：为什么？用过就知道了。
下载
https://postgrespro.github.io/pg_probackup/#pbk-install-and-setup
yum install --downloadonly --downloaddir=/root pg_probackup-14复制
安装
rpm -ivh pg_probackup-14-2.5.4-1.f4c0ac3bf13a5896c1327d05377862c33951fb90.x86_64.rpm复制
推荐：
cd <path_to_PostgreSQL_source_tree>
git clone https://github.com/postgrespro/pg_probackup contrib/pg_probackup && cd contrib/pg_probackup && make&&make install
查看命令版本
[root@pg14 ~]# pg_probackup version pg_probackup 2.5.5 (PostgreSQL 14.2)复制
查看命令路径
[postgres@pg14 pg14.2]$ which pg_probackup /opt/pgsql/bin/pg_probackup [postgres@pg14 pg14.2]$复制
查看命令帮助
[postgres@pg14 pg14.2]$ pg_probackup help pg_probackup - utility to manage backup/recovery of PostgreSQL database. pg_probackup help [COMMAND] pg_probackup version pg_probackup init -B backup-path pg_probackup set-config -B backup-path --instance=instance_name [-D pgdata-path] [--external-dirs=external-directories-paths] [--log-level-console=log-level-console] [--log-level-file=log-level-file] [--log-filename=log-filename] [--error-log-filename=error-log-filename] [--log-directory=log-directory] [--log-rotation-size=log-rotation-size] [--log-rotation-age=log-rotation-age] [--retention-redundancy=retention-redundancy] [--retention-window=retention-window] [--wal-depth=wal-depth] [--compress-algorithm=compress-algorithm] [--compress-level=compress-level] [--archive-timeout=timeout] [-d dbname] [-h host] [-p port] [-U username] [--remote-proto] [--remote-host] [--remote-port] [--remote-path] [--remote-user] [--ssh-options] [--restore-command=cmdline] [--archive-host=destination] [--archive-port=port] [--archive-user=username] [--help] pg_probackup set-backup -B backup-path --instance=instance_name -i backup-id [--ttl=interval] [--expire-time=timestamp] [--note=text] [--help] pg_probackup show-config -B backup-path --instance=instance_name [--format=format] [--help] pg_probackup backup -B backup-path -b backup-mode --instance=instance_name [-D pgdata-path] [-C] [--stream [-S slot-name] [--temp-slot]] [--backup-pg-log] [-j num-threads] [--progress] [--no-validate] [--skip-block-validation] [--external-dirs=external-directories-paths] [--no-sync] [--log-level-console=log-level-console] [--log-level-file=log-level-file] [--log-filename=log-filename] [--error-log-filename=error-log-filename] [--log-directory=log-directory] [--log-rotation-size=log-rotation-size] [--log-rotation-age=log-rotation-age] [--no-color] [--delete-expired] [--delete-wal] [--merge-expired] [--retention-redundancy=retention-redundancy] [--retention-window=retention-window] [--wal-depth=wal-depth] [--compress] [--compress-algorithm=compress-algorithm] [--compress-level=compress-level] [--archive-timeout=archive-timeout] [-d dbname] [-h host] [-p port] [-U username] [-w --no-password] [-W --password] [--remote-proto] [--remote-host] [--remote-port] [--remote-path] [--remote-user] [--ssh-options] [--ttl=interval] [--expire-time=timestamp] [--note=text] [--help] pg_probackup restore -B backup-path --instance=instance_name [-D pgdata-path] [-i backup-id] [-j num-threads] [--recovery-target-time=time|--recovery-target-xid=xid |--recovery-target-lsn=lsn [--recovery-target-inclusive=boolean]] [--recovery-target-timeline=timeline] [--recovery-target=immediate|latest] [--recovery-target-name=target-name] [--recovery-target-action=pause|promote|shutdown] [--restore-command=cmdline] [-R | --restore-as-replica] [--force] [--primary-conninfo=primary_conninfo] [-S | --primary-slot-name=slotname] [--no-validate] [--skip-block-validation] [-T OLDDIR=NEWDIR] [--progress] [--external-mapping=OLDDIR=NEWDIR] [--skip-external-dirs] [--no-sync] [-I | --incremental-mode=none|checksum|lsn] [--db-include | --db-exclude] [--remote-proto] [--remote-host] [--remote-port] [--remote-path] [--remote-user] [--ssh-options] [--archive-host=hostname] [--archive-port=port] [--archive-user=username] [--help] pg_probackup validate -B backup-path [--instance=instance_name] [-i backup-id] [--progress] [-j num-threads] [--recovery-target-time=time|--recovery-target-xid=xid |--recovery-target-lsn=lsn [--recovery-target-inclusive=boolean]] [--recovery-target-timeline=timeline] [--recovery-target-name=target-name] [--skip-block-validation] [--help] pg_probackup checkdb [-B backup-path] [--instance=instance_name] [-D pgdata-path] [--progress] [-j num-threads] [--amcheck] [--skip-block-validation] [--heapallindexed] [--checkunique] [--help] pg_probackup show -B backup-path [--instance=instance_name [-i backup-id]] [--format=format] [--archive] [--no-color] [--help] pg_probackup delete -B backup-path --instance=instance_name [-j num-threads] [--progress] [--retention-redundancy=retention-redundancy] [--retention-window=retention-window] [--wal-depth=wal-depth] [-i backup-id | --delete-expired | --merge-expired | --status=backup_status] [--delete-wal] [--dry-run] [--no-validate] [--no-sync] [--help] pg_probackup merge -B backup-path --instance=instance_name -i backup-id [--progress] [-j num-threads] [--no-validate] [--no-sync] [--help] pg_probackup add-instance -B backup-path -D pgdata-path --instance=instance_name [--external-dirs=external-directories-paths] [--remote-proto] [--remote-host] [--remote-port] [--remote-path] [--remote-user] [--ssh-options] [--help] pg_probackup del-instance -B backup-path --instance=instance_name [--help] pg_probackup archive-push -B backup-path --instance=instance_name --wal-file-name=wal-file-name [--wal-file-path=wal-file-path] [-j num-threads] [--batch-size=batch_size] [--archive-timeout=timeout] [--no-ready-rename] [--no-sync] [--overwrite] [--compress] [--compress-algorithm=compress-algorithm] [--compress-level=compress-level] [--remote-proto] [--remote-host] [--remote-port] [--remote-path] [--remote-user] [--ssh-options] [--help] pg_probackup archive-get -B backup-path --instance=instance_name --wal-file-path=wal-file-path --wal-file-name=wal-file-name [-j num-threads] [--batch-size=batch_size] [--no-validate-wal] [--remote-proto] [--remote-host] [--remote-port] [--remote-path] [--remote-user] [--ssh-options] [--help] pg_probackup catchup -b catchup-mode --source-pgdata=path_to_pgdata_on_remote_server --destination-pgdata=path_to_local_dir [--stream [-S slot-name] [--temp-slot | --perm-slot]] [-j num-threads] [-T OLDDIR=NEWDIR] [--exclude-path=path_prefix] [-d dbname] [-h host] [-p port] [-U username] [-w --no-password] [-W --password] [--remote-proto] [--remote-host] [--remote-port] [--remote-path] [--remote-user] [--ssh-options] [--help] Read the website for details. <https://github.com/postgrespro/pg_probackup> Report bugs to <https://github.com/postgrespro/pg_probackup/issues>.复制
设置
安装pg_probackup 后，完成以下设置：
- 初始化备份目录。
- 将新的备份实例添加到备份目录。
- 配置数据库集群以启用pg_probackup备份。
- 或者，配置 SSH 以在远程模式下 运行pg_probackup操作。
初始化备份目录
pg_probackup将所有 WAL 和备份文件存储在备份目录的相应子目录中。
要初始化备份目录，请运行以下命令：
pg_probackup init -B /pgdata/pg_probackup复制
backup_dir 备份目录的路径在。如果*backup_dir*已经存在，则必须为空。否则，pg_probackup返回错误。
启动pg_probackup的用户必须具有对该目录的完全访问权限。
pg_probackup创建*backup_dir*备份目录，包含以下子目录：
wal/— WAL 文件的目录。backups/— 备份文件的目录。
初始化备份目录后，您可以添加新的备份实例。
添加新的备份实例
pg_probackup可以将多个数据库集群的备份存储在单个备份目录中。要设置所需的子目录，您必须将备份实例添加到要备份的每个数据库集群的备份目录中。
要添加新的备份实例，请运行以下命令：
pg_probackup add-instance -B backup_dir -D data_dir --instance instance_name[ remote_options]复制
- *
data_dir*是您要备份的集群的数据目录。要设置和使用 pg_probackup，需要对该目录的写入权限。 - *
instance_name*是将存储此集群的 WAL 和备份文件的子目录的名称 - remote_options*
data_dir*是可选参数，仅当位于远程系统上 时才需要指定 。
pg_probackup在备份目录的和目录下创建*instance_name* 子目录。该 目录包含控制此备份实例的pg_probackup设置的配置文件 。如果您使用 remote_options运行此命令，指定的参数将被添加到. backups/``wal/``backups/*instance_name*``pg_probackup.conf``pg_probackup.conf
启动pg_probackup的用户必须具有对 backup_dir目录的完全访问权限，并且至少具有对目录的只读访问权限data_dir。如果在环境变量中指定备份目录的路径，则 可以在运行pg_probackup 命令 BACKUP_PATH时省略相应的选项。
笔记
对于PostgreSQL 11 或更高版本，建议使用 allow-group-access 功能，以便与集群所有者在同一组中的任何 OS 用户都可以进行备份。在这种情况下，用户应该具有集群目录的读取权限。
配置数据库集群
尽管pg_probackup可由超级用户使用，但建议创建一个具有所选备份策略所需的最低权限的单独角色。在这些配置说明中，以backup角色为例。
要执行备份，仅在用于连接到PostgreSQL服务器 backup的数据库中需要角色的以下权限：
对于PostgreSQL 9.5：
BEGIN; CREATE ROLE backup WITH LOGIN; GRANT USAGE ON SCHEMA pg_catalog TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.current_setting(text) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.set_config(text, text, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_is_in_recovery() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_start_backup(text, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_stop_backup() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_create_restore_point(text) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_xlog() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_current() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_current_snapshot() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_snapshot_xmax(txid_snapshot) TO backup; COMMIT;复制
对于PostgreSQL 9.6：
BEGIN; CREATE ROLE backup WITH LOGIN; GRANT USAGE ON SCHEMA pg_catalog TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.current_setting(text) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.set_config(text, text, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_is_in_recovery() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_start_backup(text, boolean, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_stop_backup(boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_create_restore_point(text) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_xlog() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_last_xlog_replay_location() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_current() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_current_snapshot() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_snapshot_xmax(txid_snapshot) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_control_checkpoint() TO backup; COMMIT;复制
对于PostgreSQL 10 或更高版本：
BEGIN; CREATE ROLE backup WITH LOGIN; GRANT USAGE ON SCHEMA pg_catalog TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.current_setting(text) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.set_config(text, text, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_is_in_recovery() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_start_backup(text, boolean, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_stop_backup(boolean, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_create_restore_point(text) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_wal() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_last_wal_replay_lsn() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_current() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_current_snapshot() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_snapshot_xmax(txid_snapshot) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_control_checkpoint() TO backup; COMMIT;复制
设置 STREAM 备份
要为 STREAM 备份设置集群，请完成以下步骤：
- 将 REPLICATION 权限授予备份角色：
ALTER ROLE backup WITH REPLICATION；复制
-
在 pg_hba.conf 文件中，允许代表备份角色进行复制。
-
确保参数 max_wal_senders 设置得足够高，以使至少一个会话可用于备份过程。
-
将参数 wal_level 设置为高于最小值。
如果您计划在 STREAM 模式下进行 PAGE 备份或使用 STREAM 备份执行 PITR，您仍然必须配置 WAL 归档，如设置连续 WAL 归档部分所述。
完成这些步骤后，您可以开始在 STREAM WAL 模式下进行 FULL、PAGE、DELTA 和 PTRACK 备份。
笔记
如果您计划在 STREAM 模式下运行备份时依赖 .pgpass 进行身份验证，则 .pgpass 必须包含复制数据库的凭据，用于通过复制协议建立连接。示例：pghost:5432:replication:backup_user:my_strong_password
设置连续 WAL 归档
在 PAGE 备份模式下进行备份、执行 PITR 和使用 ARCHIVE WAL 交付模式进行备份需要启用连续 WAL 归档。要在集群中设置连续归档，请完成以下步骤：
-
确保 wal_level 参数高于最小值。
-
如果您在 master 上配置归档，archive_mode 必须设置为 on 或 always。要在待机状态下执行归档，请将此参数设置为 always。
-
设置archive_command参数，如下：
archive_command = ''install_dir/pg_probackup' archive-push -B 'backup_dir' --instance instance_name --wal-file-name=%f [remote_options]'复制
其中 install_dir 是你将要使用的 pg_probackup 版本的安装目录，backup_dir 和 instance_name 指的是已经为这个数据库集群初始化的备份目录实例，而 remote_options 只需要指定在远程主机上归档 WAL。有关所有可能的归档推送参数的详细信息，请参阅archive-push 部分。
完成这些步骤后，您可以开始在 ARCHIVE WAL 模式下进行备份，在 PAGE 备份模式下进行备份，以及执行 PITR。
您可以使用 show 命令查看 WAL 归档的当前状态。有关详细信息，请参阅名为“查看 WAL 存档信息”的部分。
如果您计划在生成少量 WAL 流量的备用服务器上使用 ARCHIVE WAL 模式进行 PAGE 备份和/或备份，而无需长时间等待 WAL 段填满，请考虑在 master 上设置 archive_timeout PostgreSQL 参数。此参数的值应略低于 --archive-timeout 设置（默认为 5 分钟），以便在中止备份之前有足够的时间将旋转段流式传输到备用并发送到 WAL 存档，因为 --archive-timeout。
设置从待机备份
对于 PostgreSQL 9.6 或更高版本，pg_probackup 可以从备用服务器进行备份。这需要以下附加设置：
-
在备用服务器上，将 hot_standby 参数设置为 on。
-
在主服务器上，将 full_page_writes 参数设置为 on。
-
要在待机状态下执行独立备份，请完成设置 STREAM 备份部分中的所有步骤。
-
要在待机状态下执行存档备份，请完成设置连续 WAL 存档部分中的所有步骤。
完成这些步骤后，您可以开始从备用服务器以适当的 WAL 交付模式进行 FULL、PAGE、DELTA 或 PTRACK 备份：ARCHIVE 或 STREAM。
从备用服务器备份有以下限制：
-
如果在备份期间将备用服务器提升为主服务器，则备份将失败。
-
备份所需的所有 WAL 记录必须包含足够的整页写入。这要求您在 master 上启用 full_page_writes，并且不要使用 pg_compresslog 之类的工具作为 archive_command 从 WAL 文件中删除整页写入。
设置集群验证
数据库集群的逻辑验证需要以下额外设置。以角色备份为例：
- 在集群的每个数据库中安装 amcheck 或 amcheck_next 扩展：
CREATE EXTENSION amcheck;复制
- 为集群的每个数据库中的备份角色授予以下权限：
GRANT SELECT ON TABLE pg_catalog.pg_am TO backup; GRANT SELECT ON TABLE pg_catalog.pg_class TO backup; GRANT SELECT ON TABLE pg_catalog.pg_database TO backup; GRANT SELECT ON TABLE pg_catalog.pg_namespace TO backup; GRANT SELECT ON TABLE pg_catalog.pg_extension TO backup; GRANT EXECUTE ON FUNCTION bt_index_check(regclass) TO backup; GRANT EXECUTE ON FUNCTION bt_index_check(regclass, bool) TO backup;复制
设置部分还原
如果您计划使用部分还原，请完成以下附加步骤：
- 仅将 pg_catalog.pg_database 的只读访问权限授予用于连接到 PostgreSQL 服务器的数据库中的备份角色：
GRANT SELECT ON TABLE pg_catalog.pg_database TO backup；复制
配置远程模式
pg_probackup 支持远程模式，允许远程执行备份、恢复和 WAL 归档操作。在这种模式下，备份目录存储在本地系统上，而要备份和/或恢复的 PostgreSQL 实例位于远程系统上。目前唯一支持的远程协议是 SSH。
Set up SSH
如果您打算通过 SSH 在远程模式下使用 pg_probackup，请完成以下步骤：
- 在两个系统上安装 pg_probackup：backup_host 和 db_host。
- 对于主机之间的通信，请在 backup_host 上的备份用户和 db_host 上的 postgres 用户之间设置无密码 SSH 连接：
[backup@backup_host] ssh-copy-id postgres@db_host复制
- 如果您要依赖连续 WAL 归档，请在 db_host 上的 postgres 用户和 backup_host 上的备份用户之间设置无密码 SSH 连接：
[postgres@db_host] ssh-copy-id backup@backup_host复制
where：
-
backup_host 是具有备份目录的系统。
-
db_host 是带有 PostgreSQL 集群的系统。
-
backup 是用于运行 pg_probackup 的 backup_host 上的操作系统用户。
-
postgres 是 db_host 上用于启动 PostgreSQL 集群的操作系统用户。对于 PostgreSQL 11 或更高版本，由于允许组访问功能，可以使用更安全的方法。
通过 SSH 在远程模式下的 pg_probackup 工作如下：
-
在远程模式下只能启动以下命令：add-instance、backup、restore、catchup、archive-push 和archive-get。
-
在远程模式下操作需要在本地和远程系统上安装 pg_probackup 二进制文件。本地和远程二进制文件的版本必须相同。
-
在远程模式下启动时，本地系统上的主 pg_probackup 进程通过 SSH 连接到远程系统，并在远程系统上启动一个或多个代理进程，这些代理进程称为远程代理。远程代理的数量等于 -j/–threads 设置。
-
主要的 pg_probackup 进程使用远程代理来访问远程文件并在本地和远程系统之间传输数据。
-
远程代理尝试最小化网络流量和主机之间的往返次数。
-
主进程通常在 backup_host 上启动并连接到 db_host，但在 archive-push 和 archive-get 命令的情况下，主进程在 db_host 上启动并连接到 backup_host。
-
数据传输完成后，远程代理将终止并关闭 SSH 连接。
-
如果远程代理遇到错误情况，则所有代理都将终止，并由主 pg_probackup 进程报告错误详细信息，该进程以错误退出。
-
压缩总是在 db_host 上完成，而解压缩总是在 backup_host 上完成。
注意
您可以对 SSH 设置施加额外的限制，以在帐户被盗时保护系统。
设置 PTRACK 备份
PTRACK 备份模式只能用于 Postgres Pro Standard 和 Postgres Pro Enterprise 安装，或修补的 vanilla PostgreSQL。 PTRACK 补丁的链接可以在这里找到。
https://github.com/postgrespro/pg_probackup#ptrack-support
注意
低于 2.0 的 PTRACK 版本已弃用且不受支持。从 11.9.1 开始的 Postgres Pro Standard 和 Postgres Pro Enterprise 版本包含 PTRACK 2.0。升级您的服务器以避免将来在备份中出现问题，并确保使用升级的 PTRACK 对集群进行全新备份，因为使用 PTRACK 1.x 进行的备份可能已损坏。
如果要使用 PTRACK 备份，请完成以下附加步骤。将执行 PTRACK 备份的角色（以下示例中的备份角色）必须有权访问集群的所有数据库。
对于 PostgreSQL 11 或更高版本：
1.创建 PTRACK 扩展：
CREATE EXTENSION ptrack;复制
2.要启用跟踪页面更新，请将 ptrack.map_size 参数设置为正整数并重新启动服务器。
为了获得最佳性能，建议将 ptrack.map_size 设置为 N / 1024，其中 N 是 PostgreSQL 集群的大小，以 MB 为单位。如果将此参数设置为较低的值，PTRACK 更有可能将多个块映射在一起，这会在跟踪更改的块时导致误报结果，并增加增量备份的大小，因为未更改的块也可以复制到增量备份中。将 ptrack.map_size 设置为较高的值不会影响 PTRACK 操作，但不建议将此参数设置为高于 1024 的值。
注意
如果您更改 ptrack.map_size 参数值，之前创建的 PTRACK 映射文件将被清除，并从头开始跟踪新更改的块。因此，在更改 ptrack.map_size 后进行增量 PTRACK 备份之前，您必须重新进行完整备份。
2.5 使用
2.5.1 创建备份
backup_mode可以取以下值之一：
FULL — 创建一个完整备份，其中包含要恢复的集群的所有数据文件。
DELTA — 读取数据目录中的所有数据文件，并为自上次备份以来已更改的页面创建增量备份。
PAGE — 根据自上次完整或增量备份以来生成的 WAL 文件创建增量备份。仅从数据文件中读取更改的块。
PTRACK — 动态创建增量备份跟踪页面更改。
从增量备份恢复集群时， pg_probackup依赖于父全备份以及它们之间的所有增量备份，称为 “备份链”。在进行增量备份之前，您必须至少创建一个完整备份。
pg_probackup backup -B backup_dir --instance instance_name -b backup_mode复制
2.5.1.1创建归档模式备份：
ARCHIVE 是默认的 WAL 交付模式。
例如，要在 ARCHIVE 模式下进行 FULL 备份，请运行：
pg_probackup backup -B backup_dir --instance instance_name -b FULL复制
[postgres@pg14 pg14.2]$ pg_probackup backup -B /pgdata/pg_probackup --instance pg14.2 -b FULL -h 127.0.0.1 -U backup INFO: Backup start, pg_probackup version: 2.5.5, instance: pg14.2, backup ID: R8KOMJ, backup mode: FULL, wal mode: ARCHIVE, remote: false, compress-algorithm: none, compress-level: 1 WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'. INFO: wait for pg_start_backup() INFO: pg_probackup archive-push WAL file: 00000001000000000000000A, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 91ms INFO: pg_probackup archive-push WAL file: 00000001000000000000000B, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 48ms INFO: Wait for WAL segment /pgdata/pg_probackup/wal/pg14.2/00000001000000000000000B to be archived INFO: PGDATA size: 89MB INFO: Start transferring data files INFO: Data files are transferred, time elapsed: 0 2022-03-11 16:51:56.953 CST [63539] LOG: restore point "pg_probackup, backup_id R8KOMJ" created at 0/C000090 2022-03-11 16:51:56.953 CST [63539] STATEMENT: SELECT pg_catalog.pg_create_restore_point($1) INFO: pg_probackup archive-push WAL file: 00000001000000000000000B.00000028.backup, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 2ms INFO: pg_probackup archive-push WAL file: 00000001000000000000000C, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 55ms INFO: wait for pg_stop_backup() INFO: pg_stop backup() successfully executed INFO: Syncing backup files to disk INFO: Backup files are synced, time elapsed: 1s INFO: Validating backup R8KOMJ INFO: Backup R8KOMJ data files are valid INFO: Backup R8KOMJ resident size: 89MB INFO: Backup R8KOMJ completed复制
查看备份：
[postgres@pg14 pg14.2]$ pg_probackup show -B /pgdata/pg_probackup BACKUP INSTANCE 'pg14.2' ==================================================================================================================================== Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status ==================================================================================================================================== pg14.2 14 R8KOMJ 2022-03-11 16:51:56+08 FULL ARCHIVE 1/0 3s 89MB 16MB 1.00 0/B000028 0/C0000B8 OK复制
2.5.1.2 创建stream备份
pg_probackup backup -B backup_dir --instance instance_name -b FULL --stream --temp-slot复制
如果 WAL 在备份完成之前轮换，可选--temp-slot标志确保所需的段保持可用。
与 ARCHIVE 模式下的备份不同，STREAM 备份包括在进行备份时将集群恢复到一致状态所需的所有 WAL 段。
在备份期间，pg_probackup 将包含 Start LSN 和 Stop LSN 之间的 WAL 记录的 WAL 文件流式传输到 backup_dir/backups/instance_name/backup_id/database/pg_wal 目录。
为了消除静默 WAL 损坏的风险，pg_probackup 还检查 Start LSN 和 Stop LSN 之间的 WAL 记录是否可以被解析。
即使您使用的是 连续存档，STREAM 备份在以下情况下仍然很有用：
- STREAM 备份可以在对 WAL 存档没有文件访问权限的服务器上恢复。
- STREAM 备份使您能够在存档中的 WAL 文件不再可用的时间点恢复集群状态。
- STREAM 模式下的备份可以从生成少量 WAL 流量的服务器的备用服务器中获取，而无需长时间等待 WAL 段填满。
[postgres@pg14 pg14.2]$ pg_probackup backup -B /pgdata/pg_probackup --instance pg14.2 -b FULL --stream --temp-slot INFO: Backup start, pg_probackup version: 2.5.5, instance: pg14.2, backup ID: R8KPLW, backup mode: FULL, wal mode: STREAM, remote: false, compress-algorithm: none, compress-level: 1 WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'. WARNING: Current PostgreSQL role is superuser. It is not recommended to run pg_probackup under superuser. INFO: wait for pg_start_backup() INFO: Wait for WAL segment /pgdata/pg_probackup/backups/pg14.2/R8KPLW/database/pg_wal/00000001000000000000000E to be streamed INFO: PGDATA size: 89MB INFO: Start transferring data files INFO: Data files are transferred, time elapsed: 0 2022-03-11 17:13:09.716 CST [64642] LOG: restore point "pg_probackup, backup_id R8KPLW" created at 0/E000140 2022-03-11 17:13:09.716 CST [64642] STATEMENT: SELECT pg_catalog.pg_create_restore_point($1) INFO: pg_probackup archive-push WAL file: 00000001000000000000000E, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 57ms INFO: pg_probackup archive-push WAL file: 00000001000000000000000E.00000028.backup, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 0ms INFO: wait for pg_stop_backup() INFO: pg_stop backup() successfully executed INFO: Syncing backup files to disk INFO: Backup files are synced, time elapsed: 0 INFO: Validating backup R8KPLW INFO: Backup R8KPLW data files are valid INFO: Backup R8KPLW resident size: 121MB INFO: Backup R8KPLW completed复制
2.5.1.3 页面验证
如果在数据库集群中启用了数据校验和，那么 pg_probackup 会使用此信息在备份期间检查数据文件的正确性。在读取每一页时，pg_probackup 检查计算的校验和是否与存储在页头中的校验和一致。这保证了 PostgreSQL 实例和备份本身没有损坏的页面。请注意，pg_probackup 直接从文件系统读取数据库文件，因此在备份期间的繁重写入负载下，由于部分写入，它可能会显示误报校验和不匹配。如果发生页面校验和不匹配，则重新读取页面并重复校验和比较。
如果校验和比较失败超过 100 次，则认为页面已损坏。在这种情况下，备份将中止。
即使未启用数据校验和，pg_probackup 也会始终对页眉执行完整性检查。
2.5.1.4 外部目录
要备份位于数据目录之外的目录，请使用可选的 --external-dirs 参数来指定此目录的路径。如果您想添加多个外部目录，您可以提供多个路径，在 Linux 系统上用冒号分隔，在 Windows 系统上用分号分隔
例如，要将 /etc/dir1 和 /etc/dir2 目录包含在将存储在 Linux 上的 backup_dir 目录下的 instance_name 实例的完整备份中，请运行：
pg_probackup backup -B backup_dir --instance instance_name -b FULL --external-dirs=/etc/dir1:/etc/dir2复制
同样，要将 C:dir1 和 C:dir2 目录包含在 Windows 上的完整备份中，请运行：
pg_probackup backup -B backup_dir --instance instance_name -b FULL --external-dirs=C:\dir1;C:\dir2复制
pg_probackup 递归地将每个外部目录的内容复制到备份目录中的单独子目录中。由于包含在不同备份中的外部目录不必相同，因此当您从增量备份恢复集群时，只会恢复属于该特定备份的那些目录。存储在先前备份中的任何外部目录都将被忽略。
要在实例的每个备份中包含相同的目录，您可以使用带有 --external-dirs 选项的 set-config 命令在 pg_probackup.conf 配置文件中指定它们。
例子：
[postgres@pg14 pg14.2]$ pg_probackup backup -B /pgdata/pg_probackup/ --instance pg14.2 -b FULL --external-dirs=/opt/pg14/share INFO: Backup start, pg_probackup version: 2.5.5, instance: pg14.2, backup ID: R8KQAH, backup mode: FULL, wal mode: ARCHIVE, remote: false, compress-algorithm: none, compress-level: 1 WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'. WARNING: Current PostgreSQL role is superuser. It is not recommended to run pg_probackup under superuser. INFO: wait for pg_start_backup() INFO: pg_probackup archive-push WAL file: 00000001000000000000000F, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 99ms INFO: pg_probackup archive-push WAL file: 000000010000000000000010, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 47ms INFO: Wait for WAL segment /pgdata/pg_probackup/wal/pg14.2/000000010000000000000010 to be archived INFO: PGDATA size: 89MB INFO: Start transferring data files INFO: Data files are transferred, time elapsed: 0 2022-03-11 17:27:55.368 CST [65425] LOG: restore point "pg_probackup, backup_id R8KQAH" created at 0/110000C8 2022-03-11 17:27:55.368 CST [65425] STATEMENT: SELECT pg_catalog.pg_create_restore_point($1) INFO: pg_probackup archive-push WAL file: 000000010000000000000010.00000028.backup, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 13ms INFO: pg_probackup archive-push WAL file: 000000010000000000000011, threads: 1/1, batch: 1/1, compression: zlib INFO: pg_probackup archive-push completed successfully, pushed: 1, skipped: 0, time elapsed: 66ms INFO: wait for pg_stop_backup() INFO: pg_stop backup() successfully executed INFO: Syncing backup files to disk INFO: Backup files are synced, time elapsed: 0 INFO: Validating backup R8KQAH INFO: Backup R8KQAH data files are valid INFO: Backup R8KQAH resident size: 108MB INFO: Backup R8KQAH completed [postgres@pg14 pg14.2]$ pg_probackup show -B /pgdata/pg_probackup BACKUP INSTANCE 'pg14.2' ====================================================================================================================================== Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status ====================================================================================================================================== pg14.2 14 R8KQAH 2022-03-11 17:27:55+08 FULL ARCHIVE 1/0 3s 108MB 16MB 1.00 0/10000028 0/110000F0 OK pg14.2 14 R8KPLW 2022-03-11 17:13:09+08 FULL STREAM 1/0 6s 89MB 32MB 1.00 0/E000028 0/E000168 OK pg14.2 14 R8KOMJ 2022-03-11 16:51:56+08 FULL ARCHIVE 1/0 3s 89MB 16MB 1.00 0/B000028 0/C0000B8 OK pg14.2 ---- R8KN19 ---- FULL ARCHIVE 0/0 1h:10m 0 0 1.00 0/0 0/0 RUNNING pg14.2 ---- R8KMYH ---- FULL ARCHIVE 0/0 1h:12m 0 0 1.00 0/0 0/0 RUNNING pg14.2 ---- R8KMC2 ---- FULL ARCHIVE 0/0 1h:25m 0 0 1.00 0/0 0/0 RUNNING pg14.2 ---- R8KMBE ---- FULL ARCHIVE 0/0 1h:26m 0 0 1.00 0/0 0/0 RUNNING复制
2.5.2 执行集群验证
要验证PostgreSQL数据库集群是否未损坏，请运行以下命令：
pg_probackup checkdb [-B backup_dir [--instance instance_name]] [-D data_dir] [connection_options]复制
此命令通过运行页头完整性检查来对位于指定数据目录中的所有数据文件执行物理验证，如果启用了校验和，则还执行块级校验和验证。如果检测到损坏的页面，checkdb 将继续进行集群验证，直到验证集群中的所有页面。
默认情况下，类似的页面验证会在pg_probackup 进行备份时自动执行 。
该checkdb 命令使您能够按需执行此类页面验证，而无需获取任何备份副本，即使集群根本没有使用pg_probackup备份。
要执行集群验证，pg_probackup 需要连接到要验证的集群。一般来说，为 pg_probackup指定这个集群的备份实例就足够了，以确定所需的连接选项。但是，如果省略-B和 --instance选项，您必须提供 连接选项并 *data_dir*通过环境变量或命令行选项。
[postgres@pg14 ~]$ pg_probackup checkdb -B /pgdata/pg_probackup --instance pg14.2 WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'. WARNING: Current PostgreSQL role is superuser. It is not recommended to run pg_probackup under superuser. INFO: Start checking data files INFO: Data files are valid复制
物理验证无法检测到逻辑不一致、丢失或无效的块和整个文件，或类似的异常。扩展 amcheck 和 amcheck_next 为这些问题提供了部分解决方案。
如果除了物理验证之外，您还想使用这些扩展验证所有数据库中的所有索引，您可以--amcheck在运行checkdb命令时指定标志：
pg_probackup checkdb -D data_dir --amcheck [connection_options]复制
使用该标志可以更彻底地完成逻辑验证，方法是 --heapallindexed检查所有应该被索引的堆元组是否都被实际索引，但 CPU、内存和 I/O 消耗的成本更高。
[postgres@pg14 ~]$ pg_probackup checkdb -D /pgdata/14/data --amcheck WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'. WARNING: Current PostgreSQL role is superuser. It is not recommended to run pg_probackup under superuser. INFO: Start checking data files INFO: Data files are valid WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'. WARNING: Current PostgreSQL role is superuser. It is not recommended to run pg_probackup under superuser. INFO: Start amchecking PostgreSQL instance INFO: Amchecking database 'postgres' using extension 'amcheck' version 1.3 from schema 'public' INFO: Amcheck succeeded for database 'postgres' INFO: checkdb --amcheck finished successfully. All checked indexes are valid. INFO: All databases were amchecked.复制
方法是 --heapallindexed
[postgres@pg14 ~]$ pg_probackup checkdb -D /pgdata/14/data --amcheck `--heapallindexed` -bash: --heapallindexed: command not found WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'. WARNING: Current PostgreSQL role is superuser. It is not recommended to run pg_probackup under superuser. INFO: Start checking data files INFO: Data files are valid WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'. WARNING: Current PostgreSQL role is superuser. It is not recommended to run pg_probackup under superuser. INFO: Start amchecking PostgreSQL instance INFO: Amchecking database 'postgres' using extension 'amcheck' version 1.3 from schema 'public' INFO: Amcheck succeeded for database 'postgres' INFO: checkdb --amcheck finished successfully. All checked indexes are valid. INFO: All databases were amchecked.复制
2.5.3 验证备份
pg_probackup在备份过程中计算备份中每个文件的校验和。检查备份数据文件校验和的过程称为 备份验证。默认情况下，在进行备份后和恢复之前立即运行验证，以检测可能的备份损坏。
如果您想跳过备份验证，您可以 --no-validate在运行 备份和 恢复命令时指定标志。
为确保所有必需的备份文件都存在并可用于恢复数据库集群，您可以 使用您将用于恢复的确切 恢复目标选项运行validate命令。
例如，要检查您是否可以将数据库集群从备份副本还原到事务 ID 4242，请运行以下命令：
pg_probackup validate -B backup_dir --instance instance_name --recovery-target-xid=4242复制
如果验证成功完成，pg_probackup会显示相应的消息。如果验证失败，您将收到一条错误消息，其中包含可以恢复的确切时间、事务 ID 和 LSN。
如果您通过 选项指定backup_id*-i/--backup-id，则仅验证具有指定备份 ID 的备份副本。如果 使用recovery target options指定了 backup_id*，则validate**命令将检查是否可以将指定的备份恢复到指定的恢复目标。
例如，要检查您是否可以从PT8XFX备份 ID 到指定时间戳的备份副本恢复数据库集群，请运行以下命令：
pg_probackup validate -B backup_dir --instance instance_name -i PT8XFX --recovery-target-time="2017-05-18 14:18:11+03"复制
如果您指定*backup_id*增量备份，则从 FULL 备份开始的所有父项都将被验证。
如果省略所有参数，则验证所有备份。
[postgres@pg14 ~]$ pg_probackup show -B /pgdata/pg_probackup BACKUP INSTANCE 'pg14.2' ===================================================================================================================================== Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status ===================================================================================================================================== pg14.2 14 R8L3EF 2022-03-11 22:11:05+08 PTRACK ARCHIVE 1/1 3s 64MB 16MB 1.00 0/22000028 0/230000B8 OK pg14.2 14 R8L36N 2022-03-11 22:06:25+08 PAGE ARCHIVE 1/1 3s 64MB 16MB 1.00 0/1F000028 0/200000B8 OK pg14.2 14 R8L2D4 2022-03-11 21:48:42+08 PAGE ARCHIVE 1/1 3s 64MB 16MB 1.00 0/1C000028 0/1D0000B8 OK pg14.2 14 R8L2BF 2022-03-11 21:47:41+08 PTRACK ARCHIVE 1/1 3s 64MB 16MB 1.00 0/19000028 0/1A0000B8 OK pg14.2 14 R8L2AU 2022-03-11 21:47:20+08 PTRACK ARCHIVE 1/1 3s 64MB 16MB 1.00 0/17000028 0/180000F0 OK pg14.2 14 R8L26S 2022-03-11 21:44:54+08 FULL ARCHIVE 1/0 3s 89MB 16MB 1.00 0/14000028 0/150000B8 OK pg14.2 14 R8KQAH 2022-03-11 17:27:55+08 FULL ARCHIVE 1/0 3s 108MB 16MB 1.00 0/10000028 0/110000F0 OK pg14.2 14 R8KPLW 2022-03-11 17:13:09+08 FULL STREAM 1/0 6s 89MB 32MB 1.00 0/E000028 0/E000168 OK pg14.2 14 R8KOMJ 2022-03-11 16:51:56+08 FULL ARCHIVE 1/0 3s 89MB 16MB 1.00 0/B000028 0/C0000B8 OK [postgres@pg14 ~]$ pg_probackup validate -B /pgdata/pg_probackup --instance pg14.2 -iR8L2BF INFO: Validating parents for backup R8L2BF INFO: Validating backup R8L26S INFO: Backup R8L26S data files are valid INFO: Validating backup R8L2AU INFO: Backup R8L2AU data files are valid INFO: Validating backup R8L2BF INFO: Backup R8L2BF data files are valid INFO: Backup R8L2BF WAL segments are valid INFO: Backup R8L2BF is valid. INFO: Validate of backup R8L2BF completed.复制
2.5.4 恢复集群
要从备份中恢复数据库集群，请 至少使用以下选项 运行restore命令：
pg_probackup restore -B backup_dir--instance instance_name-ibackup_id复制
在哪里：
- *
backup_dir*是存储所有备份文件和元信息的备份目录。 - *
instance_name*是要恢复的集群的备份实例。 - *
backup_id*指定要从中还原集群的备份。如果您省略此选项， pg_probackup将使用可用于指定实例的最新有效备份。如果您指定要恢复的增量备份，pg_probackup 会自动恢复底层完整备份，然后按顺序应用所有必要的增量。
命令完成后restore，启动数据库服务。
如果您恢复ARCHIVE备份、执行PITR或使用命令指定--restore-as-replica标志 restore来设置备用服务器， 一旦所有数据文件都复制到目标目录中， pg_probackup就会创建一个恢复配置文件。该文件包括恢复所需的最低设置，除了 primary_conninfo 参数中的密码；如果需要，您必须手动添加密码或使用该--primary-conninfo选项。对于PostgreSQL 11 或更低版本，恢复设置被写入recovery.conf 文件。从PostgreSQL 12 开始， pg_probackup将这些设置写入probackup_recovery.conf文件，然后将其包含到postgresql.auto.conf.
如果您正在还原 STREAM 备份，则还原会立即完成，并且集群会在进行备份时返回到自洽状态。对于 ARCHIVE 备份， PostgreSQL重放所有可用的归档 WAL 段，因此集群恢复到当前时间线内可能的最新状态。您可以通过将 恢复目标选项与restore命令一起使用来更改此行为，如“执行时间点 (PITR) 恢复”一节中所述。
如果要恢复的集群包含表空间，pg_probackup 默认 将它们恢复到它们的原始位置。要将表空间恢复到其他位置，请使用 --tablespace-mapping/-T选项。否则，如果正在使用表空间，则在同一主机上恢复集群将失败，因为必须将备份写入相同的目录。
使用--tablespace-mapping/-T 选项时，您必须提供新旧表空间目录的绝对路径。如果路径恰好包含等号 ( =)，请使用反斜杠对其进行转义。可以为多个表空间多次指定此选项。例如：
pg_probackup restore -B backup_dir--instance instance_name-D data_dir-j 4 -i backup_id-T tablespace1_dir= tablespace1_newdir-T tablespace2_dir=tablespace2_newdir复制
[postgres@pg14 pgdata]$ pg_probackup restore -B /pgdata/pg_probackup --instance pg14.2 -D /pgdata/14.2/data -i R8L36N INFO: Validating parents for backup R8L36N INFO: Validating backup R8L26S INFO: Backup R8L26S data files are valid INFO: Validating backup R8L2AU INFO: Backup R8L2AU data files are valid INFO: Validating backup R8L2BF INFO: Backup R8L2BF data files are valid INFO: Validating backup R8L2D4 INFO: Backup R8L2D4 data files are valid INFO: Validating backup R8L36N INFO: Backup R8L36N data files are valid INFO: Backup R8L36N WAL segments are valid INFO: Backup R8L36N is valid. INFO: Restoring the database from backup at 2022-03-11 22:06:23+08 INFO: Start restoring backup files. PGDATA size: 89MB INFO: Backup files are restored. Transfered bytes: 89MB, time elapsed: 0 INFO: Restore incremental ratio (less is better): 100% (89MB/89MB) INFO: Syncing restored files to disk INFO: Restored backup files are synced, time elapsed: 1s INFO: Restore of backup R8L36N completed.复制
要在远程主机上恢复集群，请按照 “在远程模式下使用pg_probackup ”一节中的说明进行操作。
笔记
默认情况下，restore 命令会在恢复集群之前验证指定的备份。如果您运行定期备份验证并希望在恢复集群时节省时间，您可以指定 --no-validate标志以跳过验证并加快恢复速度。
2.5.4.1 增量恢复
通过使用带有 restore 命令的增量恢复选项仅替换现有 PostgreSQL 数据目录中无效和更改的页面，可以显着提高从备份恢复的速度。
要以增量模式从备份恢复数据库集群，请使用以下选项运行 restore 命令：
pg_probackup restore -B backup_dir --instance instance_name -D data_dir -I incremental_mode复制
其中 incremental_mode 可以采用以下值之一：
-
CHECKSUM — 读取数据目录中的所有数据文件，验证每一页的 header 和 checksum，只替换无效页和那些 checksum 和 LSN 与备份中相应页不匹配的页。这是最简单、最简单的增量模式。建议默认使用。
-
LSN — 读取数据目录中的 pg_control 以获取重做 LSN 和重做 TLI，这允许确定历史记录点 (shiftpoint)，其中数据目录状态从目标备份链历史记录转移。如果 shiftpoint 不在备份链历史的范围内，则恢复被中止。如果 shiftpoint 在备份链历史的范围内，则读取数据目录中的所有数据文件，验证每个页面中的 header 和校验和，仅替换无效页面和 LSN 大于 shiftpoint 的页面。与 CHECKSUM 相比，此模式提供了更大的加速，但需要满足两个条件。首先，必须在数据目录中启用数据校验和参数（以避免由于提示位而损坏）。此条件将在增量恢复开始时检查，如果禁用校验和，操作将中止。其次，pg_control 文件必须与数据目录的状态同步。在恢复开始时无法检查此条件，因此用户有责任确保 pg_control 包含有效信息。因此不建议在任何情况下使用 LSN 模式，其中 pg_control 不能被信任或被篡改：在 pg_resetxlog 执行后，从备份恢复后没有运行恢复等。
-
NONE — 没有任何增量优化的常规恢复。
无论选择何种增量模式，pg_probackup 都会检查给定目标目录中的 postmaster 是否未运行，并且系统标识符与备份中的相同。
假设您希望在 LSN 模式下使用增量恢复切换后将旧主服务器作为副本返回：
笔记
增量恢复仅适用于 program_version 等于或大于 2.4.0 的备份。
2.5.4.2 部分还原
如果在进行备份之前启用了部分还原，则可以使用部分还原选项和还原命令仅还原部分数据库。
要仅恢复指定的数据库，请使用以下选项运行 restore 命令：
pg_probackup restore -B backup_dir --instance instance_name --db-include=database_name复制
–db-include 选项可以指定多次。例如，要仅恢复数据库 db1 和 db2，请运行以下命令：
pg_probackup restore -B backup_dir --instance instance_name --db-include=db1 --db-include=db2复制
要从还原中排除一个或多个数据库，请使用 --db-exclude 选项：
pg_probackup restore -B backup_dir --instance instance_name --db-exclude=database_name复制
–db-exclude 选项可以指定多次。例如，要从还原中排除数据库 db1 和 db2，请运行以下命令：
pg_probackup restore -B backup_dir --instance instance_name --db-exclude=db1 --db-exclude=db2复制
部分恢复依赖于 PostgreSQL 恢复过程对截断文件的松懈行为。为了使恢复正常工作，排除数据库的文件将恢复为大小为零的文件。成功启动 PostgreSQL 集群后，您必须使用 DROP DATABASE 命令删除排除的数据库。
要将包含多个数据库的单个集群解耦为单独的集群，并且停机时间最短，您可以使用特定数据库的 --restore-as-replica 选项将集群部分还原为备用。
注意
template0 和 template1 数据库总是被恢复。
注意
由于 PostgreSQL 12 之前版本的恢复特性，建议您在对 12 之前版本的 PostgreSQL 集群进行部分恢复时将 hot_standby 参数设置为 off。否则恢复可能会失败。
2.5.5 执行时间点 (PITR) 恢复
如果在进行备份之前启用了连续 WAL 归档，则可以使用 restore 命令的恢复目标选项将集群恢复到任意时间点（恢复目标）的状态。
您可以同时使用 STREAM 和 ARCHIVE 备份进行时间点恢复，只要 WAL 存档至少从进行备份时开始可用。如果省略 -i/–backup-id 选项，pg_probackup 会自动选择最接近指定恢复目标的备份并启动恢复过程，否则 pg_probackup 将尝试将指定备份恢复到指定恢复目标。
要在确切时间恢复集群状态，请以时间戳格式指定 --recovery-target-time 选项。例如：
pg_probackup restore -B backup_dir --instance instance_name --recovery-target-time='2017-05-18 14:18:11+03'复制
要将集群状态恢复到特定的事务 ID，请使用 --recovery-target-xid 选项：
pg_probackup restore -B backup_dir --instance instance_name --recovery-target-xid=687复制
要将集群状态恢复到特定 LSN，请使用 --recovery-target-lsn 选项：
pg_probackup restore -B backup_dir --instance instance_name --recovery-target-lsn=16/B374D848复制
要将集群状态还原到特定命名的还原点，请使用 --recovery-target-name 选项：
pg_probackup restore -B backup_dir --instance instance_name --recovery-target-name='before_app_upgrade'复制
要将备份恢复到 WAL 存档中可用的最新状态，请使用具有最新值的 --recovery-target 选项：
pg_probackup restore -B backup_dir --instance instance_name --recovery-target='latest'复制
要将集群恢复到最早的一致性点，请使用带有立即值的 --recovery-target 选项：
pg_probackup restore -B backup_dir --instance instance_name --recovery-target='immediate'复制
2.5.6 在远程模式下使用 pg_probackup
pg_probackup 支持远程模式，允许通过 SSH 远程执行备份和恢复操作。在这种模式下，备份目录存储在本地系统上，而要备份的 PostgreSQL 实例位于远程系统上。您必须在两个系统上都安装 pg_probackup。
注意
pg_probackup 依赖于无密码 SSH 连接在主机之间进行通信。
典型的工作流程如下：
-
在您的备份主机上，按照安装和设置<2.4>部分中的说明配置 pg_probackup。对于 add-instance 和 set-config 命令，请确保指定指向具有 PostgreSQL 实例的数据库主机的远程选项。
-
如果您想在 PAGE 模式下进行远程备份，或者依赖 ARCHIVE WAL 交付模式，或者使用 PITR，请按照设置连续 WAL 归档部分中的说明配置从数据库主机到备份主机的连续 WAL 归档。对于archive-push 和archive-get 命令，您必须指定指向具有备份目录的备份主机的远程选项。
-
在备份主机上运行带有远程选项的备份或恢复命令。 pg_probackup 通过 SSH 连接到远程系统，并分别在本地创建备份或恢复之前在远程系统上进行的备份。
例如，要代表 postgres 用户通过端口 2302 的 SSH 连接创建位于主机地址为 192.168.0.2 的远程系统上的 PostgreSQL 集群的归档完整备份，请运行：
pg_probackup backup -B backup_dir --instance instance_name -b FULL --remote-user=postgres --remote-host=192.168.0.2 --remote-port=2302复制
要代表 postgres 用户通过端口 2302 通过 SSH 连接恢复主机地址为 192.168.0.2 的远程系统上的最新可用备份，请运行：
pg_probackup restore -B backup_dir --instance instance_name --remote-user=postgres --remote-host=192.168.0.2 --remote-port=2302复制
恢复 ARCHIVE 备份或在远程模式下执行 PITR 需要其他信息：目标地址、端口和用户名，用于建立从具有数据库的主机到具有备份目录的主机的 SSH 连接。 restore_command 将使用此信息将 WAL 段从存档复制到 PostgreSQL pg_wal 目录。
要解决此问题，您可以使用 Remote WAL Archive Options。
例如，要使用远程模式通过 SSH 连接到地址为 192.168.0.2 的主机上的用户 postgres 通过端口 2302 恢复远程系统上的最新备份，并通过端口 2303 连接到地址为 192.168.0.3 的备份目录主机上的用户备份，请运行：
pg_probackup restore -B backup_dir --instance instance_name --remote-user=postgres --remote-host=192.168.0.2 --remote-port=2302 --archive-host=192.168.0.3 --archive-port=2303 --archive-user=backup复制
提供的参数将用于构造 restore_command：
restore_command = '"install_dir/pg_probackup" archive-get -B "backup_dir" --instance instance_name --wal-file-path=%p --wal-file-name=%f --remote-host=192.168.0.3 --remote-port=2303 --remote-user=backup'复制
或者，您可以使用 --restore-command 选项提供整个 restore_command：
pg_probackup restore -B backup_dir --instance instance_name --remote-user=postgres --remote-host=192.168.0.2 --remote-port=2302 --restore-command='"install_dir/pg_probackup" archive-get -B "backup_dir" --instance instance_name --wal-file-path=%p --wal-file-name=%f --remote-host=192.168.0.3 --remote-port=2303 --remote-user=backup'复制
注意
远程模式目前不适用于 Windows 系统。
2.5.7 在并行线程上运行 pg_probackup
backup、restore、merge、delete、catchup、checkdb 和 validate 进程可以在多个并行线程上执行。如果有足够的资源（CPU 内核、磁盘和网络带宽），这可以显着加快 pg_probackup 操作。
并行执行由 -j/–threads 命令行选项控制。例如，要使用四个并行线程创建备份，请运行：
pg_probackup backup -B backup_dir --instance instance_name -b FULL -j 4复制
注意
并行恢复仅适用于将数据从备份目录复制到集群的数据目录。当 PostgreSQL 服务器启动时，需要重播 WAL 记录，这不能并行完成。
2.5.8 配置 pg_probackup
初始化备份目录并添加新的备份实例后，您可以使用位于 backup_dir/backups/instance_name 目录中的 pg_probackup.conf 配置文件来微调 pg_probackup 配置。
例如，backup 和 checkdb 命令使用常规 PostgreSQL 连接。为避免每次都在命令行上指定连接选项，您可以使用 set-config 命令在 pg_probackup.conf 配置文件中设置它们。
注意
不建议手动编辑 pg_probackup.conf。
最初，pg_probackup.conf 包含以下设置：
PGDATA — 要备份的集群数据目录的路径。
system-identifier — PostgreSQL 实例的唯一标识符。
此外，您可以使用 set-config 命令定义远程、保留、日志记录和压缩设置：
pg_probackup set-config -B backup_dir --instance instance_name [--external-dirs=external_directory_path] [remote_options] [connection_options] [retention_options] [logging_options]复制
要查看当前设置，请运行以下命令：
pg_probackup show-config -B backup_dir --instance instance_name复制
当通过相应的环境变量和/或命令行选项运行 pg_probackup 命令时，您可以覆盖 pg_probackup.conf 中定义的设置。
2.5.9 指定连接设置
如果您在 pg_probackup.conf 配置文件中定义连接设置，则可以在所有后续 pg_probackup 命令中省略连接选项。但是，如果设置了相应的环境变量，它们将获得更高的优先级。命令行上提供的选项会覆盖环境变量和配置文件设置。
优先级：命令行>环境变量>配置文件
如果没有给出任何内容，则采用默认值。默认情况下，pg_probackup 尝试通过 Unix 域套接字（Windows 上的 localhost）使用本地连接，并尝试从 PGUSER 环境变量或当前操作系统用户名中获取数据库名称和用户名。
2.5.10 管理备份目录
使用 pg_probackup，您可以从命令行管理备份：
- 查看备份信息
- 查看 WAL 存档信息
- 验证备份
- 合并备份
- 删除备份
2.5.10.1 查看备份信息
要查看每个实例的现有备份列表，请运行以下命令：
pg_probackup show -B backup_dir复制
pg_probackup 显示所有可用备份的列表。例如：
BACKUP INSTANCE 'node' ====================================================================================================================================== Instance Version ID Recovery time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status ====================================================================================================================================== node 10 PYSUE8 2019-10-03 15:51:48+03 FULL ARCHIVE 1/0 16s 9047kB 16MB 4.31 0/12000028 0/12000160 OK node 10 P7XDQV 2018-04-29 05:32:59+03 DELTA STREAM 1/1 11s 19MB 16MB 1.00 0/15000060 0/15000198 OK node 10 P7XDJA 2018-04-29 05:28:36+03 PTRACK STREAM 1/1 21s 32MB 32MB 1.00 0/13000028 0/13000198 OK node 10 P7XDHU 2018-04-29 05:27:59+03 PAGE STREAM 1/1 15s 33MB 16MB 1.00 0/11000028 0/110001D0 OK node 10 P7XDHB 2018-04-29 05:27:15+03 FULL STREAM 1/0 11s 39MB 16MB 1.00 0/F000028 0/F000198 OK复制
对于每个备份，都提供以下信息：
-
Instance — 实例名称。
-
Version — PostgreSQL 主要版本。
-
ID — 备份标识符。
-
Recovery time ——您可以恢复数据库集群状态的最早时间。
-
Mode — 用于进行此备份的方法。可能的值：FULL、PAGE、DELTA、PTRACK。
-
WAL Mode — WAL 交付模式。可能的值：STREAM 和 ARCHIVE。
-
TLI — 当前备份及其父项的时间线标识符。
-
Time — 执行备份所花费的时间。
-
Data — 此备份中数据文件的大小。此值不包括 WAL 文件的大小。对于 STREAM 备份，备份的总大小可以计算为 Data + WAL。
-
WAL — 在恢复期间需要应用的 WAL 文件的未压缩大小，以使备份达到一致状态。
-
Zratio — 压缩比，计算为“uncompressed-bytes”/“data-bytes”。
-
Start LSN — 对应于备份过程开始的 WAL 日志序列号。 PostgreSQL 恢复过程开始的重做点。
-
Stop LSN — 对应于备份过程结束的 WAL 日志序列号。 PostgreSQL 恢复过程的一致性点。
-
Status — 备份状态。可能的值：
OK— 备份已完成且有效。
DONE — 备份已完成，但未经验证。
RUNNING — 备份正在进行中。
MERGING — 正在合并备份。
MERGED — 备份数据文件已成功合并，但其元数据正在更新中。只有完整备份才能具有此状态。
DELETING — 正在删除备份文件。
CORRUPT — 一些备份文件已损坏。
ERROR — 备份因意外错误而中止。
ORPHAN — 备份无效，因为其父备份之一已损坏或丢失。
只有当备份状态为 OK 或 DONE 时，您才能从备份中恢复集群。
要获取有关备份的更多详细信息，请使用备份 ID 运行 show 命令：
pg_probackup show -B backup_dir --instance instance_name -i backup_id复制
示例输出如下：
#Configuration backup-mode = FULL stream = false compress-alg = zlib compress-level = 1 from-replica = false #Compatibility block-size = 8192 wal-block-size = 8192 checksum-version = 1 program-version = 2.1.3 server-version = 10 #Result backup info timelineid = 1 start-lsn = 0/04000028 stop-lsn = 0/040000f8 start-time = '2017-05-16 12:57:29' end-time = '2017-05-16 12:57:31' recovery-xid = 597 recovery-time = '2017-05-16 12:57:31' expire-time = '2020-05-16 12:57:31' data-bytes = 22288792 wal-bytes = 16777216 uncompressed-bytes = 39961833 pgdata-bytes = 39859393 status = OK parent-backup-id = 'PT8XFX' primary_conninfo = 'user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any'复制
详细输出具有附加属性：
- compress-alg — 备份期间使用的压缩算法。可能的值：zlib、pglz、无。
- compress-level — 备份期间使用的压缩级别。
- from-replica — 这个备份是在备用状态下进行的吗？可能的值：1、0。
- block-size — 备份开始时 PostgreSQL 集群的 block_size 设置。
- checksum-version — 是否在备份的 PostgreSQL 集群中启用了数据块校验和？可能的值：1、0。
- program-version — 用于创建备份的 pg_probackup 二进制文件的完整版本。
- start-time — 备份开始时间。
- end-time — 备份结束时间。
- expire-time — 可以根据保留策略删除固定备份的时间点。此属性仅适用于固定备份。
- uncompressed-bytes — 添加页头和应用压缩之前的数据文件大小。如果使用压缩，您可以通过将未压缩字节与数据字节进行比较来评估压缩的有效性。
- pgdata-bytes — 备份时 PostgreSQL 集群数据文件的大小。您可以通过比较 pgdata-bytes 和 uncompressed-bytes 来评估增量备份的有效性。
- recovery-xid — 备份结束时间的事务 ID。
- parent-backup-id — 父备份的 ID。仅适用于增量备份。
- primary_conninfo — libpq 连接参数，用于连接到 PostgreSQL 集群以进行此备份。不包括密码。
- note - 附加到备份的文本注释。
- content-crc — backup_content.control 文件的 CRC32 校验和。它用于检测备份元信息的损坏。
您还可以获取 JSON 格式的备份的详细信息：
pg_probackup show -B backup_dir --instance instance_name --format=json -i backup_id复制
示例输出如下：
[ { "instance": "node", "backups": [ { "id": "PT91HZ", "parent-backup-id": "PT8XFX", "backup-mode": "DELTA", "wal": "ARCHIVE", "compress-alg": "zlib", "compress-level": 1, "from-replica": false, "block-size": 8192, "xlog-block-size": 8192, "checksum-version": 1, "program-version": "2.1.3", "server-version": "10", "current-tli": 16, "parent-tli": 2, "start-lsn": "0/8000028", "stop-lsn": "0/8000160", "start-time": "2019-06-17 18:25:11+03", "end-time": "2019-06-17 18:25:16+03", "recovery-xid": 0, "recovery-time": "2019-06-17 18:25:15+03", "data-bytes": 106733, "wal-bytes": 16777216, "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any", "status": "OK" } ] } ]复制
2.5.10.2 查看 WAL 存档信息
要查看每个实例的 WAL 归档信息，请运行以下命令：
pg_probackup show -B backup_dir [--instance instance_name] --archive复制
pg_probackup 显示按时间线分组的所有可用 WAL 文件的列表。例如：
ARCHIVE INSTANCE 'node' =================================================================================================================================== TLI Parent TLI Switchpoint Min Segno Max Segno N segments Size Zratio N backups Status =================================================================================================================================== 5 1 0/B000000 00000005000000000000000B 00000005000000000000000C 2 685kB 48.00 0 OK 4 3 0/18000000 000000040000000000000018 00000004000000000000001A 3 648kB 77.00 0 OK 3 2 0/15000000 000000030000000000000015 000000030000000000000017 3 648kB 77.00 0 OK 2 1 0/B000108 00000002000000000000000B 000000020000000000000015 5 892kB 94.00 1 DEGRADED 1 0 0/0 000000010000000000000001 00000001000000000000000A 10 8774kB 19.00 1 OK复制
对于每个时间线，提供以下信息：
TLI— 时间线标识符。Parent TLI— 此时间线分支的时间线的标识符。Switchpoint— 时间线从其父时间线分支时的 LSN。Min Segno— 属于时间线的第一个 WAL 段。Max Segno— 属于时间线的最后一个 WAL 段。N segments— 属于时间线的 WAL 段数。Size— 文件在磁盘上的大小。Zratio— 压缩比计算为 N 段 * wal_segment_size * wal_block_size / Size。N segments*wal_segment_size*wal_block_size/Size.N backups— 属于时间线的备份数。要获取有关备份的详细信息，请使用 JSON 格式。Status— 此时间线的 WAL 存档状态。可能的值：OK— Min Segno 和 Max Segno 之间的所有 WAL 段都存在。DEGRADED— Min Segno 和 Max Segno 之间的一些 WAL 段丢失。要找出丢失的文件，请以 JSON 格式查看此报告。
要获取有关 JSON 格式的 WAL 存档的更多详细信息，请运行以下命令：
pg_probackup show -B backup_dir [--instance instance_name] --archive --format=json复制
示例输出如下:
[ { "instance": "replica", "timelines": [ { "tli": 5, "parent-tli": 1, "switchpoint": "0/B000000", "min-segno": "00000005000000000000000B", "max-segno": "00000005000000000000000C", "n-segments": 2, "size": 685320, "zratio": 48.00, "closest-backup-id": "PXS92O", "status": "OK", "lost-segments": [], "backups": [] }, { "tli": 4, "parent-tli": 3, "switchpoint": "0/18000000", "min-segno": "000000040000000000000018", "max-segno": "00000004000000000000001A", "n-segments": 3, "size": 648625, "zratio": 77.00, "closest-backup-id": "PXS9CE", "status": "OK", "lost-segments": [], "backups": [] }, { "tli": 3, "parent-tli": 2, "switchpoint": "0/15000000", "min-segno": "000000030000000000000015", "max-segno": "000000030000000000000017", "n-segments": 3, "size": 648911, "zratio": 77.00, "closest-backup-id": "PXS9CE", "status": "OK", "lost-segments": [], "backups": [] }, { "tli": 2, "parent-tli": 1, "switchpoint": "0/B000108", "min-segno": "00000002000000000000000B", "max-segno": "000000020000000000000015", "n-segments": 5, "size": 892173, "zratio": 94.00, "closest-backup-id": "PXS92O", "status": "DEGRADED", "lost-segments": [ { "begin-segno": "00000002000000000000000D", "end-segno": "00000002000000000000000E" }, { "begin-segno": "000000020000000000000010", "end-segno": "000000020000000000000012" } ], "backups": [ { "id": "PXS9CE", "backup-mode": "FULL", "wal": "ARCHIVE", "compress-alg": "none", "compress-level": 1, "from-replica": "false", "block-size": 8192, "xlog-block-size": 8192, "checksum-version": 1, "program-version": "2.1.5", "server-version": "10", "current-tli": 2, "parent-tli": 0, "start-lsn": "0/C000028", "stop-lsn": "0/C000160", "start-time": "2019-09-13 21:43:26+03", "end-time": "2019-09-13 21:43:30+03", "recovery-xid": 0, "recovery-time": "2019-09-13 21:43:29+03", "data-bytes": 104674852, "wal-bytes": 16777216, "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any", "status": "OK" } ] }, { "tli": 1, "parent-tli": 0, "switchpoint": "0/0", "min-segno": "000000010000000000000001", "max-segno": "00000001000000000000000A", "n-segments": 10, "size": 8774805, "zratio": 19.00, "closest-backup-id": "", "status": "OK", "lost-segments": [], "backups": [ { "id": "PXS92O", "backup-mode": "FULL", "wal": "ARCHIVE", "compress-alg": "none", "compress-level": 1, "from-replica": "true", "block-size": 8192, "xlog-block-size": 8192, "checksum-version": 1, "program-version": "2.1.5", "server-version": "10", "current-tli": 1, "parent-tli": 0, "start-lsn": "0/4000028", "stop-lsn": "0/6000028", "start-time": "2019-09-13 21:37:36+03", "end-time": "2019-09-13 21:38:45+03", "recovery-xid": 0, "recovery-time": "2019-09-13 21:37:30+03", "data-bytes": 25987319, "wal-bytes": 50331648, "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any", "status": "OK" } ] } ] }, { "instance": "master", "timelines": [ { "tli": 1, "parent-tli": 0, "switchpoint": "0/0", "min-segno": "000000010000000000000001", "max-segno": "00000001000000000000000B", "n-segments": 11, "size": 8860892, "zratio": 20.00, "status": "OK", "lost-segments": [], "backups": [ { "id": "PXS92H", "parent-backup-id": "PXS92C", "backup-mode": "PAGE", "wal": "ARCHIVE", "compress-alg": "none", "compress-level": 1, "from-replica": "false", "block-size": 8192, "xlog-block-size": 8192, "checksum-version": 1, "program-version": "2.1.5", "server-version": "10", "current-tli": 1, "parent-tli": 1, "start-lsn": "0/4000028", "stop-lsn": "0/50000B8", "start-time": "2019-09-13 21:37:29+03", "end-time": "2019-09-13 21:37:31+03", "recovery-xid": 0, "recovery-time": "2019-09-13 21:37:30+03", "data-bytes": 1328461, "wal-bytes": 33554432, "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any", "status": "OK" }, { "id": "PXS92C", "backup-mode": "FULL", "wal": "ARCHIVE", "compress-alg": "none", "compress-level": 1, "from-replica": "false", "block-size": 8192, "xlog-block-size": 8192, "checksum-version": 1, "program-version": "2.1.5", "server-version": "10", "current-tli": 1, "parent-tli": 0, "start-lsn": "0/2000028", "stop-lsn": "0/2000160", "start-time": "2019-09-13 21:37:24+03", "end-time": "2019-09-13 21:37:29+03", "recovery-xid": 0, "recovery-time": "2019-09-13 21:37:28+03", "data-bytes": 24871902, "wal-bytes": 16777216, "primary_conninfo": "user=backup passfile=/var/lib/pgsql/.pgpass port=5432 sslmode=disable sslcompression=1 target_session_attrs=any", "status": "OK" } ] } ] } ]复制
大多数字段都与普通格式一致，但有一些例外：
- 大小以字节为单位。
- 最近的备份 ID 属性包含属于先前时间线之一的最新有效备份的 ID。您可以使用此备份执行到此时间线的时间点恢复。如果不存在这样的备份，则此字符串为空。
- lost-segments 数组提供有关 DEGRADED 时间线中丢失段的间隔的信息。在 OK 时间轴中，丢失的片段数组是空的。
- 备份数组列出了属于时间线的所有备份。如果时间线没有备份，则此数组为空。
2.5.11配置保留策略
使用 pg_probackup，您可以配置保留策略以删除冗余备份、清理不需要的 WAL 文件以及固定特定备份以确保它们保留指定的时间，如下面的部分所述。所有这些动作都可以以任何方式组合在一起。
2.5.11.1 删除冗余备份
默认情况下，使用 pg_probackup 创建的所有备份副本都存储在指定的备份目录中。为了节省磁盘空间，您可以配置保留策略以删除冗余备份副本。
要配置保留策略，请通过 set-config 在 pg_probackup.conf 文件中设置以下一个或多个变量：
--retention-redundancy=redundancy复制
指定要保留在备份目录中的完整备份副本的数量。
--retention-window=window复制
定义 pg_probackup 可以完成恢复的最早时间点。此选项设置为从当前时刻算起的天数。例如，如果retention-window=7，pg_probackup 必须至少保留一份超过7 天的备份副本，以及所有相应的WAL 文件，以及随后的所有备份。
如果同时设置了 --retention-redundancy 和 --retention-window 选项，则在清除备份目录时必须考虑这两个条件。例如，如果您设置 --retention-redundancy=2 和 --retention-window=7，pg_probackup 必须保留两个完整备份副本，以及确保过去 7 天可恢复性所需的所有备份：
pg_probackup set-config -B backup_dir --instance instance_name --retention-redundancy=2 --retention-window=7复制
要根据保留策略清理备份目录，您必须运行带有保留标志的删除命令，如下所示，或者在创建新备份时使用带有这些标志的备份命令来处理过时的备份副本。
例如，要删除不再满足定义的保留策略的所有备份副本，请使用 --delete-expired 标志运行以下命令：
pg_probackup delete -B backup_dir --instance instance_name --delete-expired复制
如果您还想删除任何备份不再需要的 WAL 文件，您还应该指定 --delete-wal 标志：
pg_probackup delete -B backup_dir --instance instance_name --delete-expired --delete-wal复制
您还可以通过在运行删除或备份命令时直接指定 --retention-redundancy 和 --retention-window 选项来设置或覆盖当前保留策略：
pg_probackup delete -B backup_dir --instance instance_name --delete-expired --retention-window=7 --retention-redundancy=2复制
由于增量备份要求其父完整备份和之前的所有增量备份都可用，因此如果任何此类备份到期，则在此链中至少有一个增量备份满足保留策略时，仍无法将其删除。为避免保留恢复活动增量备份仍需要的过期备份，您可以在运行备份或删除命令时使用 --merge-expired 标志将它们与此备份合并。
假设您已经备份了 backup_dir 目录中的节点实例，并且 --retention-window 选项设置为 7，并且您在 2019 年 4 月 10 日有以下可用备份：
BACKUP INSTANCE 'node' =================================================================================================================================== Instance Version ID Recovery time Mode WAL TLI Time Data WAL Zratio Start LSN Stop LSN Status =================================================================================================================================== node 10 P7XDHR 2019-04-10 05:27:15+03 FULL STREAM 1/0 11s 200MB 16MB 1.0 0/18000059 0/18000197 OK node 10 P7XDQV 2019-04-08 05:32:59+03 PAGE STREAM 1/0 11s 19MB 16MB 1.0 0/15000060 0/15000198 OK node 10 P7XDJA 2019-04-03 05:28:36+03 DELTA STREAM 1/0 21s 32MB 16MB 1.0 0/13000028 0/13000198 OK -------------------------------------------------------retention window-------------------------------------------------------- node 10 P7XDHU 2019-04-02 05:27:59+03 PAGE STREAM 1/0 31s 33MB 16MB 1.0 0/11000028 0/110001D0 OK node 10 P7XDHB 2019-04-01 05:27:15+03 FULL STREAM 1/0 11s 200MB 16MB 1.0 0/F000028 0/F000198 OK node 10 P7XDFT 2019-03-29 05:26:25+03 FULL STREAM 1/0 11s 200MB 16MB 1.0 0/D000028 0/D000198 OK复制
即使 P7XDHB 和 P7XDHU 备份在保留窗口之外，它们也不能被删除，因为它会使仍然需要的后续增量备份 P7XDJA 和 P7XDQV 无效，因此，如果您使用 --delete-expired 标志运行删除命令，则只有P7XDFT 完整备份将被删除。
使用 --merge-expired 选项，P7XDJA 备份与底层 P7XDHU 和 P7XDHB 备份合并并成为完整备份，因此不再需要保留这些过期备份：
pg_probackup delete -B backup_dir --instance node --delete-expired --merge-expired pg_probackup show -B backup_dir复制
BACKUP INSTANCE 'node' ================================================================================================================================== Instance Version ID Recovery time Mode WAL TLI Time Data WAL Zratio Start LSN Stop LSN Status ================================================================================================================================== node 10 P7XDHR 2019-04-10 05:27:15+03 FULL STREAM 1/0 11s 200MB 16MB 1.0 0/18000059 0/18000197 OK node 10 P7XDQV 2019-04-08 05:32:59+03 PAGE STREAM 1/0 11s 19MB 16MB 1.0 0/15000060 0/15000198 OK node 10 P7XDJA 2019-04-03 05:28:36+03 FULL STREAM 1/0 21s 32MB 16MB 1.0 0/13000028 0/13000198 OK复制
合并备份的时间字段显示合并所需的时间。
2.5.11.2 固定备份
如果您需要保留某些备份的时间超过既定的保留策略允许的时间，您可以将它们固定任意时间。例如：
pg_probackup set-backup -B backup_dir --instance instance_name -i backup_id --ttl=30d复制
此命令将指定备份的到期时间设置为从其 recovery-time 属性中指示的时间开始的 30 天。
您还可以使用 --expire-time 选项显式设置备份的到期时间。例如：
pg_probackup set-backup -B backup_dir --instance instance_name -i backup_id --expire-time="2020-01-01 00:00:00+03"复制
或者，您可以将 --ttl 和 --expire-time 选项与备份命令一起使用来固定新创建的备份：
pg_probackup backup -B backup_dir --instance instance_name -b FULL --ttl=30d pg_probackup backup -B backup_dir --instance instance_name -b FULL --expire-time="2020-01-01 00:00:00+03"复制
要检查备份是否已固定，请运行 show 命令：
pg_probackup show -B backup_dir --instance instance_name -i backup_id复制
如果备份已固定，则它具有显示其过期时间的 expire-time 属性：
... recovery-time = '2017-05-16 12:57:31' expire-time = '2020-01-01 00:00:00+03' data-bytes = 22288792 ...复制
您可以通过将 --ttl 选项设置为0来取消备份：
pg_probackup set-backup -B backup_dir --instance instance_name -i backup_id --ttl=0复制
注意
固定增量备份隐式固定其所有父备份。如果您稍后取消固定此类备份，其隐式固定的父级也将自动取消固定。
2.5.11.3 配置 WAL 存档保留策略
启用连续 WAL 归档后，归档的 WAL 段可能会占用大量磁盘空间。即使您不时删除旧的备份副本，–delete-wal 标志也只能清除那些不适用于备份目录中任何剩余备份的 WAL 段。但是，如果时间点恢复仅对最近的备份至关重要，您可以配置 WAL 存档保留策略以保持 WAL 存档的有限深度并赢回更多磁盘空间。
要配置 WAL 存档保留策略，您必须运行带有 --wal-depth 选项的 set-config 命令，该选项指定可用于 PITR 的备份数量。此设置适用于所有时间线，因此您应该能够在每个时间线上对相同数量的备份执行 PITR（如果可用）。固定的备份不包括在此计数中：如果固定了最新的备份之一，则 pg_probackup 确保 PITR 可以用于一个额外的备份。
要删除不满足定义的 WAL 存档保留策略的 WAL 段，您只需运行带有 --delete-wal 标志的删除或备份命令。对于存档备份，Start LSN 和 Stop LSN 之间的 WAL 段始终保持不变，因此无论 --wal-depth 设置如何，此类备份都保持有效，并且在需要时仍可以恢复。
您还可以将 --wal-depth 选项与删除和备份命令一起使用，以覆盖先前定义的 WAL 存档保留策略并即时清除旧的 WAL 段。
假设您已经备份了 backup_dir 目录中的节点实例并配置了连续 WAL 归档：
pg_probackup show -B backup_dir --instance node复制
BACKUP INSTANCE 'node' ==================================================================================================================================== Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status ==================================================================================================================================== node 11 PZ9442 2019-10-12 10:43:21+03 DELTA STREAM 1/0 10s 121kB 16MB 1.00 0/46000028 0/46000160 OK node 11 PZ943L 2019-10-12 10:43:04+03 FULL STREAM 1/0 10s 180MB 32MB 1.00 0/44000028 0/44000160 OK node 11 PZ7YR5 2019-10-11 19:49:56+03 DELTA STREAM 1/1 10s 112kB 32MB 1.00 0/41000028 0/41000160 OK node 11 PZ7YMP 2019-10-11 19:47:16+03 DELTA STREAM 1/1 10s 376kB 32MB 1.00 0/3E000028 0/3F0000B8 OK node 11 PZ7YK2 2019-10-11 19:45:45+03 FULL STREAM 1/0 11s 180MB 16MB 1.00 0/3C000028 0/3C000198 OK node 11 PZ7YFO 2019-10-11 19:43:04+03 FULL STREAM 1/0 10s 30MB 16MB 1.00 0/2000028 0/200ADD8 OK复制
您可以通过运行带有 --archive 标志的 show 命令来检查 WAL 存档的状态：
pg_probackup show -B backup_dir --instance node --archive复制
ARCHIVE INSTANCE 'node' =============================================================================================================================== TLI Parent TLI Switchpoint Min Segno Max Segno N segments Size Zratio N backups Status =============================================================================================================================== 1 0 0/0 000000010000000000000001 000000010000000000000047 71 36MB 31.00 6 OK复制
没有 --wal-depth 的 WAL purge 不能实现太多，只删除了一个段：
pg_probackup delete -B backup_dir --instance node --delete-wal复制
ARCHIVE INSTANCE 'node' =============================================================================================================================== TLI Parent TLI Switchpoint Min Segno Max Segno N segments Size Zratio N backups Status =============================================================================================================================== 1 0 0/0 000000010000000000000002 000000010000000000000047 70 34MB 32.00 6 OK复制
例如，如果您希望仅保留可应用于最新有效备份的 WAL 段，请将 --wal-depth 选项设置为 1：
ARCHIVE INSTANCE 'node' ================================================================================================================================ TLI Parent TLI Switchpoint Min Segno Max Segno N segments Size Zratio N backups Status ================================================================================================================================ 1 0 0/0 000000010000000000000046 000000010000000000000047 2 143kB 228.00 6 OK复制
或者，您可以将 --wal-depth 选项与备份命令一起使用：
pg_probackup backup -B backup_dir --instance node -b DELTA --wal-depth=1 --delete-wal复制
ARCHIVE INSTANCE 'node' =============================================================================================================================== TLI Parent TLI Switchpoint Min Segno Max Segno N segments Size Zratio N backups Status =============================================================================================================================== 1 0 0/0 000000010000000000000048 000000010000000000000049 1 72kB 228.00 7 OK复制
2.5.12 合并备份
随着您进行越来越多的增量备份，备份目录的总大小会大幅增长。为了节省磁盘空间，您可以通过运行 merge 命令将增量备份合并到其父完整备份，指定要合并的最新增量备份的备份 ID：
pg_probackup merge -B backup_dir --instance instance_name -i backup_id复制
此命令合并属于公共增量备份链的备份。如果您指定完整备份，它将与其第一个增量备份合并。如果您指定增量备份，它将与父完整备份以及它们之间的所有增量备份一起合并。合并完成后，完整备份会接收所有合并的数据，而增量备份将作为冗余数据删除。因此，合并操作实际上等同于重新进行完整备份并删除所有过时的备份，但它可以节省大量时间，特别是对于大数据量以及 I/O 和网络流量，如果您在远程模式。
在合并之前，pg_probackup 会验证所有受影响的备份以确保它们是有效的。您可以通过使用备份 ID 运行 show 命令来检查当前备份状态：
pg_probackup show -B backup_dir --instance instance_name -i backup_id复制
如果合并仍在进行中，则备份状态显示为 MERGING。对于完整备份，当元数据在合并的最后阶段更新时，它也可以显示为 MERGED。合并是幂等的，所以如果它被中断了你可以重新开始合并。
2.5.13 删除备份
要删除不再需要的备份，请运行以下命令：
pg_probackup delete -B backup_dir --instance instance_name -i backup_id复制
此命令将删除具有指定 backup_id 的备份，以及从 backup_id 下降的所有增量备份（如果有）。通过这种方式，您可以删除一些最近的增量备份，保留底层完整备份和其后的一些增量备份。
要删除不需要恢复任何剩余备份的过时 WAL 文件，请使用 --delete-wal 标志：
pg_probackup delete -B backup_dir --instance instance_name --delete-wal复制
要删除根据当前保留策略过期的备份，请使用 --delete-expired 标志：
pg_probackup delete -B backup_dir --instance instance_name --delete-expired复制
当至少一个满足保留策略的增量备份基于它们时，无法删除过期的备份。如果您想尽量减少保持增量备份有效所需的备份数量，请在运行此命令时指定 --merge-expired 标志：
pg_probackup delete -B backup_dir --instance instance_name --delete-expired --merge-expired复制
在这种情况下，pg_probackup 搜索满足保留策略的最旧的增量备份，并将此备份与已经过期的底层完整备份和增量备份合并，从而使其成为完整备份。合并完成后，剩余的过期备份将被删除。
在合并或删除备份之前，您可以运行带有 --dry-run 标志的删除命令，该标志根据当前保留策略显示所有可用备份的状态，而不执行任何不可逆的操作。
要删除具有特定状态的所有备份，请使用 --status：
pg_probackup delete -B backup_dir --instance instance_name --status=ERROR复制
按状态删除备份会忽略已建立的保留策略。
2.5.14 克隆和同步 PostgreSQL 实例
pg_probackup 可以直接创建 PostgreSQL 实例的副本，而无需使用备份目录。为此，您可以运行 catchup 命令。它在以下情况下很有用：
- 添加新的备用服务器。
通常，pg_basebackup 用于创建 PostgreSQL 实例的副本。如果目标实例的数据目录为空，则 catchup 命令的工作方式类似，但如果以并行模式运行，则速度会更快。
- 让落后的备用服务器“赶上”主服务器。
在写入密集型负载下，副本可能无法以足够快的速度重播 WAL 以跟上主节点，因此可能会落后。创建新副本并切换到它的常用解决方案需要大量额外空间和数据传输。 catchup 命令允许您通过带来与 master 的差异来更快地更新现有副本。
catchup 与其他 pg_probackup 操作不同：
-
不需要备份目录。
-
仅支持 STREAM WAL 交付模式。
-
不支持复制外部目录。
-
DDL 命令 CREATE TABLESPACE/DROP TABLESPACE 不能与 catchup 同时运行。
-
catchup 从源服务器获取配置文件，例如 postgresql.conf、postgresql.auto.conf 或 pg_hba.conf，并在目标服务器上覆盖它们。 --exclude-path 选项允许您保持配置文件完整。
要准备克隆/同步 PostgreSQL 实例，请按如下方式设置源实例服务器：
-
为要复制的实例配置数据库集群。
-
要从远程服务器复制，请配置远程模式。
-
要使用 PTRACK 追赶模式，请设置 PTRACK 备份。
在克隆/同步 PostgreSQL 实例之前，请确保源实例服务器正在运行并接受连接。要克隆/同步 PostgreSQL 实例，在具有目标实例的服务器上，您可以运行 catchup 命令，如下所示：
pg_probackup catchup -b catchup_mode --source-pgdata=path_to_pgdata_on_remote_server --destination-pgdata=path_to_local_dir --stream [connection_options] [remote_options]复制
catchup_mode 可以采用以下值之一：FULL、DELTA 或 PTRACK。
-
FULL — 创建 PostgreSQL 实例的完整副本。对于此模式，目标实例的数据目录必须为空。
-
DELTA — 读取数据目录中的所有数据文件，并为自目标实例关闭以来已更改的页面创建增量副本。
-
PTRACK — 动态跟踪页面更改，仅读取和复制自源实例和目标实例分歧点以来发生更改的页面。
警告
PTRACK 追赶模式要求 PTRACK 不早于 2.0，因此 PostgreSQL 不早于 11。
通过指定 --stream 选项，您可以设置复制的 STREAM WAL 交付模式，该模式将通过复制协议从实例服务器流式传输所有必要的 WAL 文件。
您可以使用 connection_options 指定与源数据库集群的连接。如果它位于不同的服务器上，还要指定 remote_options。
如果源数据库集群包含必须位于不同目录中的表空间，请另外指定 --tablespace-mapping 选项：
pg_probackup catchup -b catchup_mode --source-pgdata=path_to_pgdata_on_remote_server --destination-pgdata=path_to_local_dir --stream --tablespace-mapping=OLDDIR=NEWDIR复制
要在并行线程上运行 catchup 命令，请使用 --threads 选项指定线程数：
pg_probackup catchup -b catchup_mode --source-pgdata=path_to_pgdata_on_remote_server --destination-pgdata=path_to_local_dir --stream --threads=num_threads复制
例如，假设具有 /replica-pgdata 数据目录的 PostgreSQL 实例的远程备用服务器已落后。要将此实例与 /master-pgdata 数据目录中的实例同步，您可以在 PTRACK 模式下在四个并行线程上运行 catchup 命令，如下所示：
pg_probackup catchup --source-pgdata=/master-pgdata --destination-pgdata=/replica-pgdata -p 5432 -d postgres -U remote-postgres-user --stream --backup-mode=PTRACK --remote-host =remote-hostname --remote-user=remote-unix-username -j 4 --exclude-path=postgresql.conf --exclude-path=postgresql.auto.conf --exclude-path=pg_hba.conf --exclude -path=pg_ident.conf复制
请注意，在此示例中，配置文件不会在同步期间被覆盖。
另一个示例显示了如何通过在四个并行线程上以 FULL 模式运行 catchup 命令来添加具有 PostgreSQL 数据目录 /replica-pgdata 的新远程备用服务器：
pg_probackup catchup --source-pgdata=/master-pgdata --destination-pgdata=/replica-pgdata -p 5432 -d postgres -U remote-postgres-user --stream --backup-mode=FULL --remote-host=remote-hostname --remote-user=remote-unix-username -j 4复制
2.6 示例
下面的所有示例都假定通过 SSH 进行远程操作模式。如果您计划在本地运行备份和恢复操作，请跳过“设置无密码 SSH 连接”步骤并省略所有 --remote-* 选项。
示例基于 Ubuntu 18.04、PostgreSQL 11 和 pg_probackup 2.2.0。
-
backu — 用于连接到 PostgreSQL 集群的 PostgreSQL 角色。
-
backupdb — 用于连接 PostgreSQL 集群的数据库。
-
backup_host — 具有备份目录的主机。
-
backupman — backup_host 上运行所有 pg_probackup 操作的用户。
-
/mnt/backups — backup_host 上存储备份目录的目录。
-
postgres_host — 带有 PostgreSQL 集群的主机。
-
postgres — postgres_host 上已启动 PostgreSQL 集群的用户。
-
/var/lib/postgresql/11/main — postgres_host 上的 PostgreSQL 数据目录。
最小设置
此方案说明了如何设置独立的 FULL 和 DELTA 备份。
1.设置从 backup_host 到 postgres_host 的无密码 SSH 连接：
[backupman@backup_host] ssh-copy-id postgres@postgres_host复制
2.配置您的 PostgreSQL 集群。
出于安全考虑，建议使用单独的数据库进行备份操作。
postgres=# CREATE DATABASE backupdb;复制
连接 backupdb 数据库，创建 probackup 角色，并授予该角色以下权限：
backupdb=# BEGIN; CREATE ROLE backup WITH LOGIN REPLICATION; GRANT USAGE ON SCHEMA pg_catalog TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.current_setting(text) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.set_config(text, text, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_is_in_recovery() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_start_backup(text, boolean, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_stop_backup(boolean, boolean) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_create_restore_point(text) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_wal() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_last_wal_replay_lsn() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_current() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_current_snapshot() TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.txid_snapshot_xmax(txid_snapshot) TO backup; GRANT EXECUTE ON FUNCTION pg_catalog.pg_control_checkpoint() TO backup; COMMIT;复制
3.初始化备份目录：
[backupman@backup_host]$ pg_probackup-11 init -B /mnt/backups INFO: Backup catalog '/mnt/backups' successfully inited复制
4.将实例 pg-11 添加到备份目录：
[backupman@backup_host]$ pg_probackup-11 add-instance -B /mnt/backups --instance pg-11 --remote-host=postgres_host --remote-user=postgres -D /var/lib/postgresql/11/main INFO: Instance 'node' successfully inited复制
5.进行完整备份：
[backupman@backup_host] pg_probackup-11 backup -B /mnt/backups --instance pg-11 -b FULL --stream --remote-host=postgres_host --remote-user=postgres -U backup -d backupdb INFO: Backup start, pg_probackup version: 2.2.0, instance: node, backup ID: PZ7YK2, backup mode: FULL, wal mode: STREAM, remote: true, compress-algorithm: none, compress-level: 1 INFO: Start transferring data files INFO: Data files are transferred INFO: wait for pg_stop_backup() INFO: pg_stop backup() successfully executed INFO: Validating backup PZ7YK2 INFO: Backup PZ7YK2 data files are valid INFO: Backup PZ7YK2 resident size: 196MB INFO: Backup PZ7YK2 completed复制
6.我们来看看备份目录：
[backupman@backup_host] pg_probackup-11 show -B /mnt/backups --instance pg-11 BACKUP INSTANCE 'pg-11' ================================================================================================================================== Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status ================================================================================================================================== node 11 PZ7YK2 2019-10-11 19:45:45+03 FULL STREAM 1/0 11s 180MB 16MB 1.00 0/3C000028 0/3C000198 OK复制
7.在 DELTA 模式下进行增量备份：
[backupman@backup_host] pg_probackup-11 backup -B /mnt/backups --instance pg-11 -b delta --stream --remote-host=postgres_host --remote-user=postgres -U backup -d backupdb INFO: Backup start, pg_probackup version: 2.2.0, instance: node, backup ID: PZ7YMP, backup mode: DELTA, wal mode: STREAM, remote: true, compress-algorithm: none, compress-level: 1 INFO: Parent backup: PZ7YK2 INFO: Start transferring data files INFO: Data files are transferred INFO: wait for pg_stop_backup() INFO: pg_stop backup() successfully executed INFO: Validating backup PZ7YMP INFO: Backup PZ7YMP data files are valid INFO: Backup PZ7YMP resident size: 32MB INFO: Backup PZ7YMP completed复制
8.让我们在 pg_probackup 配置文件中添加一些参数，以便您可以在命令行中省略它们：
[backupman@backup_host] pg_probackup-11 set-config -B /mnt/backups --instance pg-11 --remote-host=postgres_host --remote-user=postgres -U backup -d backupdb复制
9.以 DELTA 模式进行另一次增量备份，省略一些前面的参数：
[backupman@backup_host] pg_probackup-11 backup -B /mnt/backups --instance pg-11 -b delta --stream INFO: Backup start, pg_probackup version: 2.2.0, instance: node, backup ID: PZ7YR5, backup mode: DELTA, wal mode: STREAM, remote: true, compress-algorithm: none, compress-level: 1 INFO: Parent backup: PZ7YMP INFO: Start transferring data files INFO: Data files are transferred INFO: wait for pg_stop_backup() INFO: pg_stop backup() successfully executed INFO: Validating backup PZ7YR5 INFO: Backup PZ7YR5 data files are valid INFO: Backup PZ7YR5 resident size: 32MB INFO: Backup PZ7YR5 completed复制
10.我们看一下实例配置：
[backupman@backup_host] pg_probackup-11 show-config -B /mnt/backups --instance pg-11 # Backup instance information pgdata = /var/lib/postgresql/11/main system-identifier = 6746586934060931492 xlog-seg-size = 16777216 # Connection parameters pgdatabase = backupdb pghost = postgres_host pguser = backup # Replica parameters replica-timeout = 5min # Archive parameters archive-timeout = 5min # Logging parameters log-level-console = INFO log-level-file = OFF log-filename = pg_probackup.log log-rotation-size = 0 log-rotation-age = 0 # Retention parameters retention-redundancy = 0 retention-window = 0 wal-depth = 0 # Compression parameters compress-algorithm = none compress-level = 1 # Remote access parameters remote-proto = ssh remote-host = postgres_host复制
请注意，我们正在获取未被 set-config 命令覆盖的其他选项的默认值。
11.我们来看看备份目录：
[backupman@backup_host] pg_probackup-11 show -B /mnt/backups --instance pg-11 ==================================================================================================================================== Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status ==================================================================================================================================== node 11 PZ7YR5 2019-10-11 19:49:56+03 DELTA STREAM 1/1 10s 112kB 32MB 1.00 0/41000028 0/41000160 OK node 11 PZ7YMP 2019-10-11 19:47:16+03 DELTA STREAM 1/1 10s 376kB 32MB 1.00 0/3E000028 0/3F0000B8 OK node 11 PZ7YK2 2019-10-11 19:45:45+03 FULL STREAM 1/0 11s 180MB 16MB 1.00 0/3C000028 0/3C000198 OK复制
文章被以下合辑收录
评论
0 点赞
