Back up and restore data

InfluxDB 3 Core persists all data and metadata to object storage. Back up your data by copying object storage files in a specific order to ensure consistency and reliability.

Supported object storage

InfluxDB 3 supports the following object storage backends for data persistence:

• File system (local directory)
• AWS S3 and S3-compatible storage (MinIO)
• Azure Blob Storage
• Google Cloud Storage

File structure

Backup process

Recommended backup order:

1. Snapshots directory
2. Database (dbs) directory
3. WAL directory
4. Catalogs directory
5. Catalog checkpoint file

#!/bin/bash
NODE_ID="
NODE_ID
"
DATA_DIR="/path/to/data"
BACKUP_DIR="/backup/$(date +%Y%m%d-%H%M%S)"

mkdir -p "$BACKUP_DIR"

# Copy in recommended order
cp -r $DATA_DIR/${
NODE_ID}/snapshots "$BACKUP_DIR/"
cp -r $DATA_DIR/${
NODE_ID}/dbs "$BACKUP_DIR/"
cp -r $DATA_DIR/${
NODE_ID}/wal "$BACKUP_DIR/"
cp -r $DATA_DIR/${
NODE_ID}/catalogs "$BACKUP_DIR/"
cp $DATA_DIR/${
NODE_ID}/_catalog_checkpoint "$BACKUP_DIR/"

echo "Backup completed to $BACKUP_DIR"

#!/bin/bash
NODE_ID="
NODE_ID
"
SOURCE_BUCKET="
SOURCE_BUCKET
"
BACKUP_BUCKET="
BACKUP_BUCKET
"
BACKUP_PREFIX="backup-$(date +%Y%m%d-%H%M%S)"

# Copy in recommended order
aws s3 sync s3://${
SOURCE_BUCKET}/${
NODE_ID}/snapshots \
  s3://${
BACKUP_BUCKET}/${BACKUP_PREFIX}/${
NODE_ID}/snapshots/

aws s3 sync s3://${
SOURCE_BUCKET}/${
NODE_ID}/dbs \
  s3://${
BACKUP_BUCKET}/${BACKUP_PREFIX}/${
NODE_ID}/dbs/

aws s3 sync s3://${
SOURCE_BUCKET}/${
NODE_ID}/wal \
  s3://${
BACKUP_BUCKET}/${BACKUP_PREFIX}/${
NODE_ID}/wal/

aws s3 sync s3://${
SOURCE_BUCKET}/${
NODE_ID}/catalogs \
  s3://${
BACKUP_BUCKET}/${BACKUP_PREFIX}/${
NODE_ID}/catalogs/

aws s3 cp s3://${
SOURCE_BUCKET}/${
NODE_ID}/_catalog_checkpoint \
  s3://${
BACKUP_BUCKET}/${BACKUP_PREFIX}/${
NODE_ID}/

echo "Backup completed to s3://${
BACKUP_BUCKET}/${BACKUP_PREFIX}"

Restore process

Recommended restore order:

1. Catalog checkpoint file
2. Catalogs directory
3. WAL directory
4. Database (dbs) directory
5. Snapshots directory

File system restore example

#!/bin/bash
NODE_ID="
NODE_ID
"
BACKUP_DIR="/backup/
BACKUP_DATE
"
DATA_DIR="/path/to/data"

# 1. Stop InfluxDB
systemctl stop influxdb3 || docker stop influxdb3-core

# 2. Optional: Clear existing data for clean restore
rm -rf ${DATA_DIR}/${
NODE_ID}/*

# 3. Restore in reverse order of backup
mkdir -p ${DATA_DIR}/${
NODE_ID}
cp ${BACKUP_DIR}/_catalog_checkpoint ${DATA_DIR}/${
NODE_ID}/
cp -r ${BACKUP_DIR}/catalogs ${DATA_DIR}/${
NODE_ID}/
cp -r ${BACKUP_DIR}/wal ${DATA_DIR}/${
NODE_ID}/
cp -r ${BACKUP_DIR}/dbs ${DATA_DIR}/${
NODE_ID}/
cp -r ${BACKUP_DIR}/snapshots ${DATA_DIR}/${
NODE_ID}/

# 4. Set correct permissions (important for Docker)
chown -R influxdb:influxdb ${DATA_DIR}/${
NODE_ID}

# 5. Start InfluxDB
systemctl start influxdb3 || docker start influxdb3-core

Replace the following:

• NODE_ID: your node ID
• BACKUP_DATE: backup directory timestamp (for example, 20240115-143022)

S3 restore example

#!/bin/bash
NODE_ID="
NODE_ID
"
BACKUP_BUCKET="
BACKUP_BUCKET
"
BACKUP_PREFIX="backup-
BACKUP_DATE
"
TARGET_BUCKET="
TARGET_BUCKET
"

# 1. Stop InfluxDB
# Implementation depends on your deployment method

# 2. Optional: Clear existing data for clean restore
aws s3 rm s3://${
TARGET_BUCKET}/${
NODE_ID} --recursive

# 3. Restore from backup
aws s3 sync s3://${
BACKUP_BUCKET}/${BACKUP_PREFIX}/${
NODE_ID}/ \
  s3://${
TARGET_BUCKET}/${
NODE_ID}/

# 4. Start InfluxDB
# Implementation depends on your deployment method

Replace the following:

• NODE_ID: your node ID
• BACKUP_DATE: backup timestamp
• BACKUP_BUCKET: bucket containing backup
• TARGET_BUCKET: target bucket for restoration

Important considerations

Recovery expectations

Docker considerations

When running InfluxDB 3 Core in containers:

• Volume consistency: Use the same volume mounts for backup and restore operations
• File permissions: Ensure container user can read restored files (use chown if needed)
• Backup access: Mount a backup directory to copy files from containers to the host

Table snapshot files

Files in <node_id>/table-snapshots/ are intentionally excluded from backup:

• These files are periodically overwritten
• They regenerate automatically on server restart
• Including them doesn’t harm but increases backup size unnecessarily

Timing recommendations

• Perform backups during downtime or minimal load periods
• Copying files while the database is active may create inconsistent backups
• Consider using filesystem or storage snapshots if available
• Compression is optional but recommended for long-term storage