Overview

Backup and restore is a core component of the high availability feature of OceanBase Database. It ensures data security by preventing data loss due to storage media damage and user errors. If data is lost due to storage media damage or user errors, you can restore the data.

Overview

The backup and restore module of OceanBase Database provides backup, restore, and cleanup capabilities.

OceanBase Database supports physical backup at the tenant level. Physical backup consists of data backup and log archiving. Therefore, physical backup is a combination of data backup and log archiving. Here, the tenant refers to the user's User tenant. Physical backup is not supported for the sys tenant and Meta tenant.

Data backup refers to the capability of backing up data. This capability is divided into full backup and incremental backup:

• Full backup refers to backing up all macroblocks.

• Full backup refers to backing up all macroblocks.

• Incremental backup refers to backing up macroblocks that have been added or modified since the last backup.

The data that is backed up in data backup includes the following:

• Tenant-related information, including the tenant name, cluster name, timezone, replica distribution (locality), and compatibility mode (MySQL or Oracle) of the tenant.

• Data of all user tables

  Note

  Data backup backs up system variables and tenant-level configurations, but does not back up cluster-level configurations or private system table data.

Log archiving refers to the automatic archiving of log data. OBServer nodes periodically archive log data to the specified backup path. This action is fully automatic and does not require external triggering.

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

1. Physical restore supports tenant-level restore and table-level restore.

   • Tenant-level restore: Tenant-level restore is the process of rebuilding a new tenant based on the backup data of an existing tenant. Tenant-level restore ensures global consistency across tables and partitions.

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

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

   Notice

   Tenants restored by using quick restore cannot be manually initiated for major compactions, cannot be backed up, and cannot be switched to or failed over to the primary database. They can only exist as standby databases.

   • Full restore: Full restore refers to restoring macroblock data and incremental logs. After all data is restored from the backup medium to the local environment, the restored tenant can provide services. The full restore process includes the restore and recover processes for tenant system tables and user tables. Restore refers to restoring the baseline data required for the restore to the OBServer nodes of the target tenant. Recover refers to restoring the logs corresponding to the baseline to the corresponding OBServer nodes.

   • Quick restore: Quick restore refers to providing services to users without restoring macroblock data. This can reduce the restore waiting time and lower the user's usage cost.

3. Choose a restore point for your physical restore.

4. Choose a restore point for your physical restore.

   • Complete restore: No restore timestamp is specified.

   • Complete restore: No restore timestamp is specified.

   • Incomplete restore by specifying an SCN or timestamp: In this case, the SCN is the precise version number in OceanBase Database. In Oracle mode, the timestamp is precise to the nanosecond, with no loss of precision. In MySQL mode, the timestamp is precise to the microsecond, with loss of precision after the microsecond.

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

Backup media requirements

Backup media requirements

OceanBase Database of the current version supports backup media such as Alibaba Cloud OSS, NFS, Azure Blob (from V4.3.5 BP3 in V4.3.5), AWS S3, and object storage services compatible with the S3 protocol (such as Huawei OBS, Google GCS, and Tencent Cloud COS). Some backup media need to meet certain requirements before they can be used.

SDK version requirements

The following table describes the mapping between the object storage SDK versions and the observer versions.

Interface requirements

Interface requirements

• Alibaba Cloud OSS:

• Alibaba Cloud OSS:

  • The following table describes the interfaces supported by Alibaba Cloud OSS.

    Interface name	Description
    PutObject	Uploads an object.
    DeleteObject	Deletes an object.
    DeleteObjects	Deletes multiple objects.
    GetObject	Retrieves an object.
    ListObjects	Lists all objects in the bucket (strong consistency is required).
    HeadObject	Retrieves the metadata of an object.
    AppendObject	Uploads an object in append mode.
    PutObjectTagging (optional)	Sets or updates the tags of an object.
    GetObjectTagging (optional)	Retrieves the tags of an object.
    InitiateMultipartUpload	Initializes a multipart upload.
    UploadPart	Uploads a part.
    CompleteMultipartUpload	Combines the uploaded parts into an object.
    AbortMultipartUpload	Aborts a multipart upload and deletes the uploaded parts.
    ListMultipartUploads	Lists the multipart uploads that have been initialized but not completed or terminated.
    ListParts	Lists the uploaded parts in an upload task.

  • Only V1 signature algorithm is supported.

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

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

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

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

  1. The following table describes the S3 APIs that must be supported.

     Interface name	Description
     PutObject	Uploads an object.
     DeleteObject	Deletes an object.
     DeleteObjects	Deletes multiple objects.
     GetObject	Downloads an object.
     ListObjects	Lists all objects in the path.
     HeadObject	Retrieves the metadata of an object.
     PutObjectTagging (optional)	Sets the tags of an object.
     GetObjectTagging (optional)	Retrieves the tags of an object.
     CreateMultipartUpload	Initializes a multipart upload.
     UploadPart	Uploads a part.
     CompleteMultipartUpload	Combines the uploaded parts into an object.
     AbortMultipartUpload	Aborts a multipart upload and deletes the uploaded parts.
     ListMultipartUploads	Lists the uploaded parts.
     ListParts	Lists the uploaded parts in an upload task.

  2. The object access URL must support the virtual-hosted-style. For more information about virtual-hosted-style requests, see AWS S3 documentation.

Before you select a backup media, you can run the test_io_device command in the ob_admin tool to verify whether the I/O interface and I/O permissions provided by the backup media meet the requirements for backup and restore. You can also run the io_adapter_benchmark command in the ob_admin tool to view the read and write performance from an OBServer node to the backup media, which serves as a reference for backup performance. For more information about the test_io_device and io_adapter_benchmark commands, see test_io_device and io_adapter_benchmark.

Directory Structure

Data backup directory

Data backup directory

The data backup feature creates directories at the backup destination, and the types of files saved in each directory are as follows:

data_backup_dest
├── format.obbak                                            // The format information of the backup destination.
├── check_file
│   └── 1002_connect_file_20230111T193020.obbak             // The connectivity check file.
├── backup_sets                                             // The directory that contains all the data backup sets.
│   ├── backup_set_1_full_end_success_20230111T193420.obbak // The placeholder indicating the end of a full backup.
│   ├── backup_set_1_full_start.obbak                       // The placeholder indicating the start of a full backup.
│   ├── backup_set_2_inc_start.obbak                        // The placeholder indicating the start of an incremental backup.
│   └── backup_set_2_inc_end_success_20230111T194420.obbak  // The placeholder indicating the end of an incremental backup.
└── backup_set_1_full                                        // The full backup set. Files ending with full indicate full backups, and files ending with inc indicate incremental backups.
    ├── backup_set_1_full_20230111T193330_20230111T193420.obbak // The placeholder indicating 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 full backup set information of the current tenant.
    ├── infos
    │   ├── table_list                                      // The file containing the names of the tables in the full backup.
    │   │   ├── table_list.1702352553000000000.1.obbak      // The file containing the names of the tables in the full backup.
    │   │   ├── table_list.1702352553000000000.2.obbak     // The file containing the names of the tables in the full backup.
    │   │   └── table_list_meta_info.1702352553000000000.obbak  // The metadata file of the table names.
    │   ├── major_data_info_turn_1                           // The tenant-level backup files in major turn 1.
    │   │   ├── tablet_log_stream_info.obbak                 // The mapping file between tablets and log streams.
    │   │   ├── tenant_major_data_macro_range_index.0.obbak  // The macro block index of the major data.
    │   │   ├── tenant_major_data_meta_index.0.obbak         // The meta index of the major data.
    │   │   └── tenant_major_data_sec_meta_index.0.obbak     // The mapping file between the logical IDs and physical IDs of the major data.
    │   ├── minor_data_info_turn_1                           // The tenant-level backup files in minor turn 1.
    │   │   ├── tablet_log_stream_info.obbak                 // The mapping file between tablets and log streams.
    │   │   ├── tenant_minor_data_macro_range_index.0.obbak  // The macro block index of the minor data.
    │   │   ├── tenant_minor_data_meta_index.0.obbak         // The meta index of the minor data.
    │   │   └── tenant_minor_data_sec_meta_index.0.obbak     // The mapping file between the logical IDs and physical IDs of the minor data.
    │   ├── diagnose_info.obbak                              // The diagnostic information file of the backup set.
    |   ├── tenant_parameter.obbak                           // The tenant-level configuration information that is not the default settings.
    │   ├── locality_info.obbak                              // The locality information of the tenant to which the current backup set belongs. The locality information includes the resource configuration information and replica distribution information of the tenant.
    │   └── meta_info                                        // The log stream metadata file at the tenant level. The file contains the metadata of all log streams.
    │       ├── ls_attr_info.1.obbak                         // The snapshot of the log stream list at the time of backup.
    │       └── ls_meta_infos.obbak                          // The collection of the metadata of all log streams.
    ├── logstream_1                                          // The log stream with ID 1.
    │   ├── major_data_turn_1_retry_0                        // The baseline data in turn 1, retry 0.
    │   │   ├── macro_block_data.0.obbak                     // A data file with a size of 512 MB to 4 GB.
    │   │   ├── macro_range_index.obbak                      // The macro index.
    │   │   ├── meta_index.obbak                             // The meta index.
    │   │   └── sec_meta_index.obbak                         // The mapping file between the logical IDs and physical IDs.
    │   ├── meta_info_turn_1_retry_0                         // The log stream metadata file in turn 1, retry 0.
    │   │   ├── ls_meta_info.obbak                           // The log stream metadata.
    │   │   └── tablet_info.1.obbak                          // The list of log stream tablet metadata.
    │   ├── minor_data_turn_1_retry_0                        // The minor data in 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 in turn 1, retry 0.
    │       ├── macro_block_data.0.obbak
    │       ├── macro_range_index.obbak
    │       ├── meta_index.obbak
    │       └── sec_meta_index.obbak
    └── logstream_1001                                       // The log stream with ID 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

In the data backup directory, the top-level directory contains the following three types of data:

• format.obbak: stores the metadata of the backup path.

• check_file: stores the connectivity check result of the user data backup directory.

• backup_sets: stores the summary of all data backup sets.

• backup_set_1_full: stores the data backup set. The suffix of the directory name is full for a full backup and inc for an incremental backup. A backup set is generated for each data backup. After a data backup is completed, the backup set will no longer be modified.

  In a data backup set, the following data is stored:

  • backup_set_1_full_20230111T193330_20230111T193420.obbak: stores the ID, start time, and end time of the current backup set. This file is only for information display.

  • single_backup_set_info.obbak: stores the metadata of the current backup set, including the backup point and the logs that are dependent on the backup.

  • tenant_backup_set_infos.obbak: stores the metadata of all existing backup sets of the current tenant.

  • infos: stores the metadata of the data backup set.

  • logstream_1: stores all data of log stream 1. Log stream 1 is the system log stream of the OceanBase Database tenant.

  • logstream_1001: stores all data of log stream 1001. Log streams greater than 1000 are the user log streams of the OceanBase Database tenant.

  In addition, each log stream backup contains four directories. A directory with the retry suffix indicates log stream-level retries, and a directory with the turn suffix indicates tenant-level retries:

  • meta_info_xx: stores the metadata of the log stream (LS) and tablet.
  • sys_data_xx: stores the data of the internal system tablet of the LS.
  • minor_data_xx: stores the minor compaction data of the tablet.
  • major_data_xx: stores the major compaction data of the tablet.

Backup directory for cluster-level parameters

Every time a backup of cluster-level parameters is initiated, a backup file is generated in the specified directory. The directory structure is as follows:

cluster_parameters_backup_dest
├── cluster_parameter.20240710T103610.obbak # Information about non-default cluster-level parameters, with the file naming format: `cluster_parameter.[timestamp]`
└── cluster_parameter.20241018T140609.obbak

Log archive directory

Log archive directory

For backup media such as NFS, OSS, and Azure Blob Storage, the log archive directory and the types of files stored in each directory are described as follows:

log_archive_dest
    ├── check_file
    │   └── 1002_connect_file_20230111T193049.obbak // Connectivity check file
    ├── format.obbak                                // Formatted information of the backup path
    ├── rounds                                      // Placeholder directory for Rounds
    │   └── round_d1002r1_start.obarc               // Placeholder for the start of a Round
    ├── pieces                                      // Placeholder directory for Pieces
    │   ├── piece_d1002r1p1_start_20230111T193049.obarc // Placeholder for the start of a Piece, named in the format piece_DESTID_ROUNDID_PIECEID_start_DATE
    │   └── piece_d1002r1p1_end_20230111T193249.obarc   // Placeholder for the end of a Piece, named in the format piece_DESTID_ROUNDID_PIECEID_end_DATE
    └── piece_d1002r1p1                             // Directory for a Piece, named in the format piece_DESTID_ROUNDID_PIECEID
        ├── piece_d1002r1p1_20230111T193049_20230111T193249.obarc // Records the continuous interval of the Piece
        ├── checkpoint
        │   └── checkpoint.1673436649723677822.obarc   // Records checkpoint_scn information, with the file name in the format checkpoint.checkpoint_scn
        │   └── checkpoint_info.0.obarc             // Records the metadata of the checkpoint
        ├── single_piece_info.obarc                 // Records the metadata of the Piece
        ├── tenant_archive_piece_infos.obarc        // Records the metadata of all frozen Pieces before the current Piece
        ├── file_info.obarc                         // List of all log stream files
        ├── logstream_1                             // Log stream 1
        │   ├── file_info.obarc                    // List of files in log stream 1
        │   ├── log
        │   │   └── 1.obarc                         // Archive files under log stream 1
        │   └── schema_meta                         // Records the metadata of the data dictionary, generated only for log stream 1
        │       └── 1677588501408765915.obarc
        └── logstream_1001                          // Log stream 1001
            ├── file_info.obarc                      // List of files in log stream 1001
            └── log
                └── 1.obarc                          // Archive files under log stream 1001

In the log archive directory, the top-level directory contains the following three types of data:

• format.obbak: Records the metadata of the archive path, including information such as the tenant using the path.

• check_file: Used for connectivity check of the user log archive directory.

• rounds: A list of all Rounds in the log archive, recording the list of all Rounds.

• pieces: A list of all Pieces in the log archive, recording the list of all Pieces.

• piece_d1002r1p1: The directory for a Piece in the log archive, named in the format piece_DESTID_ROUNDID_PIECEID. Here, DESTID refers to the id corresponding to log_archive_dest; ROUNDID refers to the id of the log archive Round, which is a monotonically increasing integer; and PIECEID refers to the id of the log archive Piece, which is also a monotonically increasing integer.

  The directory for a log archive Piece contains the following data:

  • piece_d1002r1p1_20230111T193049_20230111T193249.obarc: This file displays the id, start time, and end time of the current Piece and is used only for information display.

  • checkpoint: The directory for recording the archive point of the active Piece. The ObArchiveScheduler module regularly updates the archive point information in this directory. Specifically:

    • checkpoint.1673436649723677822.obarc: This file records the checkpoint_scn information of the Piece. 1673436649723677822 is the corresponding checkpoint_scn.

    • checkpoint_info.0.obarc: This file records the metadata of the checkpoint of the active Piece, including information such as tenant_id, dest_id, round_id, and piece_id. The metadata remains unchanged within a Piece.

  • single_piece_info.obarc: This file records the metadata of the current Piece.

  • tenant_archive_piece_infos.obarc: This file records the metadata of all frozen Pieces in the current tenant.

  • file_info.obarc: This file records the list of log streams in the Piece.

  • logstream_1: This directory records the log files of log stream 1, which is the system log stream of the OceanBase Database tenant.

  • logstream_1001: This directory records the log files of log stream 1001, which is a user log stream of the OceanBase Database tenant.

  In addition, each log stream backup contains three types of data:

  • file_info.obarc: This file records the list of files in the log stream.

  • log: This directory stores all archive files of the current log stream, with file names consistent with those of the source cluster.

  • schema_meta: This directory records the metadata of the data dictionary. It exists only for the system log stream and not for user log streams.

For backup media such as AWS S3 and those compatible with the S3 protocol, the directory structure for log archiving differs from that of OSS, NFS, and COS. Each archive file is composed of multiple small files and corresponding metadata files. The specific directory structure is as follows:

log_archive_dest
    ├── ......
    └── piece_d1002r1p1                             // Piece directory. The directory name is in the piece_DESTID_ROUNDID_PIECEID format.
        ├── ......                         					// All log stream files
        ├── logstream_1                             // Log stream 1
        │   ├── file_info.obarc                    // Log stream 1 file list
        │   ├── log
        │   │   └── 1.obarc                         // Log stream 1 archive file. The archive file is identified by a prefix.
        |		|       └── @APD_PART@0-32472973.obarc  // Actual data in the archive file. The data records the content of the log file from the 0th to 32472973rd byte.
        |		|		    └── ......
        |		|		    └── @APD_PART@FORMAT_META.obarc // Archive file format
        |		|		    └── @APD_PART@SEAL_META.obarc   // Archive file metadata
        │   └── schema_meta                         // Metadata of the data dictionary. This file is generated only for log stream 1.
        │       └── 1677588501408765915.obarc
        └── logstream_1001                          // Log stream 1001
            ├── file_info.obarc                      // Log stream 1001 file list
            └── log
                └── 1.obarc                          // Archive file of log stream 1001

In the preceding log archive directory, 1.obarc is an archive file. Each archive file is identified by a prefix, and the prefix name is the same as the archive file name. The archive file contains the following three types of data:

• @APD_PART@FORMAT_META.obarc: When you write data to an archive file for the first time, the system writes the format_meta file to this directory to record the archive file format.

• @APD_PART@0-32472973.obarc: The actual data in the archive file is stored in a file with the prefix name. The file name records the starting and ending offset of the data written to the file.

• @APD_PART@SEAL_META.obarc: After you write data to an archive file for the last time, the system generates the seal_meta file in this directory to record the archive file metadata.

Differences between V3.x/V2.x features and V4.0 features

Log archiving

Data backup

Physical restore

Partner certification

For a backup and restore partner that has been certified with OceanBase Database, see Industry partners.

On the Select Partner Type tab of the Industry partners page, select Data Integration and Backup > Backup & Recovery. You can view the list of backup and restore partners that have been certified with OceanBase Database, the versions of the partners, and the validity periods of the certificates.

References

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