备份恢复
备份恢复
物理备份与恢复概述
备份恢复是 OceanBase 数据库高可用特性的核心组件，主要用于保障数据的安全，包括预防存储介质损坏和用户的错误操作等。如果存储介质损坏或者用户误操作而导致了数据丢失，可以通过恢复的方式恢复用户的数据。
概述
OceanBase 数据库的备份恢复模块提供了备份、恢复、清理三大功能。
OceanBase 数据库当前版本除了支持 OSS、NFS 等备份介质以外，从 V4.2.1 BP7 版本开始，还支持 AWS S3 以及兼容 S3 协议的对象存储（例如：华为 OBS、Google GCS、腾讯云 COS），提供了备份、恢复、清理三大功能。
OceanBase 数据库支持租户级别的物理备份。物理备份由数据备份、日志归档两种数据组成，故物理备份由数据备份和日志归档两个功能组合而成。这里的租户指的是用户的 User 租户，不支持 sys 租户和 Meta 租户的物理备份。
数据备份指的是备份数据的功能，该功能分为全量备份和增量备份两种：
- 全量备份是指备份所有的宏块。
- 增量备份是指备份上一次备份以后新增和修改过的宏块。
注意
在进行物理备份操作时，需要先开启日志归档模式后，才能执行数据备份。
备份内容
数据备份主要备份的数据如下
- 租户相关信息，包括租户名、集群名、时区（Zone）、Locality、租户的兼容模式（MySQL 或 Oracle）等
- 全部用户表数据（以及用户信息）
说明
数据备份会备份系统变量，且对于 V4.2.1 BP10 及以上版本，还会备份租户级配置项，但不会备份集群级配置项以及私有系统表数据。
日志归档
- 日志归档是指日志数据的自动归档功能，OBServer 节点会定期将日志数据归档到指定的备份路径。这个动作是全自动的，不需要外部定期触发。
恢复说明
-
OceanBase 数据库支持租户级别和表级别的恢复。租户级恢复是基于已有数据的备份重建新租户的过程，用户只需要一个 alter system restore tenant 命令，就可以完成整个恢复过程。租户级的整个恢复过程包括租户系统表和用户表的 Restore 和 Recover 过程。Restore 是将恢复需要的基线数据恢复到目标租户的 OBServer 节点，Recover 是将基线对应的日志恢复到对应的 OBServer 节点。
-
表级恢复是从备份数据中将用户指定的表恢复到一个已存在的租户，并且该已存在的租户与原表所在的租户可以是同一个租户，也可以是同一集群中的不同租户，还可以是不同集群中的租户。
备份介质要求
OceanBase 数据库当前版本除了支持阿里云 OSS 和 NFS 等备份介质以外，从 V4.2.1 BP7 版本开始，还支持 AWS S3 以及兼容 S3 协议的对象存储（例如：华为 OBS、Google GCS、腾讯云 COS），部分备份介质需要满足一些基本要求才能使用。
SDK 版本要求
对象存储 SDK 版本与 observer 版本对应关系如下：
| oss-c-sdk | s3-cpp-sdk | |
|---|---|---|
| 4.2.1 BP6 及之前版本 | 3.9.2 | 不支持 |
| 4.2.1 BP7/8/9 | 3.9.2 | 1.11.156 |
| 4.2.1 BP10 | 3.11.2 | 1.11.156 |
接口要求
阿里云 OSS：
支持阿里云官方的 OSS，依赖的接口如下表所示。
仅支持 V1 签名算法。
NFS：要求其版本为 NFS 4.1 及以上版本。
兼容 S3 协议的对象存储（例如：华为 OBS、Google GCS、腾讯云 COS）：
需要兼容支持下表所示的 S3 API 行为。
默认支持 Virtual-hosted–style 的对象访问 URL。有关 Virtual-hosted–style 请求的详细说明，参见 AWS S3 官网。其他访问方式的配置请参见 ALTER SYSTEM - SET LOG_ARCHIVE_DEST。
选择备份介质时，可以通过 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 的基线数据。
集群级配置项备份目录
对于 V4.2.1 版本，从 V4.2.1 BP10 开始支持手动执行命令备份集群级配置项。
每发起一次集群级配置项的备份，系统就会在指定目录下产生一个集群级配置项的备份文件。具体目录结构如下所示。
cluster_parameters_backup_dest
非默认设置的集群级配置项信息，文件命名格式：`cluster_parameter.[timestamp]`
└── cluster_parameter.20241018T140609.obbak
日志归档目录
对于 OSS、NFS 等备份介质，日志归档功能在归档目的地创建的目录以及各目录下保存的文件类型如下所示。
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：该目录记录了数据字典的元信息，仅系统日志流才有，用户日志流下无该目录。
对于 S3 及以兼容 S3 协议访问的备份介质，其日志归档的目录结构与 OSS、NFS 等有所不同，其单个归档文件是由多个小文件和相应的元信息文件组成，具体目录结构如下所示。
说明
尽管 S3 及以兼容 S3 协议访问的备份介质与 OSS、NFS 等备份介质的日志归档目录结构不相同，但将这些备份介质上的备份文件通过跨云拷贝到 OSS、NFS 等备份介质上后，仍然支持恢复。例如，将原生 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 版本相关功能的差异性对比
日志归档
数据备份
物理恢复
浙公网安备 33010602011771号