本文对比了OceanBase、TiDB、OpenGauss、GaussDB和GoldenDB等国产数据库的备份恢复功能，涵盖了备份方式、工具、恢复机制等方面。
原文标题：国产数据库备份恢复实现
原文作者：牧羊人的方向
冷月清谈：
OceanBase 数据库支持租户级和表级物理备份恢复，备份目标包括 OSS、NFS、COS 等。其日志归档功能支持 Log Entry 级别的物理备份，数据备份优先选择 Follower 副本进行，以减少对主库的影响。恢复方面，支持租户级恢复和 4.2.1 版本后的表级恢复。
TiDB 数据库支持快照备份和日志备份，可通过 BR 工具实现任意时间点的恢复（PITR）。快照备份包含某个时间点满足事务一致性的所有数据，日志备份记录 TiKV 中的 kv 变更数据。BR 工具调度备份恢复任务，并与 TiKV、PD 协同完成数据备份与恢复。需要注意的是，备份过程会对集群性能有一定影响，可以通过参数进行调控。
OpenGauss 数据库支持逻辑备份和物理备份。逻辑备份使用 gs_dump 工具，将数据导出为 SQL 脚本或归档文件。物理备份包括 gs_backup、gs_basebackup 等工具，分别适用于不同场景。PITR 恢复支持恢复到备份归档后的任意时间点，但仅限主节点。gs_probackup 工具可用于管理备份恢复任务。
GaussDB 数据库提供基于 OBS/NAS 的集群级/库表级物理备份恢复能力，支持全量和增量备份。其 Roach 工具可用于备份恢复集群、单表等，并支持多种存储介质。采用分布式并行技术，具有很高的备份恢复性能。
GoldenDB 分布式数据库备份包括 data 数据备份、binlog 日志备份、活跃 GTID 备份、元数据备份和 Sequence 备份。支持全量和增量备份，数据备份以库为单位。备份恢复过程会对磁盘 IO 产生影响，并在备份过程中会有短暂的 flush table with read lock 锁。
怜星夜思：
2、对于数据量很大的数据库，例如超过 10TB，应该如何选择合适的备份恢复策略？
3、未来数据库备份恢复技术的发展趋势是什么？
原文内容
数据库备份恢复是数据库高可用的基本能力，如何通过备份数据快速高效的恢复业务并且满足不同场景下的恢复需求，是各数据库厂商需要关注的要点。本文将介绍几种国产数据库的备份恢复功能，以加深了解。
1、数据库备份恢复方案
-
数据库工具完成备份到本地或NAS文件，再由集中备份设备进行统一备份管理；
-
数据库备份工具备份数据到远端或云端的存储设备，如COS或OBS，再由集中备份设备进行统一备份管理；
-
第三方工具代理直接备份数据库到集中备份设备进行管理。
在以上备份方案中，首先要满足备份恢复带宽需求，本地或云端的存储设备能否满足备份及恢复的时效性要求；其次是备份过程的影响，对主库及业务影响、是否支持备库。还有数据恢复的一致性要求，是否支持PITR一致点的恢复，这个是每一种数据库产品自身的能力。最后就是备份恢复任务的管理和监控，备份成功失败、备份超时、备份任务取消等能够通过统一的管理平台进行操作。本文将介绍几种国产数据库的备份恢复功能，以加深了解。
2、国产数据库备份恢复功能
-
数据备份包括租户相关的信息以及全部用户表数据，也就是备份时刻的Major SSTable+Minor SSTable，分为全量备份和增量备份。
-
日志归档是OBServer节点会定期将日志数据归档到指定的备份路径，也就是事务层生成的Clog，包含了SSTable之后修改的数据。
OceanBase数据库支持的备份介质包括OSS、NFS、COS、AWS S3以及兼容S3协议的对象存储（如华为OBS）等备份介质。
OceanBase数据库支持租户级别和表级别的恢复：租户级恢复是基于已有数据的备份重建新租户的过程；表级恢复是从备份数据中将用户指定的表恢复到一个已存在的租户，该功能在V4.2.1版本后才支持。
日志归档的工作由日志流的Leader副本负责。按照日志流备份日志，是Log Entry级别的物理备份，默认备份周期是2分钟。每一条归档日志实际上是一个日志集合，包含若干条Log Entry，该条归档日志称之为Log Group。每个Log Entry 都有一个SCN与之关联，Log Group也有一个 SCN，是所有Log Entry中最大的SCN。
1）开启和关闭日志归档
#开启指定租户的归档模式
ALTER SYSTEM ARCHIVELOG TENANT = mysql_tenant;
#关闭集群中指定租户的归档模式
ALTER SYSTEM NOARCHIVELOG TENANT = mysql_tenant;
2）查看归档信息
#查看当前租户归档相关的参数
SELECT * FROM oceanbase.DBA_OB_ARCHIVE_DEST;
1）配置租户备份目标端
#为指定租户配置备份目的端
ALTER SYSTEM SET DATA_BACKUP_DEST= 'data_backup_path' TENANT = mysql_tenant;
2）发起全量备份
#设置备份的并发度
ALTER SYSTEM SET ha_low_thread_score = 10;
#指定租户发起全量数据备份
ALTER SYSTEM BACKUP TENANT = mysql_tenant [PLUS ARCHIVELOG];
-
RS根据备份的数据创建需要的日志流。
-
日志流的Leader调度自己恢复数据和日志，Follower从Leader拉取数据和日志。
-
RS检测到所有的日志流恢复完成以后，认为租户数据恢复完成。
OceanBase数据库的恢复支持在同集群内恢复，也支持在不同的集群内恢复。
1）租户恢复
#恢复到指定时间戳
ALTER SYSTEM RESTORE dest_tenant_name FROM uri UNTIL TIME='timestamp' WITH 'restore_option' [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] [DESCRIPTION description];
#恢复到指定SCN
ALTER SYSTEM RESTORE dest_tenant_name FROM uri UNTIL SCN=scn WITH 'restore_option' [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] [DESCRIPTION description];
#恢复到最新位点
ALTER SYSTEM RESTORE dest_tenant_name FROM uri WITH 'restore_option' [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] [DESCRIPTION description];
恢复任务完成后，如果是从低版本的备份数据恢复到高版本集群中的场景，还需要对恢复出来的租户进行升级。如果物理恢复后的租户为备租户，后续该租户可作为备租户提供相关服务，也可转为主租户提供服务。
2）表级别恢复
OceanBase数据库的表级恢复功能是通过从备份数据中将用户指定的表恢复到一个已存在的租户中来实现的，并且该已存在的租户与原表所在的租户可以是同一个租户，也可以是同一集群中的不同租户，还可以是不同集群中的租户。表恢复过程中需要使用辅助租户：首先在辅助租户中将数据恢复到指定时间点；再将指定的表从辅助租户跨租户导入到目标租户中；最后清理辅助租户。
ALTER SYSTEM
RECOVER TABLE infodb.tbl1,infodb.tbl2
TO TENANT oracle001
FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive'
UNTIL TIME='2023-09-30 00:00:00'
WITH 'pool_list=restore_pool'
REMAP TABLE infodb.tbl1:newtbl
REMAP TABLEGROUP tg1:newtg1
REMAP TABLESPACE ts1:newts1;
表级别恢复仅支持恢复用户表。另外恢复表时，指定的表名需要与系统实际存储的表名一致。
TiDB数据库支持对集群某个时间点全量数据的备份，也就是快照数据，包含某个物理时间点上集群满足事务一致性的所有数据。同时为了满足PITR的任意时间点的恢复需求，需要开启日志备份，也就是TiKV中的kv变更数据的记录。基于集群的快照数据备份和日志备份数据，可以恢复到集群的任意时间点PITR。
-
备份流程
-
BR接收备份命令 br backup full。
-
BR调度备份数据：创建备份请求，发送给 TiKV 节点，备份请求包含 backup ts、需要备份的 region、备份存储地址
-
TiKV接受备份请求，初始化backup worker。
-
TiKV备份数据，从Region (only leader)读取backup ts对应的数据，并上传SST文件到备份存储中
-
BR从各个TiKV获取备份结果。
-
BR备份元信息，并上传到备份存储。
-
恢复流程
-
BR接收恢复命令br restore，获得快照备份数据存储地址、要恢复的database或table
-
BR调度恢复数据，根据PD分配的Region结果，发送恢复请求到对应的TiKV节点，恢复请求包含要恢复的备份数据及rewrite规则。
-
TiKV接受恢复请求，初始化restore worker。
-
TiKV恢复数据，restore worker将处理好的SST文件ingest到RocksDB中
-
Report restore result：restore worker 返回恢复结果给BR。
-
BR从各个TiKV获取恢复结果，全部备份都恢复成功后，则整个恢复任务成功。
-
备份流程
-
BR接收备份命令br log start，解析获取日志备份任务的checkpoint ts（日志备份起始位置）、备份存储地址。
-
TiKV监控日志备份任务的创建与更新。
-
TiKV log backup observer持续地备份KV变更日志，读取kv数据变更，然后保存到自定义格式的备份文件中，并定期将日志备份数据和local metadata上传到备份存储中。
-
TiDB Coordinator监控日志备份进度，根据各个Region checkpoint ts，计算整个日志备份任务的进度(global checkpoint ts)，然后上报给PD。
-
PD持久化日志备份任务状态。可以通过br log status查询。
-
PITR恢复流程
-
BR接收恢复命令br restore point，解析获取全量备份数据地址、日志备份数据地址、恢复到的时间点。
-
BR恢复全量备份，进行快照备份数据恢复。
-
BR恢复日志备份，读取日志备份数据，创建日志恢复请求，发送到对应的TiKV，日志恢复请求包含要恢复的日志备份数据信息。
-
TiKV接受BR的恢复请求，初始化log restore worker。
-
TiKV恢复日志备份数据，log restore worker根据恢复集群表的table ID对备份数据的kv进行重写，并将处理好的kv通过raft接口写入store (RocksDB)中。
-
BR从各个TiKV获取恢复结果，全部备份数据都恢复成功后，则恢复任务成功。
TiDB支持将备份数据写到Amazon S3和NFS等存储设备。使用BR命令完成备份恢复功能。
1）对集群进行快照备份
tiup br backup full --pd "${PD_IP}:2379" \
--backupts '2022-09-08 13:30:00 +08:00' \
--storage "" \
--ratelimit 128 \
2）恢复快照备份数据
tiup br restore full --pd "${PD_IP}:2379" \
--storage ""
3）恢复指定库表的数据
tiup br restore table --pd "${PD_IP}:2379" \
--db "test" \
--table "usertable" \
--storage ""
4）开启日志备份
tiup br log start --task-name=pitr --pd "${PD_IP}:2379" \
--storage ''
5）进行PITR恢复
tiup br restore point --pd "${PD_IP}:2379" \
--storage='' \
--full-backup-storage='' \
--restored-ts '2022-05-15 18:00:00+0800'
补充说明：TiDB的备份对集群的性能有一定的影响，如影响IO、事务时延以及QPS。可以通过--ratelimit 参数对备份任务进行限速、配置项 backup.num-threads限制备份任务使用的工作线程数量。
OpenGauss数据库支持逻辑备份和物理备份的方式：逻辑备份是将表的数据转储到文件，适用于数据量较小或者数据迁移、表变更等场景；物理备份通过物理文件拷贝的方式，以磁盘块为基本单位进行备份，一般用于全量备份恢复场景。
-
纯文本格式的SQL脚本文件：包含将数据库恢复为其保存时的状态所需的SQL语句。通过gsql运行该SQL脚本文件，可以恢复数据库。
-
归档格式文件：包含将数据库恢复为其保存时的状态所需的数据，可以是tar格式、目录归档格式或自定义归档格式，该导出结果必须与gs_restore配合使用来恢复数据库。
另外通过gs_dumpall可以导出所有数据库相关信息，包括数据库元数据、表空间等信息以及各数据库的SQL脚本文件。为了保证数据一致性和完整性，gs_dumpall会对需要转储的表设置共享锁，如果无法在指定时间内锁定某张表，备份会失败。
openGauss物理备份有gs_backup、gs_basebackup等工具：gs_backup是导出数据库参数文件及二进制文件，适合数据量小的备份恢复场景；gs_basebackup而是对数据库二进制文件进行全量拷贝，结合PITR恢复场景可恢复全量备份到某一时间点。
1）gs_backup备份
#备份数据库主机
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]
2）gs_basebackup
gs_basebackup对服务器数据库文件的二进制进行拷贝，其实现原理使用了复制协议。gs_basebackup仅支持主机和备机的全量备份，不支持增量备份。
3）PITR恢复
openGauss的PITR恢复支持恢复到备份归档后的任意时间点。目前只有主节点可以进行PITR恢复，备机需要全量build达成主机一致。在PITR的恢复流程中，需要将归档的WAL日志文件复制到pg_xlog文件中，通过备份数据追加日志的方式恢复到指定时间点。
4）gs_probackup
gs_probackup用于管理openGauss的备份恢复工具，可以对实例进行定期恢复，支持全量、增量和远程备份。
#初始化备份目录
gs_probackup init -B backup_dir
#添加一个新的备份实例
gs_probackup add-instance -B backup_dir -D data_dir --instance instance_name
#创建指定实例的备份
gs_probackup backup -B backup_dir --instance instance_name -b backup_mode
#从指定实例的备份中恢复数据
gs_probackup restore -B backup_dir --instance instance_name -D pgdata-path -i backup_id
GaussDB提供基于OBS/NAS存储介质的集群级/库表级物理备份能力，并在同构数据库（分片个数相同、大版本号相同）中提供集群级/库表级恢复能力。支持全量备份和增量备份。采用分布式并行技术，并行地对每个数据实例的数据文件进行物理备份恢复，提供了极高的备份恢复性能。在此基础上，还提供备份数据压缩、备份流控、断点续传等高阶功能。
全量备份图所示，会备份全量的数据文件以及截止到barrier lsn的增量日志。在做PITR恢复的时候，基于全量和增量备份集以及归档日志，将实例恢复到任意时间点。
1） Roach备份恢复工具
GaussRoach.py工具是GaussDB提供的用于备份和恢复的实用工具，可对整个数据库中的数据、WAL归档日志和运行日志进行备份。该工具不仅可以备份恢复集群，也可以备份恢复单表；不仅可以备份到物理磁盘，也可以备份到OBS和NAS；不仅可以从集群级备份中恢复集群，也可以从集群级备份中恢复数据库/表。
#备份集群到NAS
python3 GaussRoach.py -t backup --master-port 6000 --media-destination /home/userA/media --media-type NAS --metadata-destination /home/userA/metadata --cluster-unique-id gaussdb_backup
#备份表到NAS
python3 GaussRoach.py -t backup --master-port 6000 --media-destination /home/userA/media --media-type NAS --metadata-destination /home/omm/metadata --cluster-unique-id gaussdb_backup --gbr-table-list /data/table.json
#从NAS恢复集群
python3 GaussRoach.py -t restore --clean --master-port 6000 --media-destination /home/userA/media --media-type NAS --backup-key 20160121_190548 --metadata-destination /home/userA/metadata --cluster-unique-id gaussdb_backup
#从NAS恢复单表
python3 GaussRoach.py -t restore --clean --master-port 6000 --media-destination /home/userA/media --media-type NAS --backup-key 20160121_190548 --metadata-destination /home/userA/metadata --cluster-unique-id gaussdb_backup --restore-new-cluster --gbr-table-list /data/table.json --aux-db-path /data/aux_db --origin-cluster --gbr-owner 'user1' -U user
-
Data数据文件备份：使用xtrabackup开启备份，将所有备份文件备份在“$DNip_FULL_$back_start_time.xbstream”文件内；
-
Binlog备份：将DN节点的binlog备份到指定的目录，用于数据一致性恢复；
-
活跃事务GTID备份：将集群的GTID列表备份到指定目录，保证全局节点的数据一致性；
-
集群元数据：备份集群相关的元数据，主要包括有数据字典，用户密码，索引信息；
-
Sequence信息：备份集群相关的Sequence数据，主要包括有自增列所在表的库名，表名，起始值，步长，最小值，最大值，当前值等属性
1）Data数据备份流程
-
insight页面创建定时备份任务到backup_restore库，向CM发送dbtool消息
-
当CM定时器触发时，CM向各节点DBAgent发起备份请求
-
DBAgent接收到备份请求后，将备份文件保存到指定备份目录
-
DBAgent备份完成后，将备份完成结果反馈给CM
-
CM接收到各节点DBAgent的备份结果，汇总后给MDS
-
MDS接收到备份结果，将消息备份结果发向OMM， OMM入库
-
获取恢复所需要的文件。
-
通过全量备份文件（及增量文件）恢复DN。
-
应用binlog 文件。
-
回滚恢复时刻的活跃事务。
3）备份恢复影响
GoldenDB数据库支持在备节点备份，备份和恢复过程会对本地磁盘IO有影响，另外在备份过程中会有短暂的flush table with read lock锁。
而整个数据库备份恢复的时效性则依赖于数据量、备份存储设备的性能及带宽情况，能否支持高并发高吞吐的能力。尤其是在集中式数据库中，单个库的容量已经超过10T，如何能确保故障时候通过备份数据快速的恢复业务。
参考资料：
-
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000818529
-
https://docs.pingcap.com/zh/tidb/stable/br-snapshot-guide
-
https://docs-opengauss.osinfra.cn/zh/docs/5.0.0/docs/DatabaseOMGuide/
-
https://doc.hcs.huawei.com/db/zh-cn/gaussdb/24.1.30/usermanual/gaussdb_01_247.html
-
https://www.goldendb.com/#/docsIndex/docs/BackupRecovery_BasicPrinciples