Overview

Backup and restore are core components of the high availability feature of OceanBase Database. They are primarily used to protect data security against storage media failures and user errors. If data is lost due to storage media damage or user errors, the lost data can be restored.

Overview

The backup and restore module of OceanBase Database provides backup, restore, and purge functionalities.

OceanBase Database supports physical backup at the tenant level. Physical backup consists of data backup and log archive, so physical backup comprises the data backup and log archive features. In this context, a tenant is a user tenant. Physical backup is not supported for the sys tenant or the meta tenant.

The data backup feature allows you to perform full backup and incremental backup:

• A full backup backs up all macroblocks.

• An incremental backup backs up only the macroblocks that are added or modified since the last backup.

The data backup feature backs up the following data:

• Information about the tenant, including the tenant name, cluster name, zone, locality, and compatibility mode (MySQL or Oracle)

• Data of all user tables

• Data of all user tables

The log archive feature automatically archives log data. An OBServer node archives log data to the specified backup path on a regular basis. This process is automatic and does not require periodic triggering from the outside.

The overall architecture of physical restore is as follows: The overall architecture of physical restore is as follows:

1. Physical restore supports restore at the tenant level and table level.

   • Tenant-level restore: Tenant-level restore rebuilds a tenant based on existing backup data. Tenant restore ensures global consistency across tables and partitions.

   • Table-level restore: Table-level restore restores a specified table from backup data to an existing tenant. The existing tenant can be the same as the original tenant or a different tenant in the same cluster, or even a tenant in a different cluster.

2. Tenant-level restore supports complete restore and quick restore

   Notice

   Quick restore can be used only as a standby database and does not support data backup or switchover to the primary database.

   • A complete restore restores macroblock data and incremental logs. After all data is restored from backup media to the local system, the restored tenant can provide services. A complete restore comprises the restore and recover processes of system tables and user tables. In the restore process, baseline data is restored to the OBServer node that hosts the target tenant. In the recover process, logs that correspond to the baseline data are restored to the OBServer node.

   • A quick restore allows the database to provide services after a short waiting time, reducing the restore time and lowering the user costs.

3. Select a restore time point.

   • Complete restore: Does not specify a restore timestamp.

   • Incomplete restore: Specifies the restore timestamp or SCN. An SCN is an accurate version number in OceanBase Database. In Oracle mode, a timestamp is precise to the nanosecond; in MySQL mode, a timestamp is precise to the microsecond, with the precise microseconds lost.

For more information about the physical restore process, see Restore process.

Requirements for backup media

OceanBase Database of the current version supports Alibaba Cloud OSS, NFS, AWS S3, and object storage services compatible with the S3 protocol (such as Huawei Cloud OBS, Google Cloud GCS, and Tencent Cloud COS) as backup media. Some backup media require that some basic requirements be met.

SDK version requirements

The following table describes the SDK versions corresponding to the observer version:

Interface requirements

• Alibaba Cloud OSS:

  • The following table describes the interfaces required for Alibaba Cloud OSS.

    Interface name	Description
    PutObject	Uploads a single object.
    DeleteObject	Deletes a single object.
    DeleteObjects	Batch deletes objects.
    GetObject	Downloads a specific object.
    ListObjects	Lists all objects in a bucket (requires strong consistency).
    HeadObject	Queries the metadata of a specific object.
    AppendObject	Uploads an object in append write mode.
    PutObjectTagging (Optional)	Sets or updates the tags of an object.
    GetObjectTagging (Optional)	Queries the tags of an object.
    InitiateMultipartUpload	Initializes a multipart upload.
    UploadPart	Uploads a part.
    CompleteMultipartUpload	Merges the uploaded parts into a single object.
    AbortMultipartUpload	Cancels a multipart upload and deletes the uploaded parts.
    ListMultipartUploads	Lists multipart uploads that have been initialized but not completed or canceled.
    ListParts	Lists the parts uploaded in a multipart upload task.

  • Only the V1 signature algorithm is supported.

• NFS: The version must be NFS 4.1 or later.

• Object storage services that support the S3 protocol (such as Huawei OBS, Google GCS, and Tencent Cloud COS):

  1. It must be compatible with the following S3 APIs.

     Interface name	Description
     PutObject	Uploads a single object.
     DeleteObject	Deletes a single object.
     DeleteObjects	Batch deletes objects.
     GetObject	Downloads a single object.
     ListObjects	Lists all objects in a directory.
     HeadObject	Queries the metadata of a specific object.
     PutObjectTagging (Optional)	Sets or updates the tags of an object.
     GetObjectTagging (Optional)	Queries the tags of an object.
     CreateMultipartUpload	Initializes a multipart upload.
     UploadPart	Uploads a single part.
     CompleteMultipartUpload	Merges the uploaded parts into a single object.
     AbortMultipartUpload	Cancels a multipart upload and deletes the uploaded parts.
     ListMultipartUploads	Lists multipart uploads that have been initialized but not completed or canceled.
     ListParts	Lists the parts uploaded in a multipart upload task.

  2. It must support virtual-hosted-style object access URLs. For more information about virtual-hosted-style requests, see AWS S3.

Directory structure

Data backup directory

Data backup directory

The data backup feature creates the following directories in the backup destination and saves files of different types in the corresponding directories.

data_backup_dest
├── format.obbak                                            // The directory that records the metadata of the backup path.
├── check_file
│   └── 1002_connect_file_20230111T193020.obbak             // The connectivity check file.
├── backup_sets                                             // The summary directory of data backup lists. It records all data backup sets.
│   ├── backup_set_1_full_end_success_20230111T193420.obbak // The placeholder for indicating the end of a full backup.
│   ├── backup_set_1_full_start.obbak                       // The placeholder for indicating the start of a full backup.
│   ├── backup_set_2_inc_start.obbak                        // The placeholder for indicating the start of an incremental backup.
│   └── backup_set_2_inc_end_success_20230111T194420.obbak  // The placeholder for indicating the end of an incremental backup.
└── backup_set_1_full                                        // The full backup set. The files in the directory are named with the `full` suffix for full backups and the `inc` suffix for incremental backups.
    ├── backup_set_1_full_20230111T193330_20230111T193420.obbak // The placeholder that displays the start and end times of the full backup.
    ├── single_backup_set_info.obbak                        // The metadata of the current backup set.
    ├── tenant_backup_set_infos.obbak                       // The metadata of all full backup sets of the current tenant.
    ├── infos
    │   ├── table_list                                      // The file that records the full table names.
    │   │   ├── table_list.1702352553000000000.1.obbak      // Table name file 1.
    │   │   ├── table_list.1702352553000000000.2.obbak     // Table name file 2.
    │   │   └── table_list_meta_info.1702352553000000000.obbak  // The metadata file of table names.
    │   ├── major_data_info_turn_1                           // The directory that stores tenant-level backup files of major turn 1.
    │   │   ├── tablet_log_stream_info.obbak                 // The tablet-log stream mapping file.
    │   │   ├── tenant_major_data_macro_range_index.0.obbak  // The major macroblock index.
    │   │   ├── tenant_major_data_meta_index.0.obbak         // The major meta-index.
    │   │   └── tenant_major_data_sec_meta_index.0.obbak     // The major logical ID-physical ID mapping file.
    │   ├── minor_data_info_turn_1                           // The directory that stores tenant-level backup files of minor turn 1.
    │   │   ├── tablet_log_stream_info.obbak                 // The tablet-log stream mapping file.
    │   │   ├── tenant_minor_data_macro_range_index.0.obbak  // The minor macroblock index.
    │   │   ├── tenant_minor_data_meta_index.0.obbak         // The minor meta-index.
    │   │   └── tenant_minor_data_sec_meta_index.0.obbak     // The minor logical ID-physical ID mapping file.
    │   ├── diagnose_info.obbak                              // The diagnostic information file of the backup set.
    │   ├── locality_info.obbak                              // The locality information of the tenant to which the current backup set belongs.
    │   └── meta_info                                        // The metadata file of the log stream. It contains the metadata of all log streams.
    │       ├── ls_attr_info.1.obbak                         // A snapshot of the log stream list at the time of backup.
    │       └── ls_meta_infos.obbak                          // The meta collection of all log streams.
    ├── logstream_1                                          // The directory that records the data of log stream 1. Log stream 1 is the system log stream of the OceanBase tenant.
    │   ├── major_data_turn_1_retry_0                        // The baseline data of major turn 1, retry 0.
    │   │   ├── macro_block_data.0.obbak                     // A data file. Its size ranges from 512 MB to 4 GB.
    │   │   ├── macro_range_index.obbak                      // The macro-index.
    │   │   ├── meta_index.obbak                             // The meta-index.
    │   │   └── sec_meta_index.obbak                         // The logical ID-physical ID mapping file.
    │   ├── meta_info_turn_1_retry_0                         // The metadata file of log stream 1 of major turn 1, retry 0.
    │   │   ├── ls_meta_info.obbak                           // The metadata of log stream 1.
    │   │   └── tablet_info.1.obbak                          // The tablet meta-list of log stream 1.
    │   ├── minor_data_turn_1_retry_0                        // The dump data of log stream 1 of minor 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                          // The system tablet data of log stream 1 of major turn 1, retry 0.
    │       ├── macro_block_data.0.obbak
    │       ├── macro_range_index.obbak
    │       ├── meta_index.obbak
    │       └── sec_meta_index.obbak
    └── logstream_1001                                       // The directory that records the data of log stream 1001. Log stream 1001 is a user log stream of the OceanBase tenant.
        ├── 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

In the data backup directory, the top-level directories contain the following data: In the data backup directory, the top-level directories contain the following data:

• format.obbak: the directory that records the metadata of the backup path.

• check_file: the directory for performing connectivity checks on the user data backup directory.

• backup_sets: the summary directory of data backup lists. It records all data backup sets.

• backup_set_1_full: the directory that indicates a full backup set. The files in the directory are named with the full suffix for full backups and the inc suffix for incremental backups. A data backup set is generated each time data is backed up. After the backup is completed, the backup set will not be modified.

  In a full backup set, the following data is contained:

  • backup_set_1_full_20230111T193330_20230111T193420.obbak: the file that displays the ID, start, and end times of the current backup set. This file is used only for information display.

  • single_backup_set_info.obbak: the metadata file of the current backup set. It records the metadata of the backup set, including the backup location and the dependent logs.

  • tenant_backup_set_infos.obbak: the metadata file of all full backup sets of the current tenant.

  • infos: the directory that records the metadata of data backup sets.

  • infos: the directory that records the metadata of data backup sets.

  • logstream_1: the directory that records the data of log stream 1. Log stream 1 is the system log stream of the OceanBase tenant.

  • logstream_1001: the directory that records the data of log stream 1001. Log stream 1001 is a user log stream of the OceanBase tenant.

  In addition, each log stream backup contains four subdirectories named retry, turn, meta_info, sys_data, minor_data, and major_data. The retry subdirectory records log stream-level retry data. The turn subdirectory records tenant-level retry data:

  • meta_info_xx: the directory that records log stream and tablet metadata.
  • sys_data_xx: the directory that records the data of system tablets in the log stream.
  • minor_data_xx: the directory that records the dump data of normal tablets.
  • major_data_xx: the directory that records the baseline data of normal tablets.

Log archive directory

For backup media that support the NFS, OSS, and COS protocols, the log archive directory and the file types saved in the directories are as follows.

log_archive_dest
    ├── check_file
    │   └── 1002_connect_file_20230111T193049.obbak // Connectivity check file
    ├── format.obbak                                // The format of the backup path
    ├── rounds                                      // The directory for storing the summary of log archives of all rounds. The directory name contains the ID of the log archive round.
    │   └── round_d1002r1_start.obarc               // The directory for storing the start placeholder of the log archive round. The directory name contains the ID of the log archive round.
    ├── pieces                                      // The directory for storing the summary of log archives of all pieces. The directory name contains the ID of the log archive piece.
    │   ├── piece_d1002r1p1_start_20230111T193049.obarc // The directory for storing the start placeholder of the log archive piece. The file name is in the format of piece_DESTID_ROUNDID_PIECEID_start_DATE.
    │   └── piece_d1002r1p1_end_20230111T193249.obarc   // The directory for storing the end placeholder of the log archive piece. The file name is in the format of piece_DESTID_ROUNDID_PIECEID_end_DATE
    └── piece_d1002r1p1                             // The directory for storing log archives. The directory name is in the format of piece_DESTID_ROUNDID_PIECEID.
        ├── piece_d1002r1p1_20230111T193049_20230111T193249.obarc // Records the continuous range of log archives in the directory.
        ├── checkpoint
        │   └── checkpoint.1673436649723677822.obarc   // Records the checkpoint_scn information. The file name is in the format of checkpoint.checkpoint_scn.
        │   └── checkpoint_info.0.obarc             // Records the metadata of the checkpoint.
        ├── single_piece_info.obarc                 // Records the metadata of the current piece.
        ├── tenant_archive_piece_infos.obarc        // Records the metadata of all frozen pieces in the current tenant.
        ├── file_info.obarc                         // The list of log stream files.
        ├── logstream_1                             // The directory for storing files of log stream 1. Log stream 1 records the system logs of the tenant.
        │   ├── file_info.obarc                    // The file list of log stream 1.
        │   ├── log
        │   │   └── 1.obarc                         // The archive files in log stream 1. The files are prefixed with the name of the log stream.
        │   └── schema_meta                         // The directory for storing the metadata of the data dictionary. This directory is generated only in log stream 1.
        │       └── 1677588501408765915.obarc
        └── logstream_1001                          // The directory for storing files of log stream 1001. Log stream 1001 records user logs of the tenant.
            ├── file_info.obarc                      // The file list of log stream 1001.
            └── log
                └── 1.obarc                          // The archive file in log stream 1001.

In the preceding log archive directory, the top-level directories and files store the following information:

• format.obbak: records the metadata of the backup path, including the tenant that uses the path.

• check_file: the directory for performing connectivity checks on the log archive directory.

• rounds: the directory for storing the summary of log archives of all rounds. The directory name contains the ID of the log archive round.

• pieces: the directory for storing the summary of log archives of all pieces. The directory name contains the ID of the log archive piece.

• piece_d1002r1p1: the directory for storing log archives. The directory name is in the format of piece_DESTID_ROUNDID_PIECEID. In the name, DESTID indicates the ID of the log_archive_dest; ROUNDID indicates the ID of the log archive round, which is a monotonically increasing integer; PIECEID indicates the ID of the log archive piece, which is also a monotonically increasing integer.

  A log archive piece directory contains the following data:

  • piece_d1002r1p1_20230111T193049_20230111T193249.obarc: this file displays the ID, start time, and end time of the piece and is used only for display.

  • checkpoint: the directory for recording the archive points of active pieces. The obArchiveScheduler module updates the archive points in the directory periodically. The directory contains the following files:

    • checkpoint.1673436649723677822.obarc: the file name records the checkpoint_scn information of the piece. For example, 1673436649723677822 is the corresponding checkpoint_scn.

    • checkpoint_info.0.obarc: records the metadata of the checkpoint. The metadata includes tenant_id, dest_id, round_id, and piece_id. The metadata remains unchanged within a piece.

  • single_piece_info.obarc: records the metadata of the current piece.

  • tenant_archive_piece_infos.obarc: records the metadata of all frozen pieces in the current tenant.

  • file_info.obarc: the list of log stream files in the piece.

  • logstream_1: the directory for storing files of log stream 1. Log stream 1 records the system logs of the tenant.

  • logstream_1001: the directory for storing files of log stream 1001. Log stream 1001 records user logs of the tenant.

  Each log stream directory also contains the following files and directories:

  • file_info.obarc: the file list of the log stream.

  • log: the directory for storing all archive files in the current log stream. The file names are the same as those in the source cluster.

  • schema_meta: the directory for storing the metadata of the data dictionary. This directory is generated only in the system log stream.

For backup media that support the S3 protocol and protocols compatible with S3, the directory structure of log archives is different from that for backup media that support the NFS, OSS, and COS protocols. A single log archive file consists of multiple small files and corresponding metadata files. The directory structure is as follows.

log_archive_dest
    ├── ......
    └── piece_d1002r1p1                             // Piece directory. The directory name is in the format of `piece_DESTID_ROUNDID_PIECEID`.
        ├── ......                         					// The list of all log stream files.
        ├── logstream_1                             // The directory for storing files of log stream 1. Log stream 1 records the system logs of the tenant.
        │   ├── file_info.obarc                    // The file list of log stream 1.
        │   ├── log
        │   │   └── 1.obarc                         // The archive files in log stream 1. The files are prefixed with the name of the log stream.
        |		|       └── @APD_PART@0-32472973.obarc  // The actual data in the archive file. It records the data of bytes 0 to 32472973 of the log files.
        |		|		    └── ......
        |		|		    └── @APD_PART@FORMAT_META.obarc // The format of the archive file.
        |		|		    └── @APD_PART@SEAL_META.obarc   // The metadata of the archive file.
        │   └── schema_meta                         // The directory for storing the metadata of the data dictionary. This directory is generated only in log stream 1.
        │       └── 1677588501408765915.obarc
        └── logstream_1001                          // The directory for storing files of log stream 1001. Log stream 1001 records user logs of the tenant.
            ├── file_info.obarc                      // The file list of log stream 1001.
            └── log
                └── 1.obarc                          // The archive file in log stream 1001.

In the preceding log archive directory, 1.obarc indicates a single log archive file, which is prefixed with the same name as the file. A single log archive file contains the following data:

• @APD_PART@FORMAT_META.obarc: when the format_meta file is written to the directory for the first time, the format_meta file records the format of the log archive file.

• @APD_PART@0-32472973.obarc: the actual data in the log archive file is written to the file named with the prefix, and the start and end offsets of each write are recorded in the file name.

• @APD_PART@SEAL_META.obarc: after the last data write to the log archive file, the seal_meta file is generated in the directory to record the metadata of the log archive file.

Differences from V3.x and V2.x

Log archiving

Data backup

Physical restore

References

For more information about physical backup and restore, see Backup and restore.