OceanBase logo

OceanBase

A unified distributed database ready for your transactional, analytical, and AI workloads.

DEPLOY YOUR WAY

OceanBase Cloud

The best way to deploy and scale OceanBase

OceanBase Enterprise

Run and manage OceanBase on your infra

TRY OPEN SOURCE

OceanBase Community Edition

The free, open-source distributed database

OceanBase seekdb

Open source AI native search database

Customer Stories

Real-world success stories from enterprises across diverse industries.

View All
BY USE CASES

Mission-Critical Transactions

Global & Multicloud Application

Elastic Scaling for Peak Traffic

Real-time Analytics

Active Geo-redundancy

Database Consolidation

Resources

Comprehensive knowledge hub for OceanBase.

Blog

Live Demos

Training & Certification

Documentation

Official technical guides, tutorials, API references, and manuals for all OceanBase products.

View All
PRODUCTS

OceanBase Cloud

OceanBase Database

Tools

Connectors and Middleware

QUICK START

OceanBase Cloud

OceanBase Database

BEST PRACTICES

Practical guides for utilizing OceanBase more effectively and conveniently

Company

Learn more about OceanBase – our company, partnerships, and trust and security initiatives.

About OceanBase

Partner

Trust Center

Contact Us

International - English
中国站 - 简体中文
日本 - 日本語
Sign In
Start on Cloud

A unified distributed database ready for your transactional, analytical, and AI workloads.

DEPLOY YOUR WAY

OceanBase Cloud

The best way to deploy and scale OceanBase

OceanBase Enterprise

Run and manage OceanBase on your infra

TRY OPEN SOURCE

OceanBase Community Edition

The free, open-source distributed database

OceanBase seekdb

Open source AI native search database

Customer Stories

Real-world success stories from enterprises across diverse industries.

View All
BY USE CASES

Mission-Critical Transactions

Global & Multicloud Application

Elastic Scaling for Peak Traffic

Real-time Analytics

Active Geo-redundancy

Database Consolidation

Comprehensive knowledge hub for OceanBase.

Blog

Live Demos

Training & Certification

Documentation

Official technical guides, tutorials, API references, and manuals for all OceanBase products.

View All
PRODUCTS
OceanBase CloudOceanBase Database
ToolsConnectors and Middleware
QUICK START
OceanBase CloudOceanBase Database
BEST PRACTICES

Practical guides for utilizing OceanBase more effectively and conveniently

Learn more about OceanBase – our company, partnerships, and trust and security initiatives.

About OceanBase

Partner

Trust Center

Contact Us

Start on Cloud
编组
All Products
    • Databases
    • iconOceanBase Database
    • iconOceanBase Cloud
    • iconOceanBase Tugraph
    • iconInteractive Tutorials
    • iconOceanBase Best Practices
    • Tools
    • iconOceanBase Cloud Platform
    • iconOceanBase Migration Service
    • iconOceanBase Developer Center
    • iconOceanBase Migration Assessment
    • iconOceanBase Admin Tool
    • iconOceanBase Loader and Dumper
    • iconOceanBase Deployer
    • iconKubernetes operator for OceanBase
    • iconOceanBase Diagnostic Tool
    • iconOceanBase Binlog Service
    • Connectors and Middleware
    • iconOceanBase Database Proxy
    • iconEmbedded SQL in C for OceanBase
    • iconOceanBase Call Interface
    • iconOceanBase Connector/C
    • iconOceanBase Connector/J
    • iconOceanBase Connector/ODBC
    • iconOceanBase Connector/NET
icon

OceanBase Database

SQL - V4.3.0

    Download PDF

    OceanBase logo

    The Unified Distributed Database for the AI Era.

    Follow Us
    Products
    OceanBase CloudOceanBase EnterpriseOceanBase Community EditionOceanBase seekdb
    Resources
    DocsBlogLive DemosTraining & Certification
    Company
    About OceanBaseTrust CenterLegalPartnerContact Us
    Follow Us

    © OceanBase 2026. All rights reserved

    Cloud Service AgreementPrivacy PolicySecurity
    Contact Us
    Document Feedback
    1. Documentation Center
    2. OceanBase Database
    3. SQL
    4. V4.3.0
    iconOceanBase Database
    SQL - V 4.3.0
    SQL
    KV
    • V 4.4.2
    • V 4.3.5
    • V 4.3.3
    • V 4.3.1
    • V 4.3.0
    • V 4.2.5
    • V 4.2.2
    • V 4.2.1
    • V 4.2.0
    • V 4.1.0
    • V 4.0.0
    • V 3.1.4 and earlier

    Introduction to physical backup and restore

    Last Updated:2024-04-19 08:42:49  Updated
    share
    What is on this page
    Overview
    Directory structure
    Data backup directories
    Log archive directories
    Feature differences between OceanBase Database V4.x and V3.x/V2.2x
    Log archiving
    Data backup
    Physical restore
    References

    folded

    share

    The backup and restore module is a core component of OceanBase Database, designed to ensure high availability and protect data security. It effectively prevents misoperations and safeguards against damages to the storage media. In the event of data loss caused by misoperations or storage media damage, you can rely on the backup and restore module to recover and restore the lost data.

    Overview

    The current version of OceanBase Database supports Network File System (NFS), Alibaba Cloud Object Storage Service (OSS), Tencent Cloud Object Storage (COS), and Amazon Simple Storage Service (S3) as the backup media. It provides the backup, restore, and cleanup features.

    OceanBase Database supports tenant-level physical backup. Physical backup data includes backup data and archive log data. Therefore, physical backup consists of log archiving and data backup. The tenants mentioned in this topic are user tenants. Physical backup is not supported for sys tenants or meta tenants.

    Data backup refers to the backup of data, and includes full backup and incremental backup:

    • Full backup refers to the backup of all macroblocks.

    • Incremental backup refers to the backup of macroblocks that are added or modified since the last backup.

    Notice

    To perform physical backup, you must first enable log archiving.

    Data backup covers the following data:

    • Tenant information, including the tenant name, cluster name, time zone, locality, and tenant mode (MySQL or Oracle)

    • All user table data

    Note

    Data backup backs up system variables, but does not back up tenant parameters or private system table data.

    Log archiving refers to the automatic backup of log data. OBServer nodes regularly archive log data to the specified backup path without manual triggering.

    OceanBase Database supports tenant-level and table-level restore. Tenant-level restore is the process of rebuilding a new tenant based on existing backup data. The tenant-level restore process includes the restore and recovery of tenant system tables and user tables. Restore returns the required baseline data to the OBServer node of the destination tenant. Recovery returns the logs corresponding to the baseline data to the OBServer node.

    Table-level restore is the process of restoring a specified table from backup data to an existing tenant, which can be the source tenant, another tenant in the same cluster, or a tenant in a different cluster.

    Directory structure

    Data backup directories

    The directories created by the backup feature in the backup destination and types of files in the directories are as follows:

    data_backup_dest
    ├── format.obbak                                            // The format information of the backup path.
    ├── check_file
    │   └── 1002_connect_file_20230111T193020.obbak             // The connectivity check file.
    ├── backup_sets                                             // The summary directory of data backup lists, which contains all data backup sets.
    │   ├── backup_set_1_full_end_success_20230111T193420.obbak // The end placeholder for a full backup.
    │   ├── backup_set_1_full_start.obbak                       // The start placeholder for a full backup.
    │   ├── backup_set_2_inc_start.obbak                        // The start placeholder for an incremental backup.
    │   └── backup_set_2_inc_end_success_20230111T194420.obbak  // The end placeholder for an incremental backup.
    └── backup_set_1_full                                        // A full backup set. A directory whose name ends with "full" is a full backup set, and a directory whose name ends with "inc" is an incremental backup set.
        ├── backup_set_1_full_20230111T193330_20230111T193420.obbak //The placeholder that represents the start and end time of a 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
        │   ├── major_data_info_turn_1                           // The tenant-level baseline data backup file when the turn ID is 1.
        │   │   ├── tablet_log_stream_info.obbak                 // The file describing the mapping between tablets and log streams.
        │   │   ├── tenant_major_data_macro_range_index.0.obbak  // The macroblock index in the baseline data backup file.
        │   │   ├── tenant_major_data_meta_index.0.obbak         // The meta index in the baseline data backup file.
        │   │   └── tenant_major_data_sec_meta_index.0.obbak     // The mapping between the logic ID and the physical ID of the meta index in the baseline data backup file.
        │   ├── minor_data_info_turn_1                           // The tenant-level minor-compacted backup file when the turn ID is 1.
        │   │   ├── tablet_log_stream_info.obbak                 // The file describing the mapping between tablets and log streams.
        │   │   ├── tenant_minor_data_macro_range_index.0.obbak  // The macroblock index in the minor-compacted backup file.
        │   │   ├── tenant_minor_data_meta_index.0.obbak         // The meta index in the minor-compacted backup file.
        │   │   └── tenant_minor_data_sec_meta_index.0.obbak     // The mapping between the logic ID and the physical ID of the meta index in the minor-compacted backup file.
        │   ├── diagnose_info.obbak                              // The diagnosis information file of the backup set.
        │   ├── locality_info.obbak                              // The tenant locality information of the current backup set.
        │   └── meta_info                                        // The tenant-level log stream metadata file, which contains the metadata of all log streams.
        │       ├── ls_attr_info.1.obbak                         // The snapshot of log streams during backup.
        │       └── ls_meta_infos.obbak                          //  The collection of metadata of all log streams.
        ├── logstream_1                                          // Log stream 1.
        │   ├── major_data_turn_1_retry_0                        // The baseline data when the turn ID is 1 and retry ID is 0.
        │   │   ├── macro_block_data.0.obbak                     // A data file sized between 512 MB and 4 GB.
        │   │   ├── macro_range_index.obbak                      // The macro index.
        │   │   ├── meta_index.obbak                             // The meta index.
        │   │   └── sec_meta_index.obbak                         // The file describing the mapping between the logical ID and the physical ID.
        │   ├── meta_info_turn_1_retry_0                         // The metadata of log streams when the turn ID is 1 and retry ID is 0.
        │   │   ├── ls_meta_info.obbak                           // The log stream metadata.
        │   │   └── tablet_info.1.obbak                          // The metadata of log stream tablets.
        │   ├── minor_data_turn_1_retry_0                        // The minor-compacted data when the turn ID is 1 and retry ID is 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 when the turn ID is 1 and retry ID is 0.
        │       ├── macro_block_data.0.obbak
        │       ├── macro_range_index.obbak
        │       ├── meta_index.obbak
        │       └── sec_meta_index.obbak
        └── logstream_1001                                       // Log stream 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
    

    Top-level data backup directories contain the following types of data:

    • format.obbak: This directory is used for recording the metadata of the backup path.

    • check_file: This directory is used for checking the connectivity to the root backup directory.

    • backup_sets: The summary directory that contains all data backup sets.

    • backup_set_1_full: This directory represents a data backup set, where a directory whose name ends with full is a full backup set, and a directory whose name ends with inc is an incremental backup set. Each data backup generates a corresponding backup set, and the backup set will not be modified after the data backup is completed.

      A data backup set mainly includes the following data:

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

      • single_backup_set_info.obbak: This file records the metadata of the current backup set, including the backup timestamp, dependent logs, and other information.

      • tenant_backup_set_infos.obbak: This file records the metadata of all existing backup sets for the current tenant.

      • infos: This directory records the metadata of the data backup set.

      • logstream_1: This directory records all the data of log stream 1, which is the system log stream of an OceanBase tenant.

      • logstream_1001: This directory records all the data of log stream 1001, where log streams with numbers greater than 1000 are user log streams of an OceanBase tenant.

      In addition, each log stream backup has four types of directories. Directories whose names contain retry record information about log stream-level retries, and directories whose names contain turn record information about tenant-level retries.

      • meta_info_xx: This directory records log stream metadata and tablet metadata.
      • sys_data_xx: This directory records the data of internal system tablets in log streams.
      • minor_data_xx: This directory records the minor-compacted data of regular tablets.
      • major_data_xx: This directory records the baseline data of regular tablets.

    Log archive directories

    When you use NFS, OSS, or COS as the backup media, directories at the log archive destination and file types under each directory are as follows:

    log_archive_dest
        ├── check_file
        │   └── 1002_connect_file_20230111T193049.obbak // The connectivity check file.
        ├── format.obbak                                // The format information of the backup path.
        ├── rounds                                      // The round placeholder directory.
        │   └── round_d1002r1_start.obarc               // The round start placeholder.
        ├── pieces                                      // The piece placeholder directory.
        │   ├── piece_d1002r1p1_start_20230111T193049.obarc // The piece start placeholder, in the format of piece_DESTID_ROUNDID_PIECEID_start_DATE.
        │   └── piece_d1002r1p1_end_20230111T193249.obarc   // The piece end placeholder, in the format of piece_DESTID_ROUNDID_PIECEID_end_DATE.
        └── piece_d1002r1p1                             // The piece directory, named in the format of piece_DESTID_ROUNDID_PIECEID.       
            ├── piece_d1002r1p1_20230111T193049_20230111T193249.obarc // The contiguous interval of a piece.
            ├── checkpoint   
            │   └── checkpoint_info.0.obarc             // The archiving progress of a piece that is being archived.
            ├── single_piece_info.obarc                 // The metadata of the piece.
            ├── tenant_archive_piece_infos.obarc        // The metadata of all frozen pieces before this piece.        
            ├── file_info.obarc                         // The list of files in all log streams.
            ├── logstream_1                             // Log stream 1.
            │   ├── file_info.obarc                    // The list of files in log stream 1.
            │   ├── log
            │   │   └── 1.obarc                         // The archive files in log stream 1.  
            │   └── schema_meta                         // The metadata of data dictionaries. This file is generated only in log stream 1.
            │       └── 1677588501408765915.obarc                           
            └── logstream_1001                          // Log stream 1001.
                ├── file_info.obarc                      // The list of files in log stream 1001.
                └── log
                    └── 1.obarc                          // The archive file in log stream 1001.      
    

    Top-level log archive directories contain the following types of data:

    • format.obbak: This directory is used for recording the metadata of the archive path, including the tenant that uses the path.

    • check_file: This directory is used for checking the connectivity to the root archive directory.

    • rounds: The summary directory that records all rounds of log archiving.

    • pieces: The summary directory that records all pieces of log archiving.

    • piece_d1002r1p1: The piece directory for log archiving, which is named in the format of piece_DESTID_ROUNDID_PIECEID. Here, DESTID refers to the ID corresponding to log_archive_dest, ROUNDID refers to the ID of the log archiving round, which is a monotonically increasing integer, and PIECEID refers to the ID of the log archiving piece, which is also a monotonically increasing integer.

      A log archiving piece directory includes 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 display purposes.

      • checkpoint: This directory is used to record the archiving timestamps of active pieces. The ObArchiveScheduler module periodically updates the timestamp information in this directory.

      • 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 within the piece.

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

      • logstream_1001: This directory records the log files of log stream 1001, where log streams with numbers greater than 1000 are user log streams of an OceanBase tenant.

      Additionally, 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 contains all the archive files of the current log stream, with file names consistent with those in the source cluster.

      • schema_meta: This directory records the metadata of data dictionaries. It is only present in the system log stream but not in user log streams.

    When you use S3 as the backup media, the structure of log archive directories is different from that in other media. An archive file consists of multiple small files and the corresponding metadata file. The specific directory structure is as follows:

    Note

    Despite the difference in directory structure, backup files copied from S3 to other backup media across clouds can still be used for restore. For example, if you copy archived data from S3 to OSS, you can successfully restore data from the OSS path.

    log_archive_dest
        ├── ......                                   
        └── piece_d1002r1p1                             // The piece directory, named in the format of piece_DESTID_ROUNDID_PIECEID.       
            ├── ......                         					// The list of files in all log streams.
            ├── logstream_1                             // Log stream 1.
            │   ├── file_info.obarc                    // The list of files in log stream 1.
            │   ├── log
            │   │   └── 1.obarc                         // The archive file in log stream 1, which is identified by a prefix.  
            |		|       └── @APD_PART@0-32472973.obarc  // The actual data in the archive file, including the data from byte 0 to byte 32472973 in the log file.
            |		|		    └── ......  
            |		|		    └── @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 metadata of the data dictionary. This file is generated only in log stream 1.
            │       └── 1677588501408765915.obarc                           
            └── logstream_1001                          // Log stream 1001.
                ├── file_info.obarc                      // The list of files in log stream 1001.
                └── log
                    └── 1.obarc                          // The archive file in log stream 1001.      
    

    In the preceding directory structure, 1.obarc indicates a single archive file that is identified by a prefix. The prefix and the name of the archive file are the same. An archive file contains the following three types of data:

    • @APD_PART@FORMAT_META.obarc: When data is written to the archive file for the first time, the format_meta file is generated in this directory to record the format of the archive file.

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

    • @APD_PART@SEAL_META.obarc: After data is written to the archive file for the last time, the seal_meta file is generated in this directory to record the metadata in the archive file.

    Feature differences between OceanBase Database V4.x and V3.x/V2.2x

    Log archiving

    Feature V3.x/V2.2x V4.x
    Log archiving level Cluster level Tenant level
    Log archiving granularity Partition Log stream
    Required privileges Operations such as setting the archive path, enabling archiving, and viewing the archive progress can be performed only in the sys tenant. These operations can be performed either in the sys tenant or by an administrator user in a user tenant.
    Usage
    1. You can use the ALTER SYSTEM SET BACKUP_DEST statement to set the backup path for a cluster.
    2. You can use the ALTER SYSTEM SET BACKUP_DEST_OPTION statement to set the piece switching interval. By default, log splitting is disabled.
    You can use the ALTER SYSTEM SET LOG_ARCHIVE_DEST statement to set the archive path and the piece switching interval for a tenant. The default piece switching interval is 1d, which indicates one day.
    Log splitting Log splitting can be disabled and is disabled by default. Log splitting must be enabled, and the default piece switching interval is one day.
    Setting the lag of log archiving You can use the ALTER SYSTEM SET LOG_ARCHIVE_CHECKPOINT_INTERVAL statement. You can use the ALTER SYSTEM SET ARCHIVE_LAG_TARGET statement.
    Result returned by the ALTER SYSTEM ARCHIVELOG statement in the sys tenant If archiving is enabled for all tenants in the current cluster, archiving is automatically enabled for new tenants created later. If archiving is enabled for all tenants in the current cluster, archiving is not automatically enabled for new tenants created later.
    Compression of archive logs You can use the ALTER SYSTEM SET BACKUP_LOG_ARCHIVE_OPTION statement. Not supported
    Archive-related views The following three archive-related views are available:
    • CDB_OB_BACKUP_ARCHIVELOG
    • CDB_OB_BACKUP_ARCHIVELOG_SUMMARY
    • CDB_OB_BACKUP_PIECE_FILES
    The following eight archive-related views are available:
    • CDB_OB_ARCHIVELOG
    • DBA_OB_ARCHIVELOG
    • CDB_OB_ARCHIVELOG_SUMMARY
    • DBA_OB_ARCHIVELOG_SUMMARY
    • CDB_OB_ARCHIVE_DEST
    • DBA_OB_ARCHIVE_DEST
    • CDB_OB_ARCHIVELOG_PIECE_FILES
    • DBA_OB_ARCHIVELOG_PIECE_FILES
    Archive media SSD only HDD or SSD
    Number of archive files The number of archive files is proportional to the number of partitions. In a scenario with millions of partitions, a large number of small files are generated. The number of files is small and is irrelevant to the number of partitions.
    Standby tenant archiving Not supported Supported

    Data backup

    Feature V3.x/V2.2x V4.x
    Backup level Cluster level Tenant level
    Required privileges Operations such as setting a backup path, starting backup, and viewing the backup progress can be performed only in the sys tenant. These operations can be performed either in the sys tenant or by an administrator user in a user tenant.
    Setting a backup path You can use the ALTER SYSTEM SET BACKUP_DEST statement to set a backup path for a cluster. You can use the ALTER SYSTEM SET DATA_BACKUP_DEST statement to set a backup path for a tenant.
    Backing up data of a specified path You can use the ALTER SYSTEM BACKUP TENANT tenant_name_list TO backup_destination; statement to initiate the backup from the sys tenant. Not supported
    BACKUP PLUS ARCHIVELOG Not supported Supported
    Storage space expansion Snapshot points are retained during backup, which causes storage space expansion during backup. Snapshot points are not retained, thereby avoiding the storage space expansion issue.
    Standby tenant backup Not supported Supported
    Views The following five backup-related views are available:
    • CDB_OB_BACKUP_JOB_DETAILS
    • CDB_OB_BACKUP_SET_DETAILS
    • CDB_OB_BACKUP_SET_EXPIRED
    • CDB_OB_BACKUP_PROGRESS
    • CDB_OB_BACKUP_SET_FILES
    The following ten backup-related views are available:
    • CDB_OB_BACKUP_JOBS
    • DBA_OB_BACKUP_JOBS
    • CDB_OB_BACKUP_JOB_HISTORY
    • DBA_OB_BACKUP_JOB_HISTORY
    • CDB_OB_BACKUP_TASKS
    • DBA_OB_BACKUP_TASKS
    • CDB_OB_BACKUP_TASK_HISTORY
    • DBA_OB_BACKUP_TASK_HISTORY
    • CDB_OB_BACKUP_SET_FILES
    • DBA_OB_BACKUP_SET_FILES

    Physical restore

    Feature V3.x/V2.2x V4.x
    Data path The cluster-level backup path must be specified in the restore command. Both the data backup path and log archive path must be specified in the restore command.
    Restore concurrency settings Execute the ALTER SYSTEM SET RESTORE_CONCURRENCY statement to set the restore concurrency before you run the restore command. Specify concurrency in the restore command.
    Key management
    1. In internal mode, you do not need to set key information.
    2. In kms mode, you do not need to provide the key information if the original key management service (KMS) is available.
    1. The master key information must be backed up separately.
    2. You must specify the address of the master key during restore.
    Roles of restored tenants Primary tenants, namely primary databases Standby tenants, namely standby databases
    Upgrade Tenants are automatically upgraded during the restore process. You need to manually upgrade the tenants after they are restored.
    Allowlist-based restore (restore of specified tables in the tenant) Supported Not supported
    Table-level restore Not supported Supported in V4.2.1 and later
    Restore by using the ADD RESTORE SOURCE statement Supported Not supported

    References

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

    Previous topic

    Audit specified database objects
    Last

    Next topic

    Experience physical backup and restore with simplified deployment
    Next
    What is on this page
    Overview
    Directory structure
    Data backup directories
    Log archive directories
    Feature differences between OceanBase Database V4.x and V3.x/V2.2x
    Log archiving
    Data backup
    Physical restore
    References