BR Design Principles

This document describes the design principles of Backup & Restore (BR), including its architecture and backup files.

BR architecture

BR sends a backup or restoration command to each TiKV node. After receiving the command, TiKV performs the corresponding backup or restoration operation.

Each TiKV node has a path in which the backup files generated in the backup operation are stored and from which the stored backup files are read during the restoration.

Backup files

This section describes the design of backup files generated by BR.

Types of backup files

BR can generate the following types of backup files:

• SST file: stores the data that the TiKV node backs up.
• backupmeta file: stores the metadata of a backup operation, including the number, the key range, the size, and the Hash (sha256) value of the backup files.
• backup.lock file: prevents multiple backup operations from storing data to the same directory.

Naming format of SST files

SST files are named in the format of storeID_regionID_regionEpoch_keyHash_cf. The fields in the format are explained as follows:

• storeID is the TiKV node ID.
• regionID is the Region ID.
• regionEpoch is the version number of a Region.
• keyHash is the Hash (sha256) value of the startKey of a range, which ensures the uniqueness of a key.
• cf indicates the Column Family of RocksDB (default or write by default).

Storage format of SST files

• For details about the storage format of SST files, see Rocksdb BlockBasedTable Format.
• For details about the encoding format of backup data in SST files, see Mapping of table data to Key-Value.