Skip to main content
Checkpoint provides APIs for creating openable snapshots of a RocksDB database at a specific point in time. Checkpoints can be used for backups, replication, or creating read-only database copies.

Creating a Checkpoint Object

Create

Creates a Checkpoint object for a database.
DB*
The database to create checkpoints from.
Checkpoint**
Output parameter for the created Checkpoint object.
Status
Returns OK on success.

Creating a Checkpoint

CreateCheckpoint

Builds an openable snapshot of the database.
const std::string&
Absolute path where the checkpoint will be created. Directory must not exist.
uint64_t
If total log file size >= this value, a flush is triggered for all column families. 0 (default) always triggers flush. Archived logs are not included in the calculation.
uint64_t*
Optional output parameter set to a sequence number guaranteed to be in the checkpoint.
Status
Returns OK on success, NotSupported if db_paths or cf_paths use multiple directories.

How Checkpoints Work

  1. SST and Blob Files: Hard linked if the checkpoint directory is on the same filesystem, copied otherwise
  2. Other Files: MANIFEST and other required files are always copied
  3. Consistency: Checkpoint represents a consistent point-in-time snapshot

Exporting Column Families

ExportColumnFamily

Exports all live SST files of a specified column family.
ColumnFamilyHandle*
Column family to export.
const std::string&
Directory where SST files will be exported. Must not exist.
ExportImportFilesMetaData**
Output parameter with information about exported SST files.
Status
Returns OK on success.

Export Behavior

  • SST files are hard linked when export_dir is on the same partition as the database
  • SST files are copied when on different partitions
  • Always triggers a flush
  • export_dir is created by the API

Example: Creating a Checkpoint

Example: Conditional Flush

Example: Exporting a Column Family

Use Cases

Database Backups

Checkpoints provide a fast way to create consistent backups:

Read Replicas

Create read-only copies for load distribution:

Testing and Development

Quickly create database copies for testing:

Performance Considerations

  • Hard links are nearly instantaneous
  • Copies can be slow for large databases
  • Ensure checkpoint directory is on the same filesystem for best performance

Flush Behavior

  • Setting log_size_for_flush > 0 can reduce checkpoint time
  • For most up-to-date snapshot, use log_size_for_flush = 0
  • Two-phase commit (2PC) always triggers flush regardless of setting

Space Efficiency

  • Hard-linked checkpoints use minimal additional disk space
  • Deleting the original database doesn’t affect hard-linked checkpoints
  • Space is only freed when all hard links are deleted

Limitations

Multiple Directories Not Supported

Checkpoints don’t support databases using db_paths or cf_paths with multiple directories (without WALs). The API will return NotSupported.

Sequence Number Guarantees

The sequence_number_ptr is set to a sequence number guaranteed to be part of the checkpoint, but not necessarily the latest sequence number.

Comparison with BackupEngine

Use Checkpoint for:
  • Fast point-in-time snapshots
  • Read replicas
  • Same-filesystem operations
Use BackupEngine for:
  • Incremental backups
  • Remote backups
  • Backup verification
  • Production backup workflows

See Also