830版本发布后对备份这块做了很多增强，主要新增功能如下：
1.支持了pitr，总体步骤和pg类似
2.支持备机备份
3.支持远程基础备份
4.pg_receivexlog支持
5.解决主备环境下只剩下主机做basebackup阻塞业务的问题
目前还存在的问题：
1.基础备份不包含xlog内容
2.如果归档命令中使用test ! -f会造成归档失败
下面具体看看这些功能
pitr
修改归档模式
postgres=# alter system set archive_mode=on;
ALTER SYSTEM SET
postgres=# alter system set archive_command='cp %p /mnt/disk1/gaussarch/%f';
ALTER SYSTEM SET重启数据库，做基础备份：
[omm@db01 ~]$ gs_basebackup -D /tmp/backup/ -Ft -p 5532 --checkpoint=fast
INFO: The starting position of the xlog copy of the full build is: 20/41000688. The slot minimum LSN is: 20/41000688.
begin build tablespace list
finish build tablespace list
NOTICE: pg_stop_backup complete, all required WAL segments have been archived建表，查看时间戳
postgres=# create table test(id int);
CREATE TABLE
postgres=# \d
List of relations
Schema | Name | Type | Owner | Storage
--------+------+-------+-------+----------------------------------
public | test | table | omm | {orientation=row,compression=no}
(1 row)
postgres=# select current_timestamp;
pg_systimestamp
-------------------------------
2020-09-15 10:40:52.941916+08
(1 row)停止数据库，删除数据目录
[omm@db01 gaussdata]$ rm -rf *解压基础备份包，注意使用gs_tar命令解压
[omm@db01 gaussdata]$ gs_tar -D . -F /tmp/backup/base.tar
[omm@db01 gaussdata]$ vi recovery.conf
standby_mode = 'on'
restore_command='cp /mnt/disk1/gaussarch/%f %p'
recovery_target_time='2020-09-15 10:40:52.941916+08'启动数据库
[omm@db01 gaussdata]$ gs_ctl start检查发现该表已恢复
[omm@db01 gaussdata]$ gsql postgres -p 5532 -r
gsql ((openGauss 1.0.0 build ) compiled at 2020-09-01 10:14:40 commit 0 last mr )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.
postgres=# \d
List of relations
Schema | Name | Type | Owner | Storage
--------+------+-------+-------+----------------------------------
public | test | table | omm | {orientation=row,compression=no}
(1 row)备机备份
在630版本在备库备份后报如下错误：
[opengauss@olddb02 ~]$ gs_basebackup -D /tmp/basebackup/ -p 5432
INFO: Try to bind walsender thread to available CPUs in threadpool.
gs_basebackup: could not initiate base backup: FATAL: WAL generated with full_page_writes=off was replayed since last restartpoint
HINT: This means that the backup being taken on the standby is corrupt and should not be used. Enable full_page_writes and run CHECKPOINT on the master, and then try an online backup again.会报出备机不支持备份，同时让你检查full_page_writes是否开启（full_page_writes是开启的）
这个缺陷在830版本已经修复：
[omm@db02 ~]$ gs_ctl query |grep local_role
local_role : Standby
local_role : Standby做基础备份，可以看到可以备份成功
[omm@db02 ~]$ gs_basebackup -D /tmp/backup/ -p 5532 -Ft --checkpoint=fast
INFO: The starting position of the xlog copy of the full build is: 21/1E000028. The slot minimum LSN is: 0/0.
begin build tablespace list
finish build tablespace list
[omm@db02 ~]$ ll /tmp/backup/
total 2133044
-rw------- 1 omm dbgrp 2184232960 Sep 15 11:00 base.tar远程备份
在备机备份使用gs_basebackup备份远程主机数据，可以看到能够正常备份
[omm@db02 ~]$ gs_basebackup -h 192.168.1.1 -p 5532 -D /tmp/backup/ -Ft --checkpoint=fast
INFO: The starting position of the xlog copy of the full build is: 21/1E000028. The slot minimum LSN is: 21/1F000000.
begin build tablespace list
finish build tablespace list
[omm@db02 ~]$ ll /tmp/backup/
total 2133036
-rw------- 1 omm dbgrp 2184221696 Sep 15 11:03 base.tarpg_receivexlog
这个其实是很有用的一个功能，但是用的人不多，这个工具可以远程的实时将xlog文件以流的方式拷贝到本端，因为pg中的xlog十分重要，所以xlog除了归档之外最好有其他方式能够进行备份。而pg_receivexlog就是用来做这个事情的。
默认装完opengauss后bin目录下会有pg_receivexlog的二进制文件，这里演示在备机上实时拷贝主机xlog文件。
[omm@db02 ~]$ mkdir pg_receivexlog
[omm@db02 ~]$ pg_receivexlog -h 192.168.1.1 -p 5532 -D pg_receivexlog/ > pg_receivexlog.log 2>&1 &
[1] 50870主库做一个日志切换：
postgres=# select pg_switch_xlog();
pg_switch_xlog
----------------
21/200002A0
(1 row)备库查看日志已经同步过来了，可以看到有一个partial的文件，说明这个文件是源端最后那个文件，还没写满，还在实时拷贝。
[omm@db02 ~]$ ll pg_receivexlog
total 32768
-rw------- 1 omm dbgrp 16777216 Sep 15 11:17 000000010000002100000020
-rw------- 1 omm dbgrp 16777216 Sep 15 11:17 000000010000002100000021.partial