首批通过分布式安全可靠测评,为关键业务系统打造
物理备份与恢复概述
更新时间:2026-04-21 13:17:09
备份恢复是 OceanBase 数据库高可用特性的核心组件,主要用于保障数据的安全,包括预防存储介质损坏和用户的错误操作等。如果存储介质损坏或者用户误操作而导致了数据丢失,可以通过恢复的方式恢复用户的数据。
概述
OceanBase 数据库的备份恢复模块提供了备份、恢复、清理三大功能。
OceanBase 数据库支持租户级别的物理备份。物理备份由数据备份、日志归档两种数据组成,故物理备份由数据备份和日志归档两个功能组合而成。这里的租户指的是用户的 User 租户,不支持 sys 租户和 Meta 租户的物理备份。
数据备份指的是备份数据的功能,该功能分为全量备份和增量备份两种:
全量备份是指备份所有的宏块。
增量备份是指备份上一次备份以后新增和修改过的宏块。
注意
在进行物理备份操作时,需要先开启日志归档模式后,才能执行数据备份。
数据备份主要备份的数据如下:
租户相关信息,包括租户名、集群名、时区(Zone)、Locality、租户的兼容模式(MySQL 或 Oracle)等
全部用户表数据
说明
数据备份会备份系统变量和租户配置项,但不会备份集群级配置项以及私有系统表数据。
日志归档是指日志数据的自动归档功能,OBServer 节点会定期将日志数据归档到指定的备份路径。这个动作是全自动的,不需要外部定期触发。
物理恢复整体架构如下:
物理恢复支持租户级恢复和表级恢复
租户级别恢复:租户级恢复是基于已有数据的备份重建新租户的过程。租户恢复保证了跨表、跨分区的全局一致性。
表级别恢复:表级恢复是从备份数据中将用户指定的表恢复到一个已存在的租户,并且该已存在的租户与原表所在的租户可以是同一个租户,也可以是同一集群中的不同租户,还可以是不同集群中的租户。
租户级恢复又支持全量恢复和快速恢复
注意
通过快速恢复方式恢复出来的租户不支持手动发起合并,不支持数据备份,也不支持 Switchover/Failover 成主库,只能作为备库存在。
全量恢复:指恢复宏块数据和增量日志,当所有数据都从备份介质恢复到本地后,完成恢复的租户才可以提供服务。全量恢复的整个过程包括租户系统表和用户表的 Restore 和 Recover 过程。Restore 是将恢复需要的基线数据恢复到目标租户的 OBServer 节点,Recover 是将基线对应的日志恢复到对应的 OBServer 节点。
快速恢复:指不恢复宏块数据就可以给用户提供服务,可以减少恢复等待时间并降低用户使用成本。
为您的物理恢复选择恢复时间点
完全恢复:不指定恢复的时间戳。
指定 SCN 或者时间戳的不完全恢复:其中,SCN 是 OceanBase 数据库内部精确的版本号。时间戳在 Oracle 模式下精确到纳秒,没有精度丢失;时间戳在 MySQL 模式下精确到微秒,会丢失微秒之后的精度。
物理恢复流程请参见恢复流程。
备份介质要求
OceanBase 数据库当前版本支持阿里云 OSS、NFS、Azure Blob(在 V4.3.5 版本中,从 V4.3.5 BP3 版本开始支持)、AWS S3 以及兼容 S3 协议的对象存储(例如:华为 OBS、Google GCS、腾讯云 COS) 等备份介质,部分备份介质需要满足一些基本要求才能使用。
SDK 版本要求
对象存储 SDK 版本与 observer 版本对应关系如下:
| oss-c-sdk | s3-cpp-sdk | |
|---|---|---|
| 4.3.4 及以上版本 | 3.11.2 | 1.11.156 |
接口要求
阿里云 OSS:
支持阿里云官方的 OSS,依赖的接口如下表所示。
接口名 描述 PutObject 上传单个对象 DeleteObject 删除单个对象 DeleteObjects 批量删除对象 GetObject 获取某个对象 ListObjects 列举存储空间中的所有对象(依赖强一致) HeadObject 获取某个对象的元数据 AppendObject 以追加写的方式上传对象 PutObjectTagging(可选项) 设置或更新对象的标签 GetObjectTagging(可选项) 获取对象标签 InitiateMultipartUpload 初始化分片上传 UploadPart 上传分片 CompleteMultipartUpload 合并已上传分片为一个对象 AbortMultipartUpload 取消分片上传,删除已上传的分片 ListMultipartUploads 列出已经初始化但还未完成或还未终止的分片信息 ListParts 列出上传任务中已完成上传的分片信息 仅支持 V1 签名算法。
NFS:要求其版本为 NFS 3 及以上版本。
兼容 S3 协议的对象存储(例如:华为 OBS、Google GCS、腾讯云 COS):
需要兼容支持下表所示的 S3 API 行为。
接口名 描述 PutObject 上传单个对象 DeleteObject 删除单个对象 DeleteObjects 批量删除对象 GetObject 下载单个对象 ListObjects 列路举径下的所有对象 HeadObject 获取某个对象的元数据 PutObjectTagging(可选项) 设置对象标签 GetObjectTagging(可选项) 获取对象标签 CreateMultipartUpload 初始化分片上传 UploadPart 上传单个分片 CompleteMultipartUpload 合并已上传分片为一个对象 AbortMultipartUpload 中止分片上传,删除已上传分片 ListMultipartUploads 列出上传的分片 ListParts 列出上传任务中已完成上传的分片信息 需要支持 Virtual-hosted–style 的对象访问 URL。有关 Virtual-hosted–style 请求的详细说明,参见 AWS S3 官网。
选择备份介质时,可以通过 ob_admin 工具中的 test_io_device 命令来验证该备份介质所提供的 I/O 接口及当前 I/O 权限是否满足备份恢复的需要。同时,还可以使用 ob_admin 工具中的 io_adapter_benchmark 命令来查看 OBServer 节点到备份介质的读写性能,以作为备份性能的参考。有关 test_io_device 和 io_adapter_benchmark 命令的详细说明及使用,参见 test_io_device 和 io_adapter_benchmark。
目录结构
数据备份目录
数据备份功能在备份目的地创建的目录以及各目录下保存的文件类型如下所示。
data_backup_dest
├── format.obbak // 备份路径的格式化信息
├── check_file
│ └── 1002_connect_file_20230111T193020.obbak // 连通性检查文件
├── backup_sets // 数据备份列表的汇总目录,记录了所有的数据备份集列表
│ ├── backup_set_1_full_end_success_20230111T193420.obbak // 全量备份结束占位符
│ ├── backup_set_1_full_start.obbak // 全量备份起始占位符
│ ├── backup_set_2_inc_start.obbak // 增量备份起始占位符
│ └── backup_set_2_inc_end_success_20230111T194420.obbak // 增量备份结束占位符
└── backup_set_1_full // 全量备份集,文件结尾为 full 表示是全量备份,inc 表示是增量备份
├── backup_set_1_full_20230111T193330_20230111T193420.obbak //占位符,展示全量备份的开始和结束时间
├── single_backup_set_info.obbak // 当前备份集的元信息
├── tenant_backup_set_infos.obbak // 当前租户的全量备份集信息
├── infos
│ ├── table_list //全量表名文件
│ │ ├── table_list.1702352553000000000.1.obbak //表名文件 1
│ │ ├── table_list.1702352553000000000.2.obbak //表名文件 2
│ │ └── table_list_meta_info.1702352553000000000.obbak //表名元信息文件
│ ├── major_data_info_turn_1 // major turn 1 下的租户级备份文件
│ │ ├── tablet_log_stream_info.obbak // tablet 与 日志流的映射文件
│ │ ├── tenant_major_data_macro_range_index.0.obbak // major 宏块索引
│ │ ├── tenant_major_data_meta_index.0.obbak // major meta 索引
│ │ └── tenant_major_data_sec_meta_index.0.obbak // major 逻辑 id 与物理 id 的映射文件
│ ├── minor_data_info_turn_1 // minor turn 1 下的租户级备份文件
│ │ ├── tablet_log_stream_info.obbak // tablet 与 日志流映射文件
│ │ ├── tenant_minor_data_macro_range_index.0.obbak // minor 宏块索引
│ │ ├── tenant_minor_data_meta_index.0.obbak // minor meta 索引
│ │ └── tenant_minor_data_sec_meta_index.0.obbak // minor 逻辑 id 与物理 id 映射
│ ├── diagnose_info.obbak // 备份集诊断信息文件
| ├── tenant_parameter.obbak // 当前租户非默认设置的租户级配置项信息
│ ├── locality_info.obbak // 当前备份集的所属租户的 locality 信息,包括租户的资源配置信息和副本分布信息
│ └── meta_info // 租户级别的日志流元信息文件,包含所有日志流的元信息
│ ├── ls_attr_info.1.obbak // 备份时的日志流列表快照
│ └── ls_meta_infos.obbak // 所有日志流的 meta 集合
├── logstream_1 // 1 号日志流
│ ├── major_data_turn_1_retry_0 // turn 1,retry 0 下的基线数据
│ │ ├── macro_block_data.0.obbak // 一个数据文件,大小为 512 MB ~ 4 GB
│ │ ├── macro_range_index.obbak // macro索引
│ │ ├── meta_index.obbak // meta 索引
│ │ └── sec_meta_index.obbak // 逻辑 id 与物理 id 的映射文件
│ ├── meta_info_turn_1_retry_0 // turn 1,retry 0 下的日志流元信息文件
│ │ ├── ls_meta_info.obbak // 日志流元信息
│ │ └── tablet_info.1.obbak // 日志流 tablet meta 列表
│ ├── minor_data_turn_1_retry_0 // turn 1,retry 0 下的转储数据
│ │ ├── macro_block_data.0.obbak
│ │ ├── macro_range_index.obbak
│ │ ├── meta_index.obbak
│ │ └── sec_meta_index.obbak
│ └── sys_data_turn_1_retry_0 //turn 1, retry 0 下的系统 tablet 数据
│ ├── macro_block_data.0.obbak
│ ├── macro_range_index.obbak
│ ├── meta_index.obbak
│ └── sec_meta_index.obbak
└── logstream_1001 // 1001 号日志流
├── major_data_turn_1_retry_0
│ ├── macro_block_data.0.obbak
│ ├── macro_range_index.obbak
│ ├── meta_index.obbak
│ └── sec_meta_index.obbak
├── meta_info_turn_1_retry_0
│ ├── ls_meta_info.obbak
│ └── tablet_info.1.obbak
├── minor_data_turn_1_retry_0
│ ├── macro_block_data.0.obbak
│ ├── macro_range_index.obbak
│ ├── meta_index.obbak
│ └── sec_meta_index.obbak
└── sys_data_turn_1_retry_0
├── macro_block_data.0.obbak
├── macro_range_index.obbak
├── meta_index.obbak
└── sec_meta_index.obbak
数据备份目录中,顶层目录包含以下三种数据:
format.obbak:用于记录备份路径的元信息。check_file:用于用户数据备份目录的连通性检查。backup_sets:数据备份列表的汇总目录,记录了所有的数据备份集列表。backup_set_1_full:该目录表示的是一个数据备份集,目录名结尾为full表示全量备份,为inc表示增量备份。每一次数据备份都会生成一个对应的备份集,数据备份结束后,该备份集就不会再修改了。在一个数据备份集下,主要包含以下数据:
backup_set_1_full_20230111T193330_20230111T193420.obbak:该文件展示了当前备份集的 ID、开始和结束的时间。此文件仅用来展示信息。single_backup_set_info.obbak:该文件记录了当前备份集的元信息,包括备份的位点、依赖的日志等信息。tenant_backup_set_infos.obbak:该文件记录了当前租户已有的所有备份集的元信息。infos:该目录记录了数据备份集的元信息。logstream_1:该目录记录了 1 号日志流的所有数据,1 号日志流是 OceanBase 数据库租户的系统日志流。logstream_1001:该目录记录了 1001 号日志流的所有数据,大于 1000 的日志流是 OceanBase 数据库租户的用户日志流。
同时,每个日志流备份下还有 4 种目录,含
retry的目录表示日志流级别的重试;含turn的目录表示租户级别的重试:meta_info_xx:该目录记录了 LS 元信息和 Tablet 元信息。sys_data_xx:该目录记录了 LS 内部系统 Tablet 的数据。minor_data_xx:该目录记录了普通 Tablet 的转储数据。major_data_xx:该目录记录了普通 Tablet 的基线数据。
集群级配置项备份目录
每发起一次集群级配置项的备份,系统就会在指定目录下产生一个集群级配置项的备份文件。具体目录结构如下所示。
cluster_parameters_backup_dest
├── cluster_parameter.20240710T103610.obbak # 非默认设置的集群级配置项信息,文件命名格式:`cluster_parameter.[timestamp]`
└── cluster_parameter.20241018T140609.obbak
日志归档目录
对于 NFS、OSS、Azure Blob 等备份介质,日志归档功能在归档目的地创建的目录以及各目录下保存的文件类型如下所示。
log_archive_dest
├── check_file
│ └── 1002_connect_file_20230111T193049.obbak // 连通性检查文件
├── format.obbak // 备份路径的格式化信息
├── rounds // Rounds 占位符目录
│ └── round_d1002r1_start.obarc // Round 开始占位符
├── pieces // Piece 占位符目录
│ ├── piece_d1002r1p1_start_20230111T193049.obarc // Piece 开始占位符,piece_DESTID_ROUNDID_PIECEID_start_DATE
│ └── piece_d1002r1p1_end_20230111T193249.obarc // Piece 结束占位符,piece_DESTID_ROUNDID_PIECEID_end_DATE
└── piece_d1002r1p1 // Piece 目录,目录命名格式为 piece_DESTID_ROUNDID_PIECEID
├── piece_d1002r1p1_20230111T193049_20230111T193249.obarc // 记录了 Piece 的连续区间
├── checkpoint
│ └── checkpoint.1673436649723677822.obarc // 记录 checkpoint_scn 信息,文件名命令格式为 checkpoint.checkpoint_scn
│ └── checkpoint_info.0.obarc // 记录 checkpoint 的元信息
├── single_piece_info.obarc // 记录该 Piece 的元信息
├── tenant_archive_piece_infos.obarc // 记录该 Piece 之前的所有 frozen Piece 的元信息
├── file_info.obarc // 所有日志流文件列表
├── logstream_1 // 1 号日志流
│ ├── file_info.obarc // 日志流1的文件列表
│ ├── log
│ │ └── 1.obarc // 1 号日志流下的归档文件
│ └── schema_meta // 记录数据字典的元信息,只会在 1 号日志流生成此文件
│ └── 1677588501408765915.obarc
└── logstream_1001 // 1001 号日志流
├── file_info.obarc // 1001 号日志流的文件列表
└── log
└── 1.obarc // 1001 号日志流的归档文件
上述日志归档目录中,顶层目录包含以下三种数据:
format.obbak:用于记录归档路径的元信息,包括使用路径的租户等信息。check_file:用于用户日志归档目录的连通性检查。rounds:日志归档的 Round 汇总列表,记录了所有 Round 的列表。pieces:日志归档的 Piece 汇总列表,记录了所有的 Piece 的列表。piece_d1002r1p1:日志归档的 Piece 目录,目录命名格式为piece_DESTID_ROUNDID_PIECEID。其中,DESTID指的是log_archive_dest对应的 id;ROUNDID指的是日志归档 Round 的 id,是一个单调递增的整数;PIECEID指的是日志归档 Piece 的 id,也是一个单调递增的整数。一个日志归档的 Piece 目录下,又包含以下数据:
piece_d1002r1p1_20230111T193049_20230111T193249.obarc:该文件展示了当前 Piece 的 id、开始和结束的时间,并且仅用来展示信息。checkpoint:该目录是 Active 的 Piece 记录归档位点的目录,ObArchiveScheduler 模块会定期更新该目录的位点信息。其中:checkpoint.1673436649723677822.obarc:该文件名上记录了 Piece 的 checkpoint_scn 信息,1673436649723677822即为对应的 checkpoint_scn。checkpoint_info.0.obarc:该文件记录了活跃的 Piece 的 checkpoint 的元信息,这些元信息包括 tenant_id、dest_id、round_id、piece_id 等。元信息在一个 Piece 中保持不变。
single_piece_info.obarc:该文件记录了当前 Piece 的元信息。tenant_archive_piece_infos.obarc:该文件记录了当前租户内所有 Frozen Pieces 的元信息。file_info.obarc:该文件记录了 Piece 内的日志流列表。logstream_1:该目录记录了 1 号日志流的日志文件,1 号日志流是 OceanBase 数据库租户的系统日志流。logstream_1001:该目录记录了 1001 号日志流的日志文件,大于 1000 的日志流是 OceanBase 数据库租户的用户日志流。
同时,每个日志流备份下还有 3 种数据:
file_info.obarc:该文件记录了日志流内的文件列表。log:该目录中保存了当前日志流的所有归档文件,文件名和源集群内部的日志文件一致。schema_meta:该目录记录了数据字典的元信息,仅系统日志流才有,用户日志流下无该目录。
对于 AWS S3 及以兼容 S3 协议访问的备份介质,其日志归档的目录结构与 OSS、NFS、COS 等有所不同,其单个归档文件是由多个小文件和相应的元信息文件组成,具体目录结构如下所示。
说明
尽管 AWS S3 及以兼容 S3 协议访问的备份介质与 OSS、NFS、Azure Blob 等备份介质的日志归档目录结构不相同,但将这些备份介质上的备份文件通过跨云拷贝到 OSS、NFS、Azure Blob 等备份介质上后,仍然支持恢复。例如,将 AWS S3 归档的数据拷贝到 OSS 上,使用该 OSS 路径,仍然可以成功恢复。
log_archive_dest
├── ......
└── piece_d1002r1p1 // Piece 目录,目录命名格式为 piece_DESTID_ROUNDID_PIECEID
├── ...... // 所有日志流文件列表
├── logstream_1 // 1 号日志流
│ ├── file_info.obarc // 1 号日志流的文件列表
│ ├── log
│ │ └── 1.obarc // 1 号日志流下的归档文件, 由前缀标识
| | └── @APD_PART@0-32472973.obarc // 归档文件中的实际数据,记录了日志文件的第 0~32472973 Byte 的数据
| | └── ......
| | └── @APD_PART@FORMAT_META.obarc // 归档文件的格式
| | └── @APD_PART@SEAL_META.obarc // 归档文件的元信息
│ └── schema_meta // 记录数据字典的元信息,仅 1 号日志流上会生成此文件
│ └── 1677588501408765915.obarc
└── logstream_1001 // 1001 号日志流
├── file_info.obarc // 1001 号日志流的文件列表
└── log
└── 1.obarc // 1001 号日志流的归档文件
上述日志归档目录中,1.obarc 表示单个归档文件,单个归档文件由一个前缀标识,且前缀名称与归档文件名完全相同。单个归档文件下主要包含以下三种数据:
@APD_PART@FORMAT_META.obarc:初次向归档文件写入时,会在该目录下写入format_meta文件,用于记录归档文件的格式。@APD_PART@0-32472973.obarc:归档文件中的实际数据写在以该前缀命名的文件下,并将每次写入的起始偏移量和中止偏移量记录在文件名中。@APD_PART@SEAL_META.obarc:在最后一次向归档文件写入数据之后,会在该目录下生成seal_meta文件,用于记录归档文件内的元信息。
与 V3.x/V2.x 版本相关功能的差异性对比
日志归档
| 差异项 | V3.x/V2.2x | V4.x |
|---|---|---|
| 归档级别 | 集群级 | 租户级 |
| 归档粒度 | 按分区 | 按日志流 |
| 权限要求 | 只能通过 sys 租户操作,例如设置归档路径、开启归档、查看归档进度等 |
既可以通过 sys 租户操作,也可以通过用户租户的管理员用户操作 |
| 使用方式 |
|
通过 ALTER SYSTEM SET LOG_ARCHIVE_DEST 语句设置租户级归档路径以及 Piece 切换周期,默认为 1d 即 1 天,且日志归档路径与数据备份路径可以分别独立配置 |
| 切 Piece 功能 | 允许不开启切 Piece 的功能且默认不开启 | 仅允许开启切 Piece 功能,且默认周期 1 天 |
| 归档延迟时间的设置方法 | 通过 ALTER SYSTEM SET LOG_ARCHIVE_CHECKPOINT_INTERVAL 语句设置 |
通过 ALTER SYSTEM SET ARCHIVE_LAG_TARGET 语句设置 |
sys 租户下 执行 ALTER SYSTEM ARCHIVELOG 语句后的结果 |
开启当前集群中所有租户的归档,在归档开启后新建的租户也会自动开启归档 | 开启当前集群中所有租户的归档,在归档开启后新建的租户不会自动开启归档 |
| 归档日志压缩功能 | 通过 ALTER SYSTEM SET BACKUP_LOG_ARCHIVE_OPTION 设置 |
不支持 |
| 归档视图 | 归档相关视图主要为以下 3 个:
|
归档相关视图为以下 8 个:
|
| 归档介质要求 | 要求必须是 SSD | 可以是 HDD 或者 SSD |
| 归档文件数量 | 文件数量和分区数成正比,百万分区场景下,会产生海量小文件的问题。 | 文件数量少,与分区数无关,不会存在海量小文件的问题 |
| 备库归档 | 不支持 | 支持 |
数据备份
| 差异项 | V3.x/V2.2x | V4.x |
|---|---|---|
| 备份级别 | 集群级 | 租户级 |
| 权限 | 只能通过 sys 租户操作,例如设置备份路径,开始备份,查看备份进度等 |
既可以通过 sys 租户操作,也可以通过用户租户的管理员用户操作 |
| 备份路径的设置方法 | 通过 ALTER SYSTEM SET BACKUP_DEST 语句设置集群级的备份路径 |
通过 ALTER SYSTEM SET DATA_BACKUP_DEST 语句设置租户级备份路径,且数据备份路径与日志归档路径可以分别独立配置 |
| 指定路径的数据备份 | sys 租户通过执行 ALTER SYSTEM BACKUP TENANT tenant_name_list TO backup_destination; 语句发起 |
不支持 |
| BACKUP PLUS ARCHIVELOG 功能 | 不支持 | 支持 |
| 空间膨胀 | 备份期间保留快照点,会导致备份期间存储空间膨胀 | 不保留快照点,不会导致空间膨胀 |
| 备库备份 | 不支持 | 支持 |
| 视图 | 备份相关视图主要为以下 5 个:
|
备份相关视图主要为以下 10 个:
|
物理恢复
| 差异项 | V3.x/V2.2x | V4.x |
|---|---|---|
| 数据路径 | 在恢复命令中提供集群级备份路径 | 需要同时提供数据备份和日志归档 2 个路径 |
| 恢复并发度设置 | 在发起恢复命令前,通过 ALTER SYSTEM SET RESTORE_CONCURRENCY 语句设置 |
在恢复命令中指定 concurrecy |
| 秘钥管理方式 |
|
|
| 恢复完成后的租户角色 | 主租户,即主库 | 备租户,即备库 |
| 升级 | 恢复过程中会自动升级租户 | 恢复完成后需要手动升级租户 |
| 表级恢复 | 支持,且仅支持将表恢复到新租户(恢复过程中创建的租户)中,不支持恢复到已存在的租户中 | V4.2.1 版本开始支持,仅支持将表恢复到已存在的租户中,不支持恢复到新租户(恢复过程中创建的租户)中 |
| 快速恢复 | 不支持 | V4.3.3 版本开始支持 |
通过 ADD RESTORE SOURCE 语句来恢复 |
支持 | 不支持 |
相关文档
关于物理备份与恢复的更多详细介绍,请参见 备份恢复 章节。