CNDBA社区
在之前的博客，我们了解了openGauss 的备份恢复概念，如下：
openGauss 备份恢复 说明
https://www.cndba.cn/dave/article/116548
openGauss 闪回恢复 操作示例
https://www.cndba.cn/dave/article/116546
openGauss 逻辑备份与恢复 操作示例
https://www.cndba.cn/dave/article/116549
本篇我们来学习下opengauss的物理备份与恢复。
物理备份与恢复通过物理文件拷贝的方式对数据库进行备份，以磁盘块为基本单位将数据从主机复制到备机。通过备份的数据文件及归档日志等文件，数据库可以进行完全恢复。
物理备份速度快，一般被用作对数据进行备份和恢复，适用于数据量大的场景，主要用于全量数据备份恢复，也可对整个数据库中的WAL归档日志和运行日志进行备份。
1 gs_backup（备份参数和app bin文件）
注意该工具不是备份数据文件的，仅导出数据库参数文件和二进制文件（app目录下）。帮助openGauss备份、恢复重要数据、显示帮助信息和版本号信息。
1.1 查看命令帮助
[dave@www.cndba.cn ~]$ gs_backup --help
gs_backup is a utility to back up or restore binary files and parameter files.
Usage:
gs_backup -? | --help
gs_backup -V | --version
gs_backup -t backup --backup-dir=BACKUPDIR [-h HOSTNAME] [--parameter]
[--binary] [--all] [-l LOGFILE]
gs_backup -t restore --backup-dir=BACKUPDIR [-h HOSTNAME] [--parameter]
[--binary] [--all] [-l LOGFILE]
[--force]
General options:
-t Operation type. It can be backup or restore.
--backup-dir=BACKUPDIR Backup or restore directory.
-h The node which stored the backup file,
need to specify the node when recovering.
If the node name is not specified,
the backup sets are stored in each node.
--parameter Back up or restore parameter files only.
(This option is used by default.)
--binary Back up or restore binary files only.
--all Back up or restore both parameter files and binary files.
--force Force to restore binary files even if the
cluster_static_config is lost
-l Path of log file.
-?, --help Show help information for this utility,
and exit the command line mode.
-V, --version Show version information.
[dave@www.cndba.cn ~]$
这里重要的参数只有3个：
- –parameter： 备份参数文件，不指定–parameter、–binary、–all参数时默认只备份参数文件。
- –binary：备份app目录下的二进制文件。
- –all：备份app目录下的二进制文件、pg_hba.conf和postgsql.conf文件。
1.2 操作示例
1.2.1 备份
[dave@www.cndba.cn backup]$ gs_backup -t backup --backup-dir=/data/backup -h oracle --parameter
Parsing configuration files.
Successfully parsed the configuration file.
Performing remote backup.
Remote backup succeeded.
Successfully backed up cluster files.
[dave@www.cndba.cn backup]$ gs_backup -t backup --backup-dir=/data/backup -h oracle --binary
Parsing configuration files.
Successfully parsed the configuration file.
Performing remote backup.
Remote backup succeeded.
Successfully backed up cluster files.
[dave@www.cndba.cn backup]$ ll
总用量 513240
-rw------- 1 omm dbgrp 525496320 4月 17 10:07 binary.tar
-rw------- 1 omm dbgrp 61440 4月 17 10:06 parameter.tar
[dave@www.cndba.cn backup]$ rm -rf *
[dave@www.cndba.cn backup]$ gs_backup -t backup --backup-dir=/data/backup -h oracle --all
Parsing configuration files.
Successfully parsed the configuration file.
Performing remote backup.
Remote backup succeeded.
Successfully backed up cluster files.
[dave@www.cndba.cn backup]$ ll
总用量 513240
-rw------- 1 omm dbgrp 525496320 4月 17 10:08 binary.tar
-rw------- 1 omm dbgrp 61440 4月 17 10:08 parameter.tar
[dave@www.cndba.cn backup]$
可以看到，当添加--all时，也是分别生成2个文件：binary.tar 和 parameter.tar。
1.2.2 恢复
[dave@www.cndba.cn backup]$
[dave@www.cndba.cn backup]$ gs_backup -t restore --backup-dir=/data/backup -h oracle --parameter
Parsing configuration files.
Successfully parsed the configuration file.
Performing remote restoration.
Successfully restored cluster files.
[dave@www.cndba.cn backup]$ gs_backup -t restore --backup-dir=/data/backup -h oracle --binary
Parsing configuration files.
Successfully parsed the configuration file.
Performing remote restoration.
Successfully restored cluster files.
[dave@www.cndba.cn backup]$ gs_backup -t restore --backup-dir=/data/backup -h oracle --all
Parsing configuration files.
Successfully parsed the configuration file.
Performing remote restoration.
Successfully restored cluster files.
[dave@www.cndba.cn backup]$
2 gs_basebackup 工具
gs_backup 工具仅能备份参数文件和app 下的bin文件，因此生产环境还需要使用gs_basebackup工具对服务器数据库文件的二进制进行全量拷贝，只能对数据库某一个时间点的时间作备份。
结合PITR恢复，可恢复全量备份时间点后的某一时间点。恢复时可以直接拷贝替换原有的文件，或者直接在备份的库上启动数据库，恢复时间快。
注意gs_basebackup有如下限制：
- gs_basebackup仅支持主机和备机的全量备份，不支持增量。
- gs_basebackup当前支持热备份模式和压缩格式备份。
- gs_basebackup在备份包含绝对路径的表空间时，如果在同一台机器上进行备份，可以通过tablespace-mapping重定向表空间路径，或使用归档模式进行备份。
2.1 命令帮助
[dave@www.cndba.cn backup]$ gs_basebackup --help
gs_basebackup takes a base backup of a running openGauss server.
Usage:
gs_basebackup [OPTION]...
Options controlling the output:
-D, --pgdata=DIRECTORY receive base backup into directory
-F, --format=p|t output format (plain (default), tar)
-T, --tablespace-mapping=OLDDIR=NEWDIR
relocate tablespace in OLDDIR to NEWDIR
-x, --xlog include required WAL files in backup (fetch mode)
-X, --xlog-method=fetch|stream
include required WAL files with specified method
-z, --gzip compress tar output
-Z, --compress=0-9 compress tar output with given compression level
General options:
-c, --checkpoint=fast|spread
set fast or spread checkpointing
-l, --label=LABEL set backup label
-P, --progress show progress information
-v, --verbose output verbose messages
-V, --version output version information, then exit
-?, --help show this help, then exit
Connection options:
-h, --host=HOSTNAME database server host or socket directory
-p, --port=PORT database server port number
-s, --status-interval=INTERVAL
time between status packets sent to server (in seconds)
-t, --rw-timeout=RW_TIMEOUT
read-write timeout during idle connection.(in seconds)
-U, --username=NAME connect as specified database user
-w, --no-password never prompt for password
-W, --password force password prompt (should happen automatically)
Report bugs to community@opengauss.org> or join opengauss community <https://opengauss.org>.
[dave@www.cndba.cn backup]$
2.2 gs_basebackup 操作示例
2.2.1 备份
[dave@www.cndba.cn backup]$ gs_basebackup -D /data/backup -h localhost -p 15500
INFO: The starting position of the xlog copy of the full build is: 0/15603E18. The slot minimum LSN is: 0/15603E18. The disaster slot minimum LSN is: 0/0. The logical slot minimum LSN is: 0/0.
[2023-04-17 11:24:36]:begin build tablespace list
[2023-04-17 11:24:36]:finish build tablespace list
[2023-04-17 11:24:36]:begin get xlog by xlogstream
[2023-04-17 11:24:36]: check identify system success
[2023-04-17 11:24:36]: send START_REPLICATION 0/15000000 success
[2023-04-17 11:24:36]: keepalive message is received
[2023-04-17 11:24:41]: keepalive message is received
[2023-04-17 11:24:46]:gs_basebackup: base backup successfully
[dave@www.cndba.cn backup]$ ll
总用量 5016
-rw------- 1 omm dbgrp 208 4月 17 11:24 backup_label
-rw------- 1 omm dbgrp 175 4月 17 11:24 backup_label.old
drwx------ 7 omm dbgrp 67 4月 17 11:24 base
-rw------- 1 omm dbgrp 0 4月 17 11:24 build_completed.done
-rw------- 1 omm dbgrp 4399 4月 17 11:24 cacert.pem
drwx------ 4 omm dbgrp 82 4月 17 11:24 dbe_perf_standby
-rw------- 1 omm dbgrp 57 4月 17 11:24 full_backup_label
drwx------ 2 omm dbgrp 4096 4月 17 11:24 global
-rw------- 1 omm dbgrp 4915200 4月 17 11:24 gswlm_userinfo.cfg
-rw------- 1 omm dbgrp 21016 4月 17 11:24 mot.conf
drwx------ 2 omm dbgrp 26 4月 17 11:24 pg_clog
drwx------ 2 omm dbgrp 26 4月 17 11:24 pg_csnlog
-rw------- 1 omm dbgrp 0 4月 17 11:24 pg_ctl.lock
drwx------ 2 omm dbgrp 6 4月 17 11:24 pg_errorinfo
-rw------- 1 omm dbgrp 4885 4月 17 11:24 pg_hba.conf
-rw------- 1 omm dbgrp 4885 4月 17 11:24 pg_hba.conf.bak
-rw------- 1 omm dbgrp 1024 4月 17 11:24 pg_hba.conf.lock
-rw------- 1 omm dbgrp 1636 4月 17 11:24 pg_ident.conf
drwx------ 4 omm dbgrp 39 4月 17 11:24 pg_llog
drwx------ 2 omm dbgrp 35 4月 17 11:24 pg_logical
drwx------ 4 omm dbgrp 36 4月 17 11:24 pg_multixact
drwx------ 2 omm dbgrp 26 4月 17 11:24 pg_notify
drwx------ 2 omm dbgrp 6 4月 17 11:24 pg_replslot
drwx------ 2 omm dbgrp 6 4月 17 11:24 pg_serial
drwx------ 2 omm dbgrp 6 4月 17 11:24 pg_snapshots
drwx------ 2 omm dbgrp 25 4月 17 11:24 pg_stat_tmp
drwx------ 2 omm dbgrp 6 4月 17 11:24 pg_tblspc
drwx------ 2 omm dbgrp 6 4月 17 11:24 pg_twophase
-rw------- 1 omm dbgrp 4 4月 17 11:24 PG_VERSION
drwx------ 3 omm dbgrp 4096 4月 17 11:24 pg_xlog
-rw------- 1 omm dbgrp 36583 4月 17 11:24 postgresql.conf
-rw------- 1 omm dbgrp 36583 4月 17 11:24 postgresql.conf.guc.bak
-rw------- 1 omm dbgrp 1024 4月 17 11:24 postgresql.conf.lock
-rw------- 1 omm dbgrp 36466 4月 17 11:24 postgresql.conf.wal.bak
-rw------- 1 omm dbgrp 0 4月 17 11:24 postmaster.pid.lock
-rw------- 1 omm dbgrp 4402 4月 17 11:24 server.crt
-rw------- 1 omm dbgrp 1766 4月 17 11:24 server.key
-rw------- 1 omm dbgrp 56 4月 17 11:24 server.key.cipher
-rw------- 1 omm dbgrp 24 4月 17 11:24 server.key.rand
-rw------- 1 omm dbgrp 4 4月 17 11:24 term_file
drwx------ 5 omm dbgrp 67 4月 17 11:24 undo
[dave@www.cndba.cn backup]$
我们这里没有采用压缩，直接进行的复制备份。
2.2.2 恢复
模拟故障，把文件都删了：
[dave@www.cndba.cn backup]$ ps -ef|grep openG
omm 27193 1 9 4月13 ? 09:28:05 /data/openGauss/install/app/bin/gaussdb -D /data/openGauss/install/data/dn -M primary
omm 27393 6109 0 11:27 pts/0 00:00:00 grep --color=auto openG
omm 28103 1 15 4月11 ? 22:51:42 /data/openGauss/install/app/bin/cm_server
omm 28724 1 1 10:30 ? 00:00:55 /data/openGauss/install/app/bin/om_monitor -L /var/log/omm/omm/cm/om_monitor
omm 28730 28724 19 10:30 ? 00:10:53 /data/openGauss/install/app/bin/cm_agent
[dave@www.cndba.cn backup]$ cd /data/openGauss/install/data/dn
[dave@www.cndba.cn dn]$ pwd
/data/openGauss/install/data/dn
[dave@www.cndba.cn dn]$ ls
backup_label.old global pg_ctl.lock pg_location pg_snapshots postgresql.conf.guc.bak server.key
base gs_build.pid pg_errorinfo pg_logical pg_stat_tmp postgresql.conf.lock server.key.cipher
build_completed.done gs_gazelle.conf pg_hba.conf pg_multixact pg_tblspc postgresql.conf.wal.bak server.key.rand
cacert.pem gswlm_userinfo.cfg pg_hba.conf.bak pg_notify pg_twophase postmaster.opts term_file
dbe_perf_standby mot.conf pg_hba.conf.lock pg_replslot PG_VERSION postmaster.pid undo
disable_conn_file pg_clog pg_ident.conf pg_rewind_filemap pg_xlog postmaster.pid.lock
full_backup_label pg_csnlog pg_llog pg_serial postgresql.conf server.crt
[dave@www.cndba.cn dn]$ rm -rf *
[dave@www.cndba.cn dn]$
[dave@www.cndba.cn dn]$ gs_ctl stop -D /data/openGauss/install/data/dn
恢复：
因为gs_basebackup的备份是物理复制，所以直接cp 恢复即可。
[dave@www.cndba.cn dn]$ cp -r /data/backup/* .
[dave@www.cndba.cn dn]$ ls
backup_label full_backup_label pg_csnlog pg_ident.conf pg_serial pg_xlog postmaster.pid.lock undo
backup_label.old gaussdb.state pg_ctl.lock pg_llog pg_snapshots postgresql.conf server.crt
base global pg_errorinfo pg_logical pg_stat_tmp postgresql.conf.guc.bak server.key
build_completed.done gswlm_userinfo.cfg pg_hba.conf pg_multixact pg_tblspc postgresql.conf.lock server.key.cipher
cacert.pem mot.conf pg_hba.conf.bak pg_notify pg_twophase postgresql.conf.wal.bak server.key.rand
dbe_perf_standby pg_clog pg_hba.conf.lock pg_replslot PG_VERSION postmaster.pid term_file
[dave@www.cndba.cn dn]$
启动库：
[dave@www.cndba.cn dn]$ gs_ctl start -D /data/openGauss/install/data/dn
3 gs_basebackup + PITR 恢复
3.1 PITR（Point-In-Time Recovery） 概述
当数据库崩溃或希望回退到数据库之前的某一状态时，openGauss的即时恢复功能（Point-In-Time Recovery，简称PITR）可以支持恢复到备份归档数据之后的任意时间点。
PITR仅支持恢复到物理备份数据之后的某一时间点。仅主节点可以进行PITR恢复，备机需要进行全量build达成与主机数据同步。
PITR恢复流程：
- 将物理备份的文件替换目标数据库目录。
- 删除数据库目录下pg_xlog/中的所有文件。
- 将归档的WAL日志文件复制到pg_xlog文件中（此步骤可以省略，通过配置recovery.conf恢复命令文件中的restore_command项替代）。
- 在数据库目录下创建恢复命令文件recovery.conf，指定数据库恢复的程度。
- 启动数据库。
- 连接数据库，查看是否恢复到希望预期的状态。
- 若已经恢复到预期状态，通过pg_xlog_replay_resume()指令使主节点对外提供服务。
当然利用PITR 的另一个前提是启用了归档，具体参考之前的博客：
OpenGauss WAL 日志 与 归档 配置
https://www.cndba.cn/dave/article/116488openGauss 5.0.0 参数 查看 与 修改
https://www.cndba.cn/dave/article/116536
3.2 gs_basebackup 物理全备
上节gs_baseback 备份时没有采用压缩， 也没有采用备份wal日志，我们这里启用压缩加备份wal日志。
[dave@www.cndba.cn backup]$ gs_basebackup -h 127.0.0.1 -p 15500 -U omm -W -D /data/backup -Xf -Ft -z -Pv -Z=9
Password:
INFO: The starting position of the xlog copy of the full build is: 0/3A000028. The slot minimum LSN is: 0/3A000148. The disaster slot minimum LSN is: 0/0. The logical slot minimum LSN is: 0/0.
[2023-04-17 15:47:03]:transaction log start point: 0/3A000028
[2023-04-17 15:47:03]:begin build tablespace list
[2023-04-17 15:47:03]:finish build tablespace list
615046/615046 kB (100%), 1/1 tablespace
[2023-04-17 15:47:05]:transaction log end point: 0/3A000688
[2023-04-17 15:47:05]:gs_basebackup: fetching MOT checkpoint
gs_basebackup: no mot checkpoint exists
[2023-04-17 15:47:05]:gs_basebackup: base backup completed
[2023-04-17 15:47:05]:gs_basebackup: base backup successfully
[dave@www.cndba.cn backup]$
[dave@www.cndba.cn backup]$ ll -lh
总用量 601M
-rw------- 1 omm dbgrp 601M 4月 17 15:47 base.tar
[dave@www.cndba.cn backup]$
相关参数说明：
F：t tar 格式输出；p plain原样输出
z：输出的tar备份经过gzip压缩
P：实时的打印备份的进度
v：详细模式，当使用-P，还会打印出正在备份哪个具体文件的信息
l：指定备份的一个标识 lable
R：write configuration for replication
X：备份的模式，串行和并行
f ：fetch串行复制，数据复制完，再复制wal日志，如果使用tar格式，预写式日志文件将被写入到base.tar文件。
s ：stream并行复制，数据和wal日志同步复制，如果使用tar格式，预写式日志文件被写入到一个单独的名为pg_wal.tar的文件；这个值是默认值。
3.3 恢复全备
因为gs_basebackup 的恢复是物理的复制，所以恢复就是一个解压缩的过程。 这里要留意对WAL 目录的处理，因为在故障时刻，最新的一个WAL 还没有来得及归档，如果没有把这个文件复制出来，那么基于WAL归档的恢复就会丢失最后一个WAL 的数据，默认情况下，一个WAL 是16M，还是有不少数据的。
这里如果是恢复到其他目录，那么则没有还可以从故障原库的WAL 目录复制过来，如果是恢复到相同的目录，那么需要再恢复直接，先备份一下WAL 目录。
我们这里恢复到新目录进行验证。
因为之前已经有了全备，这里先创建一个测试表在恢复：
openGauss=# create table cndba(id int,website varchar2(100));
CREATE TABLE
openGauss=# select * from cndba;
id | website
----+----------------------
1 | https://www.cndba.cn
(1 row)
openGauss=#
这表表不在我们的备份和归档中。
我们执行恢复：
[dave@www.cndba.cn backup]$ mkdir /data/openGauss/install/data/cndba
[dave@www.cndba.cn backup]$ gs_tar -F base.tar -D /data/openGauss/install/data/cndba
注意，openGauss的tar 文件必须使用gs_tar 来解压缩。
3.4 配置PITR 恢复文件recovery.conf
在数据库目录下创建恢复命令文件recovery.conf，指定数据库恢复的程度。
openGauss=# select sysdate;
sysdate
---------------------
2023-04-17 15:54:10
(1 row)
[dave@www.cndba.cn cndba]$ cat recovery.conf
#### 归档恢复配置 ####
restore_command = 'cp /data/openGauss/archivelog/%f %p' ## 该SHELL命令获取已归档的WAL文件。
archive_cleanup_command = 'pg_archivecleanup /data/openGauss/archivelog %r' ## 清理备库WAL归档日志的shell命令，每次重启时会执行
## 说明：
## %f即归档检索中的文件名，%p即复制目的地的路径名，%r最新可用重启点的文件名
## 如果多个备机从相同的归档路径恢复时，需要确保该路径存在所有备机恢复所需要的WAL文件。
#### 恢复目标设置(四选一) ####
#recovery_target_name = 'restore_point_1' ## 还原到一个使用pg_create_restore_point()创建的还原点
#recovery_target_time = '2023-04-17 15:54:10' ## 还原到一个指定时间戳
#recovery_target_xid = '3000' ## 还原到一个事务ID
#recovery_target_lsn = '0/0FFFFFF' ## 还原到日志的指定LSN点
#recovery_target_inclusive = true ## 声明是否在指定恢复目标之后停止(true) 或 之前停止(false),不支持recovery_target_name 配置
#注意：如果不配置任何恢复目标 或 配置目标不存在，则默认恢复到最新的WAL日志点。
[dave@www.cndba.cn cndba]$
我们这里不指定恢复的时间点，直接恢复到最新的WAL 日志点。
3.5 处理最新的WAL 日志
先查看恢复之后的pg_xlog:
[dave@www.cndba.cn cndba]$ cd pg_xlog/
[dave@www.cndba.cn pg_xlog]$ ll
总用量 16384
-rw------- 1 omm dbgrp 16777216 4月 17 16:19 00000001000000000000003A
drwx------ 2 omm dbgrp 43 4月 17 16:19 archive_status
[dave@www.cndba.cn pg_xlog]$
这里面的3A肯定不是最新的了，我们查看归档，已经到了3C：
[dave@www.cndba.cn archivelog]$ ll
总用量 163844
-rw------- 1 omm dbgrp 16777216 4月 17 15:42 000000010000000000000027
-rw------- 1 omm dbgrp 16777216 4月 17 15:49 000000010000000000000028
-rw------- 1 omm dbgrp 16777216 4月 17 15:50 000000010000000000000029
-rw------- 1 omm dbgrp 16777216 4月 17 16:00 00000001000000000000002A
-rw------- 1 omm dbgrp 16777216 4月 17 16:01 00000001000000000000002B
-rw------- 1 omm dbgrp 16777216 4月 17 15:41 000000010000000000000038
-rw------- 1 omm dbgrp 16777216 4月 17 15:47 000000010000000000000039
-rw------- 1 omm dbgrp 16777216 4月 17 15:47 00000001000000000000003A
-rw------- 1 omm dbgrp 305 4月 17 15:47 00000001000000000000003A.00000028.backup
-rw------- 1 omm dbgrp 16777216 4月 17 16:00 00000001000000000000003B
-rw------- 1 omm dbgrp 16777216 4月 17 16:00 00000001000000000000003C
[dave@www.cndba.cn archivelog]$
而原旧库wal 目录最新的一个已经是3D：
[dave@www.cndba.cn pg_xlog]$ pwd
/data/openGauss/install/data/dn/pg_xlog
[dave@www.cndba.cn pg_xlog]$ ll -lrt
总用量 524296
……
-rw------- 1 omm dbgrp 16777216 4月 17 16:00 00000001000000000000003B
-rw------- 1 omm dbgrp 16777216 4月 17 16:00 00000001000000000000003C
drwx------ 2 omm dbgrp 4096 4月 17 16:02 archive_status
-rw------- 1 omm dbgrp 16777216 4月 17 16:25 00000001000000000000003D
[dave@www.cndba.cn pg_xlog]$
所以我们这里先清空全被恢复之后的pg_xlog，然后把原来旧库WAL 目录中，还没有来得及归档的3D复制过来。当然这里也可以直接复制到归档目录，也一样。
[dave@www.cndba.cn pg_xlog]$ pwd
/data/openGauss/install/data/cndba/pg_xlog
[dave@www.cndba.cn pg_xlog]$ ll
总用量 16384
-rw------- 1 omm dbgrp 16777216 4月 17 16:19 00000001000000000000003A
drwx------ 2 omm dbgrp 43 4月 17 16:19 archive_status
[dave@www.cndba.cn pg_xlog]$ rm -rf *
[dave@www.cndba.cn pg_xlog]$ cp /data/openGauss/install/data/dn/pg_xlog/00000001000000000000003D .
[dave@www.cndba.cn pg_xlog]$ ll
总用量 16384
-rw------- 1 omm dbgrp 16777216 4月 17 16:29 00000001000000000000003D
[dave@www.cndba.cn pg_xlog]$
3.6 启动数据库并验证
openGauss在启动的时候，会自动根据recovery.conf 来执行恢复操作。
[dave@www.cndba.cn pg_xlog]$ gs_ctl start -D /data/openGauss/install/data/cndba
[dave@www.cndba.cn pg_xlog]$ gsql -h localhost -p 15600 -d postgres -U omm -W omm@123456 -r
gsql ((openGauss 5.0.0 build a07d57c3) compiled at 2023-03-29 03:07:56 commit 0 last mr )
SSL connection (cipher: ECDHE-RSA-AES128-GCM-SHA256, bits: 128)
Type "help" for help.
#检查当前数据库是否处于恢复状态
openGauss=# select pg_is_in_recovery();
pg_is_in_recovery
-------------------
f
(1 row)
openGauss=# select * from cndba;
id | website
----+----------------------
1 | https://www.cndba.cn
(1 row)
此时最后一个没有归档的WAL 也完成了回复。
我们这里因为之前已经恢复结束了，recover 状态是f，如果是t，则还需要执行结束恢复命令，使机器对外提供读写服务：
openGauss=# select pg_xlog_replay_resume();
ERROR: recovery is not in progress
HINT: Recovery control functions can only be executed during recovery.
CONTEXT: referenced column: pg_xlog_replay_resume
openGauss=#
4 gs_probackup工具
gs_probackup用于对openGauss 实例进行定期备份。支持增量备份、定期备份和远程备份。增量备份时间相对于全量备份时间比较短，只需要备份修改的文件。
当前默认备份是数据目录，如果表空间不在数据目录，需要手动指定备份的表空间目录进行备份。当前只支持在主机上执行备份。
gs_probackup使用的前提条件：
- 可以正常连接openGauss数据库。
- 若要使用PTRACK增量备份，需在postgresql.conf中手动添加参数“enable_cbm_tracking = on”。
- 为了防止xlog在传输结束前被清理，请适当调高postgresql.conf文件中wal_keep_segments的值。
gs_probackup 最主要的是支持增量备份，同样也可以结合PITR 一起使用，具体步骤参考上节内容，这里不再重复演示。
工具的具体用法可以参考帮助：
[dave@www.cndba.cn backup]$ gs_probackup --help
4.1 启用enable_cbm_tracking
[dave@www.cndba.cn backup]$ gs_guc reload -D /data/openGauss/install/data/cndba -c "enable_cbm_tracking=on"
The gs_guc run with the following arguments: [gs_guc -D /data/openGauss/install/data/cndba -c enable_cbm_tracking=on reload ].
NOTICE: Turn on cbm tracking function.
expected instance path: [/data/openGauss/install/data/cndba/postgresql.conf]
gs_guc reload: enable_cbm_tracking=on: [/data/openGauss/install/data/cndba/postgresql.conf]
server signaled
Total instances: 1. Failed instances: 0.
Success to perform gs_guc!
[dave@www.cndba.cn pg_xlog]$ gsql -h localhost -p 15500 -d postgres -U omm -W omm@123456 -r
gsql ((openGauss 5.0.0 build a07d57c3) compiled at 2023-03-29 03:07:56 commit 0 last mr )
SSL connection (cipher: ECDHE-RSA-AES128-GCM-SHA256, bits: 128)
Type "help" for help.
openGauss=# show enable_cbm_tracking;
enable_cbm_tracking
---------------------
on
(1 row)
4.2 全备
4.2.1 初始化备份目录
[dave@www.cndba.cn probackup]$ gs_probackup init -B /data/backup/probackup
INFO: Backup catalog '/data/backup/probackup' successfully inited
[dave@www.cndba.cn probackup]$ ll
总用量 0
drwx------ 2 omm dbgrp 6 4月 17 17:40 backups
drwx------ 2 omm dbgrp 6 4月 17 17:40 wal
[dave@www.cndba.cn probackup]$
这里会生成2个目录：backups和wal。
4.2.2 添加备份实例
在备份路径backup-path内初始化一个新的备份实例，并生成pg_probackup.conf配置文件，该文件保存了指定数据目录pgdata-path的gs_probackup设置。
[dave@www.cndba.cn probackup]$ gs_probackup add-instance -B /data/backup/probackup -D /data/openGauss/install/data/cndba --instance=cndba
INFO: Instance 'cndba' successfully inited
[dave@www.cndba.cn probackup]$ ll
总用量 0
drwx------ 3 omm dbgrp 19 4月 17 18:52 backups
drwx------ 3 omm dbgrp 19 4月 17 18:52 wal
[dave@www.cndba.cn probackup]$ ll backups/cndba/
总用量 4
-rw------- 1 omm dbgrp 113 4月 17 18:52 pg_probackup.conf
[dave@www.cndba.cn probackup]$
4.2.3 将相关设置添加到pg_probackup.conf配置文件中
将指定的连接、压缩、日志等相关设置添加到pg_probackup.conf配置文件中，或修改已设置的值。不推荐手动编辑pg_probackup.conf配置文件。
[dave@www.cndba.cn probackup]$ gs_probackup set-config --instance=cndba -B /data/backup/probackup -d postgres -p 15500
[dave@www.cndba.cn probackup]$ gs_probackup show-config --instance=cndba -B /data/backup/probackup
# Backup instance information
pgdata = /data/openGauss/install/data/cndba
system-identifier = 576504339705580697
# Connection parameters
pgdatabase = postgres
pgport = 15500
# Archive parameters
archive-timeout = 5min
# Logging parameters
log-level-console = LOG
log-level-file = OFF
log-filename = pg_probackup.log
log-rotation-size = 0TB
log-rotation-age = 0d
# 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
# DSS connect parameters
enable-dss = false
instance-id = -1
[dave@www.cndba.cn probackup]$
4.2.4 创建测试表
openGauss=# create table cndba(id int,website varchar2(100));
CREATE TABLE
openGauss=# insert into cndba values(1,'https://www.cndba.cn');
INSERT 0 1
openGauss=# select * from cndba;
id | website
----+----------------------
1 | https://www.cndba.cn
(1 row)
openGauss=#
4.2.5 创建全备
[dave@www.cndba.cn ~]$ gs_probackup backup -B /data/backup/probackup --instance cndba -b full
INFO: Backup start, gs_probackup version: 2.4.2, instance: cndba, backup ID: RT9D03, backup mode: FULL, wal mode: STREAM, remote: false, compress-algorithm: none, compress-level: 1
LOG: Backup destination is initialized
LOG: This openGauss instance was initialized with data block checksums. Data block corruption will be detected
LOG: Database backup start
LOG: started streaming WAL at 0/3C000000 (timeline 1)
[2023-04-17 19:52:52]: check identify system success
[2023-04-17 19:52:52]: send START_REPLICATION 0/3C000000 success
[2023-04-17 19:52:52]: keepalive message is received
INFO: PGDATA size: 1097MB
[2023-04-17 19:52:52]: keepalive message is received
INFO: Start transferring data files
LOG: Creating page header map "/data/backup/probackup/backups/cndba/RT9D03/page_header_map"
[2023-04-17 19:52:57]: keepalive message is received
INFO: Data files are transferred, time elapsed: 6s
INFO: wait for pg_stop_backup()
INFO: pg_stop backup() successfully executed
LOG: stop_lsn: 0/3C000C08
LOG: Looking for LSN 0/3C000C08 in segment: 00000001000000000000003C
LOG: Found WAL segment: /data/backup/probackup/backups/cndba/RT9D03/database/pg_xlog/00000001000000000000003C
LOG: Thread [0]: Opening WAL segment "/data/backup/probackup/backups/cndba/RT9D03/database/pg_xlog/00000001000000000000003C"
LOG: Found LSN: 0/3C000C08
[2023-04-17 19:53:03]:(null): not renaming "/data/backup/probackup/backups/cndba/RT9D03/database/pg_xlog/00000001000000000000003D", segment is not complete.
LOG: finished streaming WAL at 0/3D000538 (timeline 1)
LOG: Getting the Recovery Time from WAL
LOG: Thread [0]: Opening WAL segment "/data/backup/probackup/backups/cndba/RT9D03/database/pg_xlog/00000001000000000000003C"
INFO: Syncing backup files to disk
INFO: Backup files are synced, time elapsed: 5s
INFO: Validating backup RT9D03
INFO: Backup RT9D03 data files are valid
INFO: Backup RT9D03 resident size: 1130MB
INFO: Backup RT9D03 completed
[dave@www.cndba.cn ~]$
说明：
- -b backup-mode, —backup-mode=backup-mode: 指定备份模式，支持FULL和PTRACK。
- FULL：创建全量备份，全量备份包含所有数据文件。
- PTRACK：创建PTRACK增量备份。
4.3 增备
4.3.1 创建新增数据
openGauss=# insert into cndba values(2,'https://www.cndba.cn');
INSERT 0 1
openGauss=# select * from cndba;
id | website
----+----------------------
1 | https://www.cndba.cn
2 | https://www.cndba.cn
(2 rows)
openGauss=#
4.3.2 执行增量备份
[dave@www.cndba.cn ~]$ gs_probackup backup -B /data/backup/probackup --instance cndba -b PTRACK
INFO: Backup start, gs_probackup version: 2.4.2, instance: cndba, backup ID: RT9D4M, backup mode: PTRACK, wal mode: STREAM, remote: false, compress-algorithm: none, compress-level: 1
LOG: Backup destination is initialized
LOG: This openGauss instance was initialized with data block checksums. Data block corruption will be detected
LOG: Database backup start
LOG: Latest valid FULL backup: RT9D03
INFO: Parent backup: RT9D03
LOG: started streaming WAL at 0/3E000000 (timeline 1)
[2023-04-17 19:55:34]: check identify system success
[2023-04-17 19:55:34]: send START_REPLICATION 0/3E000000 success
[2023-04-17 19:55:34]: keepalive message is received
INFO: PGDATA size: 1097MB
LOG: Current tli: 1
LOG: Parent start_lsn: 0/3C000028
LOG: start_lsn: 0/3E000028
INFO: Extracting pagemap of changed blocks
INFO: change bitmap start lsn location is 0/3C000028
[2023-04-17 19:55:34]: keepalive message is received
INFO: change bitmap end lsn location is 00000000/3E000028
INFO: Pagemap successfully extracted, time elapsed: 0 sec
INFO: Start transferring data files
LOG: Creating page header map "/data/backup/probackup/backups/cndba/RT9D4M/page_header_map"
INFO: Data files are transferred, time elapsed: 1s
INFO: wait for pg_stop_backup()
INFO: pg_stop backup() successfully executed
LOG: stop_lsn: 0/3E0006F8
LOG: Looking for LSN 0/3E0006F8 in segment: 00000001000000000000003E
LOG: Found WAL segment: /data/backup/probackup/backups/cndba/RT9D4M/database/pg_xlog/00000001000000000000003E
LOG: Thread [0]: Opening WAL segment "/data/backup/probackup/backups/cndba/RT9D4M/database/pg_xlog/00000001000000000000003E"
LOG: Found LSN: 0/3E0006F8
LOG: finished streaming WAL at 0/3F000000 (timeline 1)
LOG: Getting the Recovery Time from WAL
LOG: Thread [0]: Opening WAL segment "/data/backup/probackup/backups/cndba/RT9D4M/database/pg_xlog/00000001000000000000003E"
INFO: Syncing backup files to disk
INFO: Backup files are synced, time elapsed: 0
INFO: Validating backup RT9D4M
INFO: Backup RT9D4M data files are valid
INFO: Backup RT9D4M resident size: 277MB
INFO: Backup RT9D4M completed
[dave@www.cndba.cn ~]$
4.4 查看备份信息
[dave@www.cndba.cn ~]$ gs_probackup show -B /data/backup/probackup --instance cndba
=============================================================================================================================================
Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Type Status
=============================================================================================================================================
cndba 9.2 RT9D4M 2023-04-17 19:55:35+08 PTRACK STREAM 1/1 5s 261MB 16MB 1.00 0/3E000028 0/3E0006F8 FILE OK
cndba 9.2 RT9D03 2023-04-17 19:52:58+08 FULL STREAM 1/0 17s 1002MB 128MB 0.98 0/3C000028 0/3C000C08 FILE OK
[dave@www.cndba.cn ~]$
4.5 验证备份有消息
[dave@www.cndba.cn ~]$ gs_probackup validate -B /data/backup/probackup
INFO: Validate backups of the instance 'cndba'
INFO: Validating backup RT9D4M
INFO: Backup RT9D4M data files are valid
LOG: Thread [1]: Opening WAL segment "/data/backup/probackup/backups/cndba/RT9D4M/database/pg_xlog/00000001000000000000003E"
INFO: Backup RT9D4M WAL segments are valid
INFO: Validating backup RT9D03
INFO: Backup RT9D03 data files are valid
LOG: Thread [1]: Opening WAL segment "/data/backup/probackup/backups/cndba/RT9D03/database/pg_xlog/00000001000000000000003C"
INFO: Backup RT9D03 WAL segments are valid
INFO: All backups are valid
[dave@www.cndba.cn ~]$
4.6 恢复
4.6.1 恢复全量备份并验证
恢复之前需要先关闭数据库。
[dave@www.cndba.cn ~]$ gs_ctl stop -D /data/openGauss/install/data/cndba
[2023-04-17 20:45:55.220][340][][gs_ctl]: gs_ctl stopped ,datadir is /data/openGauss/install/data/cndba
waiting for server to shut down............................................. done
server stopped
[dave@www.cndba.cn ~]$
恢复全量备份：
注意这里-D，需要恢复的新的路径，如果是原路径，会报错：
[dave@www.cndba.cn ~]$ gs_probackup restore -B /data/backup/probackup --instance cndba -D /data/openGauss/install/data/cndba -i RT9D03
ERROR: Restore destination is not empty: "/data/openGauss/install/data/cndba"
[dave@www.cndba.cn ~]$ gs_probackup restore -B /data/backup/probackup --instance cndba -D /data/openGauss/install/data/newcndba -i RT9D03
LOG: Restore begin.
LOG: there is no file tablespace_map
LOG: check tablespace directories of backup RT9D03
LOG: check external directories of backup RT9D03
INFO: Validating backup RT9D03
INFO: Backup RT9D03 data files are valid
LOG: Thread [1]: Opening WAL segment "/data/backup/probackup/backups/cndba/RT9D03/database/pg_xlog/00000001000000000000003C"
INFO: Backup RT9D03 WAL segments are valid
INFO: Backup RT9D03 is valid.
INFO: Restoring the database from backup at 2023-04-17 19:52:51+08
LOG: there is no file tablespace_map
LOG: Restore directories and symlinks... in /data/openGauss/install/data/newcndba
INFO: Start restoring backup files. PGDATA size: 1225MB
LOG: Start thread 1
INFO: Backup files are restored. Transfered bytes: 1129MB, time elapsed: 2s
INFO: Restore incremental ratio (less is better): 92% (1129MB/1225MB)
INFO: Syncing restored files to disk
INFO: Restored backup files are synced, time elapsed: 8s
INFO: Restore of backup RT9D03 completed.
[dave@www.cndba.cn ~]$
启库查询数据：
[dave@www.cndba.cn ~]$ gs_ctl start -D /data/openGauss/install/data/newcndba
[dave@www.cndba.cn ~]$ gsql -h localhost -p 15500 -d postgres -U omm -W omm@123456 -r
gsql ((openGauss 5.0.0 build a07d57c3) compiled at 2023-03-29 03:07:56 commit 0 last mr )
SSL connection (cipher: ECDHE-RSA-AES128-GCM-SHA256, bits: 128)
Type "help" for help.
openGauss=# select * from cndba;
id | website
----+----------------------
1 | https://www.cndba.cn
(1 row)
openGauss=#
4.6.2 恢复增量备份并验证（可以直接恢复增量）
同样需要新关闭数据库：
[dave@www.cndba.cn ~]$ gs_ctl stop -D /data/openGauss/install/data/newcndba
[2023-04-17 20:54:31.663][2398][][gs_ctl]: gs_ctl stopped ,datadir is /data/openGauss/install/data/newcndba
waiting for server to shut down............................................... done
server stopped
[dave@www.cndba.cn ~]$
这里同样不要指定一个空的路径：
[dave@www.cndba.cn ~]$ gs_probackup restore -B /data/backup/probackup --instance cndba -D /data/openGauss/install/data/cndba -i RT9D4M
ERROR: Restore destination is not empty: "/data/openGauss/install/data/cndba"
[dave@www.cndba.cn ~]$
[dave@www.cndba.cn ~]$ gs_probackup restore -B /data/backup/probackup --instance cndba -D /data/openGauss/install/data/newcndba2 -i RT9D4M
LOG: Restore begin.
LOG: there is no file tablespace_map
LOG: check tablespace directories of backup RT9D4M
LOG: check external directories of backup RT9D4M
INFO: Validating parents for backup RT9D4M
INFO: Validating backup RT9D03
INFO: Backup RT9D03 data files are valid
INFO: Validating backup RT9D4M
INFO: Backup RT9D4M data files are valid
LOG: Thread [1]: Opening WAL segment "/data/backup/probackup/backups/cndba/RT9D4M/database/pg_xlog/00000001000000000000003E"
INFO: Backup RT9D4M WAL segments are valid
INFO: Backup RT9D4M is valid.
INFO: Restoring the database from backup at 2023-04-17 19:55:34+08
LOG: there is no file tablespace_map
LOG: Restore directories and symlinks... in /data/openGauss/install/data/newcndba2
INFO: Start restoring backup files. PGDATA size: 1113MB
LOG: Start thread 1
INFO: Backup files are restored. Transfered bytes: 1113MB, time elapsed: 1s
INFO: Restore incremental ratio (less is better): 100% (1113MB/1113MB)
INFO: Syncing restored files to disk
INFO: Restored backup files are synced, time elapsed: 14s
INFO: Restore of backup RT9D4M completed.
[dave@www.cndba.cn ~]$
同操作日志，可以看出，增量备份恢复时，是先进行全备的恢复，然后追加的增量。所以这里我们完全可以直接恢复增量备份即可。
启库验证：
[dave@www.cndba.cn ~]$ gs_ctl start -D /data/openGauss/install/data/newcndba2
[dave@www.cndba.cn ~]$ gsql -h localhost -p 15500 -d postgres -U omm -W omm@123456 -r
gsql ((openGauss 5.0.0 build a07d57c3) compiled at 2023-03-29 03:07:56 commit 0 last mr )
SSL connection (cipher: ECDHE-RSA-AES128-GCM-SHA256, bits: 128)
Type "help" for help.
openGauss=# select * from cndba;
id | website
----+----------------------
1 | https://www.cndba.cn
2 | https://www.cndba.cn
(2 rows)
openGauss=#
4.7 合并全备和增量备份
[dave@www.cndba.cn ~]$ gs_probackup show -B /data/backup/probackup
BACKUP INSTANCE 'cndba'
=============================================================================================================================================
Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Type Status
=============================================================================================================================================
cndba 9.2 RT9D4M 2023-04-17 19:55:35+08 PTRACK STREAM 1/1 5s 261MB 16MB 1.00 0/3E000028 0/3E0006F8 FILE OK
cndba 9.2 RT9D03 2023-04-17 19:52:58+08 FULL STREAM 1/0 17s 1002MB 128MB 0.98 0/3C000028 0/3C000C08 FILE OK
[dave@www.cndba.cn ~]$
我们可以看到前面生成的2个备份，可以使用merge选项将指定的增量备份与其父完全备份之间的所有增量备份合并到父完全备份。父完全备份将接收所有合并的数据，而已合并的增量备份将作为冗余被删除。
指定最后一个增量备份的id，自动将其与全备之间的增量备份进行合并:
[dave@www.cndba.cn ~]$ gs_probackup merge -B /data/backup/probackup --instance cndba -i RT9D4M
INFO: Merge started
INFO: Merging backup RT9D4M with parent chain
INFO: Validate parent chain for backup RT9D4M
INFO: Validating backup RT9D03
INFO: Backup RT9D03 data files are valid
INFO: Validating backup RT9D4M
INFO: Backup RT9D4M data files are valid
LOG: Restore directories and symlinks... in /data/backup/probackup/backups/cndba/RT9D03/database
INFO: Start merging backup files
LOG: Creating page header map "/data/backup/probackup/backups/cndba/RT9D03/page_header_map_tmp"
INFO: Backup files are successfully merged, time elapsed: 15s
INFO: Delete: RT9D4M 2023-04-17 19:55:35+08
LOG: Rename /data/backup/probackup/backups/cndba/RT9D03 to /data/backup/probackup/backups/cndba/RT9D4M
INFO: Rename merged full backup RT9D03 to RT9D4M
INFO: Validating backup RT9D4M
INFO: Backup RT9D4M data files are valid
INFO: Merge of backup RT9D4M completed
[dave@www.cndba.cn ~]$ gs_probackup show -B /data/backup/probackup
BACKUP INSTANCE 'cndba'
===========================================================================================================================================
Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Type Status
===========================================================================================================================================
cndba 9.2 RT9D4M 2023-04-17 19:55:35+08 FULL STREAM 1/0 15s 1710MB 240MB 1.00 0/3E000028 0/3E0006F8 FILE OK
[dave@www.cndba.cn ~]$
版权声明：本文为博主原创文章，未经博主允许不得转载。
