首批通过分布式安全可靠测评，为关键业务系统打造
备份恢复概述
更新时间：2026-04-14 15:16:08
编辑
分享
本节为您介绍 OCP 为 OceanBase 提供的备份恢复功能和二次备份功能。
备份恢复
备份恢复是 OceanBase 数据库高可用特性的核心组件，主要用于保障数据的安全，包括预防存储介质损坏和用户的错误操作等导致的数据丢失。如果存储介质损坏或者用户误操作而导致了数据丢失，可以通过恢复功能恢复用户数据。
目前 OceanBase 数据库支持 OSS 和 NFS 两种备份介质，提供了备份、恢复、管理三大功能。
物理备份由基线数据、日志归档数据两种数据组成，因此物理备份由日志归档和数据备份两个功能组合而成：
日志归档是指日志数据的自动归档功能，OBServer 节点会定期将日志数据归档到指定的备份路径。这个动作是全自动的，不需要外部定期触发。
数据备份指的是备份基线数据的功能，该功能分为全量备份和增量备份两种：
全量备份是指备份所有的需要基线的宏块。
增量备份是指备份上一次备份以后新增和修改过的宏块。
OceanBase 数据库支持租户级别的恢复，恢复是基于已有数据的备份重建新租户的过程。恢复过程包括租户系统表和用户表的 Restore 和 Recover 过程。Restore 是将恢复需要的基线数据恢复到目标租户的 OBServer 节点，Recover 是将基线对应的日志恢复到对应 OBServer 节点并回放。
物理备份架构
OceanBase 数据库物理备份的架构如下图所示。
当用户用系统租户登录到待备份的集群以后，需要先用 SQL 发起日志归档，等日志归档发起完成启动阶段以后，才可以发起基线备份。
日志归档是定期备份到备份目的端的，只需要用户发起一次 alter system archivelog，日志备份就会在后台持续进行。日志归档是由每个 PG（PartitionGroup）的 leader 负责定期将该 PG 的日志归档到备份介质指定的路径，RS（RootService）负责定期统计日志归档的进度，并更新到内部表。
数据备份是需要用户触发的，比较常见的场景是周六触发一次全量备份，周二周四触发一次增量备份。当用户发起数据备份请求时，该请求会首先被转发到 RS 所在的节点上；RS 会根据当前的租户和租户包含的 PG 生成备份数据的任务，然后把备份任务分发到 OBServer 节点上并行地执行备份任务；OBServer 节点负责备份 PG 的元信息和宏块到指定的备份目录，宏块是按照 PG 为单位管理的。
OceanBase 数据库目前支持使用 OSS 和 NFS 两种文件系统作为备份的目的地。以下两个图是备份功能在备份目的地创建的目录结构以及每个目录下保存的文件类型，其中图一适用于 4.x 版本的 OceanBase 集群，图二适用于 3.x 版本的 OceanBase 集群。
backup/ # 备份的根目录
└── ob1 # cluster_name
└── 1 # cluster_id
└── tenant_incarnation_1 #分身id（适用于 4.x 版本的 OceanBase 集群）
├── 1001 # 租户id
│ ├── clog # clog的根目录
│ │ ├── 1 # clog备份的round id
│ │ │ ├── data # 日志的数据目录
│ │ │ └── index # 日志的索引目录
│ │ └── tenant_clog_backup_info # 日志备份的元信息，按照round id分段记录
│ └── data # 数据的根目录
│ ├── backup_set_1 # 全量备份的目录
│ │ ├── backup_1 # 差异备份的目录，第一个差异备份目录是全量的meta
│ │ ├── backup_2 # 差异备份的目录。第二个差异备份的目录，meta也是全量备份的。
│ │ ├── backup_set_info # 记录了backup_set目录内的多次差异备份的信息
│ │ └── data #宏块数据的目录，包含了所有的全量和差异的宏块
│ └── tenant_data_backup_info # 记录了租户全部的数据备份信息
├── clog_info # server启动日志备份的信息
│ └── 1_xxx.xxx.xxx.xxx_12533 # 一个server一个启动日志备份信息
├── cluster_clog_backup_info # 集群级别的日志备份信息
├── cluster_data_backup_info # 集群级别的数据备份信息
├── tenant_info # 租户的信息
└── tenant_name_info #租户name和id的影射关系
backup/ # 备份的根目录
└── ob1 # cluster_name
└── 1 # cluster_id
└── incarnation_1 #分身id（适用于 3.x 版本的 OceanBase 集群）
├── 1001 # 租户id
│ ├── clog # clog的根目录
│ │ ├── 1 # clog备份的round id
│ │ │ ├── data # 日志的数据目录
│ │ │ └── index # 日志的索引目录
│ │ └── tenant_clog_backup_info # 日志备份的元信息，按照round id分段记录
│ └── data # 数据的根目录
│ ├── backup_set_1 # 全量备份的目录
│ │ ├── backup_1 # 差异备份的目录，第一个差异备份目录是全量的meta
│ │ ├── backup_2 # 差异备份的目录。第二个差异备份的目录，meta也是全量备份的。
│ │ ├── backup_set_info # 记录了backup_set目录内的多次差异备份的信息
│ │ └── data #宏块数据的目录，包含了所有的全量和差异的宏块
│ └── tenant_data_backup_info # 记录了租户全部的数据备份信息
├── clog_info # server启动日志备份的信息
│ └── 1_xxx.xxx.xxx.xxx_12533 # 一个server一个启动日志备份信息
├── cluster_clog_backup_info # 集群级别的日志备份信息
├── cluster_data_backup_info # 集群级别的数据备份信息
├── tenant_info # 租户的信息
└── tenant_name_info #租户name和id的影射关系
物理恢复架构
OceanBase 数据库的物理恢复架构如下图所示。
对于用户可见的流程主要有两步：
在目的集群上用
CREATE RESOURCE POOL命令建立恢复租户需要的 resource pool。通过
ALTER SYSTEM RESTORE TENANT命令调度租户恢复任务。
对于备份恢复来说，restore tenant 命令内部的流程如下：
创建恢复用的租户
恢复租户的系统表数据
恢复租户的系统表日志
调整恢复租户的元信息
恢复租户的用户表数据
恢复租户的用户表日志
恢复扫尾工作
对于单个 PG 来说，恢复的流程是先将 PG 的元信息和宏块数据拷贝到指定的 OBServer 节点，构建出一个只有基线数据的 PG，此时只恢复到了数据备份的时间点；然后再把 PG 的日志拷贝到指定的 OBServer 节点，回放到该 PG 的 MemTable 中，此时则恢复到了灾难时刻或用户想恢复到的时刻。这个流程中如果日志的量比较大，可能会触发转储操作。
二次备份
说明
OceanBase 4.x 版本不支持二次备份。
若称 OceanBase 集群备份恢复中的备份为常规备份，那么二次备份则是在 OceanBase 集群成功进行了常规备份的基础上，对 OceanBase 集群常规备份的全量备份数据进行再次备份，并归档到不同于常规备份存储地址的位置，全量备份数据包括基线数据和日志归档数据。
二次备份的目的是降低常规备份的存储压力。将常规备份存储服务器上的备份数据定期归档到二次备份存储目录后，缩短常规备份的备份文件保留天数，这样即可释放部分常规备份的存储空间。
同时，二次备份也保证了 OceanBase 集群的可恢复性。当常规备份的存储服务器异常导致备份文件不可获取时，二次备份依旧可以保障 OceanBase 集群的可恢复性。
