OceanBase物理备份恢复：多副本之外的数据保护机制

OceanBase 物理备份恢复：为什么需要它

OceanBase 已经有多副本同步机制，为何还要做备份？

场景一：用户执行了误操作。这条破坏性指令会以合法事务的形式迅速同步到所有副本上。此时只有备份、回收站或闪回能救回数据。

场景二：发生了超出容灾级别的极端灾难，造成多数派故障。这种情形同样只能靠备份恢复来处理。

多副本与备份恢复的关注点差异

多副本（实时强一致性）：盯的是当前时刻数据的可用性和实时一致性。所有副本存的都是当前状态，数据一旦被改写或覆盖，旧状态很快会被转储或合并冲掉。

备份恢复（历史时间线）：盯的是历史时刻数据的可追溯性。靠“基线数据备份 + 日志归档（Clog）”实现指定时间点恢复。比如发现某场景的数据在 3 天前下午 2 点被非法改动，也能把数据还原到那个时间点之前。

1. 物理备份与逻辑备份

1.1 物理备份 (Physical Backup)

概念：直接复制数据库的物理文件，包括数据文件和日志文件。

组成：

数据备份：包含存储层的基线数据和转储数据（SSTable）。

日志归档：包含事务层生成的 Clog（Redo Log）。

粒度：支持租户级别的物理备份。OCP 云平台虽然有集群层级备份，但那只是图省事备份集群内所有租户，实际备份粒度仍然落在租户级，每个租户都需要开归档。各租户可独立决定是否开归档以及归档存储位置。

适用场景：需要快速恢复和高可靠性的场合，数据量较大时尤为合适。

1.2 逻辑备份 (Logical Backup)

概念：借助 OBDumper 导出数据库的逻辑结构和数据，不碰底层物理文件。

形式：通常以 SQL 语句或特定格式（如 CSV）导出数据。

粒度：可通过工具或 SQL 语句灵活导出指定的数据库、表、分区数据。

适用场景：需要灵活性和可移植性的场合，数据量较小或需要跨平台迁移时更合适。

1.3 备份介质 (Backup Media)

V 4.2.1 BP 7 之前：主要支持 NFS、阿里云 OSS、腾讯云 COS。

OBCP 实验考试时，会在 OCP 上配置一个 NFS Server，需要手动挂载到三台 OBServer 服务器的相同目录。

1、启动 nfs-server

$ systemctl start nfs-server

2、在其他三台 OBServer 服务器上再次验证，均能访问

$ showmount -e 192.168.11.200
Export list for 192.168.11.200:
/data/nfs_server *

$ mkdir -p /data/ob_backup
mount -t nfs4 -o rw,nfsvers=4.1,sync,lookupcache=positive,hard,timeo=600,wsize=1048576,rsize=1048576,namlen=255 192.168.11.200:/data/nfs_server /data/ob_backup

4、三台 OBServer 检查

$ df -h
Filesystem Size Used Avail Use% Mounted on
192.168.11.200:/data/nfs_server 99G 12G 83G 12% /data/ob_backup

8、随后进入白屏运维，新建租户级备份策略，执行全量备份

V 4.2.1 BP 7 及之后：新增支持 AWS S3 及兼容 S3 协议的对象存储（如华为 OBS、Google GCS 等）。

2. 日志归档架构

2.1 Clog 日志相关概念

2.1.1 Clog 的写入与副本同步

本地写入路径：集群正常运行时，每个日志流在本地记录事务日志，默认存放在服务器的 /data/log1 目录中。

副本同步机制：为保证分布式强一致性，Clog 由该日志流的 Leader 机器负责产生，并通过 Paxos 协议把日志同步发送给对应的 Follower 机器，多数派机器确认写入成功后事务才能提交。

2.1.2 Clog 的空间回收机制

空间回收触发条件：Clog 存储空间使用率达到 80%（高水位线）时，系统会自动触发对日志可回收空间的清理删除。

“可回收”日志的判定标准：

数据已落盘（SSTable）：Clog 对应的内存数据（MemTable）已经通过转储（Mini/Minor Freeze）或合并（Major Compaction）持久化到磁盘的基线/增量数据文件（SSTable）中。

日志已归档（若开启）：如果租户开启了日志归档功能，则该段 Clog 必须已经被成功归档到外部存储介质（如 OSS/NFS）中。

无未决事务：该 Clog 覆盖的事务必须全部提交或回滚，不存在活动的长事务占用。

2.2 日志归档

日志归档指的是日志数据的自动持续归档功能，OBServer 节点会自动且持续地把事务日志归档到指定的备份路径。

作用：把数据库产生的事务日志存到外部介质上，从而更长时间地保存数据库的所有 Redo Log 记录。

租户隔离：OceanBase 是多租户数据库，每个租户可独立决定是否开启日志归档功能，各租户之间的日志归档相互独立、互不影响。

归档主体与去重：归档日志由日志流 Leader 负责，备份优先在 Follower 机器上做，每个日志只归档一份。

进度管控：归档过程中，由 RS Leader 负责根据每个日志流的归档进度，计算出当前租户的全局归档进度。

OceanBase 与 Oracle 归档及备份路径机制对比

Oracle 数据库（“本地中转 + 后续打包备份”）：

归档流程：Oracle 开启归档后，在线日志（Online Redo Log）写满触发切换，ARCn 后台进程把日志复制到本地归档路径（如本地磁盘或 shared disk 的 ARCHIVELOG 目录）。

备份流程：RMAN 备份是一个主动发起的批处理作业。执行 RMAN 脚本时，才把数据文件、控制文件与存储在本地的归档日志二次拷贝到最终备份路径（如 tape 等）。

OceanBase 数据库（“直连远端 + 实时流式归档”）：

归档流程：OceanBase 开启归档后，每个日志流的 Leader 机器会把内存/本地产出的 Clog 实时、持续（Stream）地直接写入远端备份路径（如 NFS、阿里云 OSS 等对象存储）。

备份流程：数据备份（SSTable 宏块）独立定期开展；而日志归档则在后台不断向远端备份介质追加，不需要在本地占用专门的“归档日志存放目录”做中转。

2.3 数据备份

2.3.1 概述与核心界定

数据备份是指 OceanBase 数据库定期地将存储在磁盘上的数据文件（SSTable）复制并传输到指定外部存储介质的过程。

备份内容：主要包括数据库转储（Minor Freeze）和合并（Major Compaction）后产出的 SSTable 宏块数据。

与日志归档的区别：数据备份是定期的静态快照，日志归档则是持续的动态 Clog 记录。两者结合可实现指定时间点恢复（PITR）。

2.3.2 备份方式

OceanBase 提供以下两种数据备份方式：

全量备份（Full Backup）：备份租户内所有的宏块数据。

增量备份（Incremental Backup）：仅备份自上一次备份（全量或增量）以来新增和被修改过的宏块数据。

2.3.3 租户隔离规范

租户级独立配置：OceanBase 作为多租户数据库，每个租户可独立设置并开启数据备份功能，租户间互不影响。

为避免数据覆盖和混乱，不同的租户禁止设置相同的备份目录或路径。

2.3.4 副本选择与备份策略

优先选择 Follower 副本：数据备份任务会优先调度到日志流的 Follower 副本上执行。好处是：

保护 Leader 场景表现：数据备份属于高 I/O 任务，在 Follower 执行可避免抢占 Leader 的磁盘与 CPU 资源，保证生产读写无延迟。

充分利用集群资源：均衡分担集群内各个 OBServer 节点的工作负载。

强一致性保障：得益于 Paxos 协议，Follower 上的 SSTable 与 Leader 完全一致，确保备份数据的正确性。

3. 物理备份的流程

3.1 设置日志归档目的地

在开启日志归档前，必须先设置归档路径（LOG_ARCHIVE_DEST）和相关策略。

ALTER SYSTEM SET LOG_ARCHIVE_DEST=’LOCATION=archive_path [BINDING=archive_mode] [PIECE_SWITCH_INTERVAL=piece_switch_interval]’ [TENANT = tenant_name];

虽然可以通过 ALTER SYSTEM 设置 LOG_ARCHIVE_DEST 参数，但它并非一个配置项。因此，不能通过 SHOW PARAMETERS like xx 查询。参数详细说明：

LOCATION（必选）：指定归档目的地（路径和文件目录），支持 NFS、对象存储介质。

BINDING（可选）：设置归档与业务的优先方式，默认是 Optional 模式。

Optional（业务优先）：优先保证业务正常运行。如果归档跟不上，Clog 回收时不会等待归档完成，可能出现归档断流（缺日志），后续可能无法恢复到断流点之后。

Mandatory（归档优先）：优先保证数据安全性。Clog 回收必须等待日志成功归档。若归档介质异常或卡住，会导致本地 Clog 无法回收，进而触发磁盘空间满并影响业务写入。

PIECE_SWITCH_INTERVAL（可选）：设置 piece（片段）的切换周期，取值范围为 [1d, 7d]，默认为 1d。

OceanBase 按照 Piece 来组织管理归档数据，一个 Piece 代表某个租户在连续一段时间内完整日志的集合。

TENANT（可选）：在 SYS 系统租户中执行时，必须指定用户租户名；若直接在普通用户租户下执行，则无需指定。

ALTER SYSTEM SET LOG_ARCHIVE_DEST=’LOCATION=file:///data/obbackup/archive’ TENANT = obmy;

执行完会创建如下文件夹和文件

[root@oceanbase2 archive]# pwd
/data/obbackup/archive
[root@oceanbase2 archive]# ll
total 4
drwx—— 2 admin admin 53 Sep 7 09:30 check_file
-rw——- 1 admin admin 142 Sep 7 09:30 format.obbak
drwx—— 7 admin admin 149 Sep 7 09:31 piece_d1001r1p1
drwx—— 2 admin admin 57 Sep 7 09:31 pieces
drwx—— 2 admin admin 39 Sep 7 09:31 rounds
[root@oceanbase1 archive]# cd piece_d1001r1p1/
[root@oceanbase1 piece_d1001r1p1]# ll
total 4
drwx—— 2 admin admin 86 Sep 7 09:33 checkpoint
drwx—— 4 admin admin 36 Sep 7 09:31 logstream_1
drwx—— 3 admin admin 17 Sep 7 09:31 logstream_1001
drwx—— 3 admin admin 17 Sep 7 09:31 logstream_1002
drwx—— 3 admin admin 17 Sep 7 09:31 logstream_1003
-rw——- 1 admin admin 125 Sep 7 09:31 tenant_archive_piece_infos.obarc

/archive/ 目录：

format.obbak：归档格式化标记文件。记录了当前归档路径的格式版本、创建时间、集群/租户元数据等信息。OceanBase 在使用该目录作为归档目的地时会生成此文件，用于校验归档目录的合法性与兼容性。

piece_d1001r1p1/：具体的归档分片目录（Piece 目录）。命名规则一般为 piece_drp：

d1001：归档目的地 ID（Destination ID）。

r1：归档轮次（Round 1），表示第 1 次开启归档。如果关闭归档后重新开启，轮次会递增。

p1：分片编号（Piece 1），归档数据会按时间或大小切割成多个 Piece 依次递增（如 p1, p2, p3…）。

pieces/：记录 Piece 生命周期和状态历史的目录，存放与 Piece 切换相关的历史元数据文件。

rounds/：记录归档轮次（Round）状态与历史元数据的目录，用来追踪每次开启/关闭归档的生命周期。

check_file/：归档自检与完整性校验目录，OceanBase 后台任务会通过该目录下的校验文件确认归档数据的完整性。

piece_d1001r1p1/ 内部目录结构：

checkpoint/：归档检查点目录。记录当前 Piece 内各个日志流（Logstream）的归档进度（Archive SCN），保证恢复时可以精确知道日志的连续性和边界。

logstream_1/ 及 logstream_100x/：日志流数据目录。OceanBase 4.x 使用多日志流结构：

logstream_1：系统日志流，存放系统租户/租户级系统表（如元数据、事务状态表）的 Redo 日志。

logstream_1001, 1002, 1003…：用户数据日志流，对应表空间/分区的用户数据写入 Redo 日志。日志流内部包含分段切片的 .pal 或 .arc 日志文件。

tenant_archive_piece_infos.obarc：Piece 碎片元数据文件。记录了当前租户下所有 Piece（归档分片）的状态、起始时间/SCN、结束时间/SCN 等全局信息，供恢复（Restore）时快速锚定需要拉取哪些分片。

— 系统租户查看所有租户的日志归档路径
SELECT * FROM oceanbase.CDB_OB_ARCHIVE_DEST;
+———–+———+———————–+——————————-+
| TENANT_ID | DEST_NO | NAME | VALUE |
+———–+———+———————–+——————————-+
| 1002 | 0 | binding | OPTIONAL |
| 1002 | 0 | dest_id | 1001 |
| 1002 | 0 | path | file:///data/obbackup/archive |
| 1002 | 0 | piece_switch_interval | 1d |
| 1002 | 0 | state | ENABLE |
+———–+———+———————–+——————————-+

— 当前租户查看本租户的日志归档路径
SELECT * FROM DBA_OB_ARCHIVE_DEST;
+———+———————–+——————————-+
| DEST_NO | NAME | VALUE |
+———+———————–+——————————-+
| 0 | binding | OPTIONAL |
| 0 | dest_id | 1001 |
| 0 | path | file:///data/obbackup/archive |
| 0 | piece_switch_interval | 1d |
| 0 | state | ENABLE |
+———+———————–+——————————-+

3.2 开启归档

设置好目的地后，执行 SQL 开启归档：

核心字段解读：

ROUND_ID：归档轮次，开启归档为 1，重新开启会递增。

STATUS：归档状态，常见如 DOING（正在归档）、STOP（停止）。

START_SCN_DISPLAY：本次归档的起点时间位点。

CHECKPOINT_SCN_DISPLAY：最新归档成功的位点（在此之前的日志都已安全入库）。

3.3 设置数据备份路径

OceanBase V4 可以为日志归档和数据备份设置不同的目的地（或目录）。

系统租户使用 CDB_OB 视图查看所有租户的信息，用户租户使用 DBA_OB 视图查看本租户的信息。

3.4 开启数据备份

数据备份可以是全量备份，也可以是增量备份，执行增量备份前至少要有一份全量备份。

— 发起全量备份
ALTER SYSTEM BACKUP {DATABASE | TENANT = tenant_name} [PLUS ARCHIVELOG];
— 发起增量备份
ALTER SYSTEM BACKUP INCREMENTAL {DATABASE | TENANT = tenant_name};

参数说明：

DATABASE：在 SYS 租户下执行时，表示对所有租户发起备份；在普通用户租户下执行时，仅对当前租户生效。

PLUS ARCHIVELOG（可选）：在发起全量备份的同时，把当前的归档日志一并打包拷贝到数据备份目录下，构成一个自包含、具备独立恢复能力的数据集（无需额外依赖外部归档目录）。

执行备份并查看备份任务进度与历史：

— 查看备份历史摘要
SELECT TENANT_ID, ROUND_ID, STATUS, START_SCN, CHECKPOINT_SCN, COMMENT FROM oceanbase.CDB_OB_ARCHIVELOG_SUMMARY WHERE TENANT_ID = 1002;
+———–+———-+——–+———————+———————+———+
| TENANT_ID | ROUND_ID | STATUS | START_SCN | CHECKPOINT_SCN | COMMENT |
+———–+———-+——–+———————+———————+———+
| 1002 | 1 | DOING | 1788744674422245711 | 1788746595096081692 | |
+———–+———-+——–+———————+———————+———+

— 查看已经完成或失败的历史备份作业记录
SELECT JOB_ID, BACKUP_TYPE, PLUS_ARCHIVELOG, START_TIMESTAMP, END_TIMESTAMP, STATUS, RESULT
FROM DBA_OB_BACKUP_JOB_HISTORY;
— sys 租户下查看备份进度
SELECT * FROM oceanbase.CDB_OB_BACKUP_JOBS;
— sys 租户查看备份历史
SELECT
JOB_ID, — 备份作业ID
BACKUP_SET_ID, — 备份集ID
INITIATOR_TENANT_ID, — 租户ID
BACKUP_TYPE, — 备份类型 (FULL/INC)
STATUS, — 当前状态 (DOING/COMPLETED/FAILED)
START_TIMESTAMP, — 开始时间
END_TIMESTAMP, — 结束时间
PATH — 备份存储路径
FROM oceanbase.CDB_OB_BACKUP_JOB_HISTORY;
+——–+—————+———————+————-+———–+—————————-+—————————-+—————————-+
| JOB_ID | BACKUP_SET_ID | INITIATOR_TENANT_ID | BACKUP_TYPE | STATUS | START_TIMESTAMP | END_TIMESTAMP | PATH |
+——–+—————+———————+————-+———–+—————————-+—————————-+—————————-+
| 1 | 1 | 1002 | FULL | COMPLETED | 2026-09-07 09:55:46.415275 | 2026-09-07 09:57:42.262472 | file:///data/obbackup/data |
+——–+—————+———————+————-+———–+—————————-+—————————-+—————————-+

— 查看备份文件
[root@oceanbase1 data]# cd backup_set_1_full/
[root@oceanbase1 backup_set_1_full]# pwd
/data/obbackup/data/backup_set_1_full
[root@oceanbase1 backup_set_1_full]# ll
4.0K backup_set_1_full_20260907T095548_20260907T095742.obbak
204K infos
39M logstream_1
184K logstream_1001
136K logstream_1002
136K logstream_1003
4.0K single_backup_set_info.obbak
4.0K tenant_backup_set_infos.obbak

视图速查汇总：

4. 物理恢复架构

物理恢复本质上是基于物理备份（数据备份与归档日志）在 OceanBase 中重建租户或表的过程。恢复出来的租户可以位于原集群，也可以跨集群恢复到新的目标集群。

4.1 物理恢复分类

4.1.1 恢复粒度

租户级恢复：基于备份数据重新建一个新的租户，恢复内容包括租户系统表和所有用户表。

表级恢复：仅从备份数据中提取用户指定的表并恢复到已有租户中。表级恢复需通过辅助租户（Auxiliary Tenant）完成。先将包含目标表的备份恢复到辅助租户，再把表数据复制到目标租户，最后销毁辅助租户。

租户级。

truncate table、闪回查询、回收站都无法恢复，只能采用备份恢复。

传统 Oracle 数据库的恢复是原地覆盖，用备份文件覆盖当前数据库里的数据文件；OceanBase 的恢复是异位生成，重新创建一个全新的目标租户，原始租户完全不受影响，可正常提供读写服务。

4.1.2 恢复位点（Recovery Point）

完全恢复：先拉取基线数据备份，再重做所有归档 Clog，让租户数据恢复到最新的物理一致位点。

不完全恢复（PITR）：拉取基线数据备份后，仅重做部分 Clog，将租户数据精确还原到指定的历史时间点（或 SCN）。

4.2 物理恢复租户流程与命令

新建租户遵循三部曲（创建资源规格、创建资源池、创建租户关联资源池），然后将物理备份的数据恢复到目标租户中，物理恢复租户第一步要新建目标租户。

clog 日志来恢复数据到指定的一致点。

4.2.1 准备资源单元与资源池

在 SYS 系统租户下创建目标租户所需的资源：

CREATE RESOURCE UNIT u1 MAX_CPU 1, MEMORY_SIZE = ‘2G’;
CREATE RESOURCE POOL p1 unit = ‘u1’, unit_num = 1, zone_list = (‘zone1′,’zone2′,’zone3’);

4.2.2 执行恢复

ALTER SYSTEM RESTORE dest_tenant_name FROM uri [ UNTIL {TIME=’timestamp’ | SCN=scn} ] WITH ‘restore_option’;
— 系统租户执行恢复，指定备份路径和日志归档路径，并指定资源池
ALTER SYSTEM RESTORE my FROM ‘file:///data/obbackup/data,file:///data/obbackup/archive’ WITH ‘pool_list=p1&primary_zone=zone1’;

使用 DBA_OB_RESTORE_PROGRESS 查看正在执行的恢复任务，使用 DBA_OB_RESTORE_HISTORY 查看已经完成的恢复任务。

— 系统租户下查看所有租户恢复状态
SELECT * FROM oceanbase.CDB_OB_RESTORE_PROGRESS;
SELECT
JOB_ID,
RESTORE_TENANT_NAME, — 恢复生成的新租户名
BACKUP_TENANT_NAME, — 原始备份租户名
STATUS, — 当前恢复阶段 (如 CREATE_TENANT, RESTORE_USER_DATA)
RESTORE_SCN_DISPLAY, — 恢复目标时间点
RESTORE_PROGRESS, — 恢复进度百分比
START_TIMESTAMP — 任务开始时间
FROM oceanbase.CDB_OB_RESTORE_PROGRESS;
+——–+———————+——————–+—————————-+—————————-+——————+—————————-+
| JOB_ID | RESTORE_TENANT_NAME | BACKUP_TENANT_NAME | STATUS | RESTORE_SCN_DISPLAY | RESTORE_PROGRESS | START_TIMESTAMP |
+——–+———————+——————–+—————————-+—————————-+——————+—————————-+
| 2 | my | obmy | WAIT_TENANT_RESTORE_FINISH | 2026-09-07 10:35:15.536058 | NULL | 2026-09-07 10:36:13.943372 |
| 2 | my | obmy | RESTORING | 2026-09-07 10:35:15.536058 | 99.83 | 2026-09-07 10:36:13.943372 |
+——–+———————+——————–+—————————-+—————————-+——————+—————————-+

— 用户租户查看当前正在执行的恢复任务
SELECT * FROM oceanbase.DBA_OB_RESTORE_PROGRESS;
— 用户租户查看已完成的恢复历史记录
SELECT * FROM oceanbase.DBA_OB_RESTORE_HISTORY;

点击 OCP 租户页面，此时可看到恢复出来的 my 租户是备租户：

obclient -h192.168.182.22 -P2881 -uroot@my -p’OBexampas123%^&’ -c -A -Dlab4spm
obclient [lab4spm]> insert into tb1 values(1,1,’a’,’a’);
ERROR 4688 (HY000): standby tenant is read only

连通备租户发现插入数据报错，因为备租户是只读状态。准确来讲：

备份恢复流程就是搭建了一个备租户，将备租户应用日志到指定时间点。后续可选择作为灾备库持续日志同步（主备租户），也可选择激活成主租户（备份恢复）。

4.2.3 恢复后的后续关键运维

刚恢复完成的租户默认处于备租户状态（只读），需要根据实际情况执行激活或日志追赶运维。

创建备租户并持续同步（主备库结构）

如果该恢复租户用于作为灾备库，可以开启日志持续同步：

— 持续回放源租户的日志
ALTER SYSTEM RECOVER STANDBY [TENANT = tenant_name] UNTIL { TIME=’timestamp’ | SCN=scn_no | UNLIMITED };

转为主租户（切换为可读写）

如果恢复目的是数据救急或搭建新独立环境，需把它提升为主租户：

— 将备租户激活为主租户（让其拥有读写能力）
ALTER SYSTEM ACTIVATE STANDBY [TENANT = tenant_name];
obclient [oceanbase]> ALTER SYSTEM ACTIVATE STANDBY TENANT=my;
Query OK, 0 rows affected (2.408 sec)

OCP 页面已经显示为：主租户

激活成为主租户后，便可插入数据了。

跨大版本恢复后的租户升级

如果把低版本集群备份出的数据恢复到了高版本集群中，转为主租户后必须执行租户升级流程：

— 升级租户元数据与内部表结构
ALTER SYSTEM RUN UPGRADE JOB “UPGRADE_ALL” TENANT = tenant_name;

注意：只有当恢复出来的租户已经转换为主租户（Active Master）后，才能执行 RUN UPGRADE JOB 升级操作。