How to back up InfluxDB

Which InfluxDB do you run?

influxd version

That works on 1.x and 2.x; InfluxDB 3 answers influxdb3 --version. Each major version backs up differently:

InfluxDB 2: the operator token

influx backup needs an operator token: the one created by influx setup, or another made with --operator. An All Access token covers one organization only, and the backup fails with read:authorizations is unauthorized. With an existing operator token you can create one for backups:

influx auth create --org my-org --operator --description "backups"

Back up InfluxDB 2

Keep the token out of the command line and shell history, in a file only root can read (chmod 600), and run the backup as root:

INFLUX_HOST=http://localhost:8086
INFLUX_TOKEN=your-operator-token

set -a; . /etc/influxdb/backup.env; set +a; influx backup /var/backups/influxdb/2026-10-04_0215

• The influx CLI reads INFLUX_HOST and INFLUX_TOKEN as --host and -t. It talks to the HTTP API, so it can run from another machine.
• It creates the directory and writes the key-value store (tokens, users, dashboards, tasks) as .bolt.gz, the SQL metadata as .sqlite.gz, one .tar.gz per shard and a .manifest.
• --bucket example-bucket backs up one bucket. --compression none skips local gzip; with InfluxDB 2.9 and CLI 2.8, --gzip-compression-level speedy trades size for speed.
• It can't back up InfluxDB Cloud.

Restore InfluxDB 2

A plain restore recreates the backed-up buckets and their data. It can't write into a bucket that already exists:

influx restore /var/backups/influxdb/2026-10-04_0215

To bring one bucket back next to the live one, rename it on the way in:

influx restore --bucket telegraf --new-bucket telegraf-restored /var/backups/influxdb/2026-10-04_0215

--full replaces all data and the key-value store: tokens, users, dashboards and tasks. For a backup taken on 2.9, pass the operator token (CLI 2.8.0 or newer) so the CLI can authenticate once the old tokens are replaced:

influx restore --full --operator-token your-operator-token /var/backups/influxdb/2026-10-04_0215

InfluxDB moves existing data aside while it restores. If the restore fails, that data stays in a tmp directory under the engine path (/var/lib/influxdb/engine for the Linux package): copy the files back into engine, remove their .tmp extensions and restart influxd.

Restore InfluxDB 2 on a new server

Install the same InfluxDB version, then run setup with the source server's operator token as the new admin token. With a different token, the restore's first step replaces the token the CLI is using, and every later call fails to authenticate:

influx setup --username admin --password 'long-random-password' --org my-org --bucket scratch --token your-operator-token --force

influx restore --full --operator-token your-operator-token /var/backups/influxdb/2026-10-04_0215

--force skips the confirmation prompt. The org and bucket created by setup are replaced by the backup's. Then compare a few queries' counts with the old server. More on moving servers: migrating to a new provider.

InfluxDB 1.x

influxd backup -portable /var/backups/influxdb/2026-10-04

influxd restore -portable -db telegraf -newdb telegraf_restored /var/backups/influxdb/2026-10-04

• -portable writes the format InfluxDB 1.5 and later (and InfluxDB Enterprise) restore. Without it you get the legacy format.
• -db limits a backup or restore to one database, -rp to a retention policy, -start/-stop to whole shards overlapping a time range. -newdb and -newrp rename on restore.
• Both talk to influxd's RPC service on 127.0.0.1:8088 (bind-address in influxdb.conf), so influxd must be running.
• The backup skips the WAL and in-memory cache, so the latest writes may be missing.
• InfluxData supports restoring into the same version or one minor version up, such as 1.7 into 1.8, plus 1.8 into 1.11.

Restoring into an existing database fails. Restore under -newdb, then copy the points across with SELECT * INTO "telegraf".autogen.:MEASUREMENT FROM "telegraf_restored".autogen./.*/ GROUP BY * (once per retention policy) and DROP DATABASE "telegraf_restored".

InfluxDB 3 Core and Enterprise

InfluxDB 3 keeps everything in object storage: a local directory, S3, Azure or Google Cloud Storage. Core has no backup command. You copy the node's files in this order, preferably while it is stopped or quiet, since copying under load can give an inconsistent backup. The Linux package keeps them in /var/lib/influxdb3/data with node ID primary-node:

#!/bin/bash
set -euo pipefail
SRC="/var/lib/influxdb3/data/primary-node"
DEST="/var/backups/influxdb3/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$DEST"
cp -r "$SRC/snapshots" "$DEST/"
cp -r "$SRC/dbs" "$DEST/"
cp -r "$SRC/wal" "$DEST/"
cp -r "$SRC/catalog" "$DEST/"
cp "$SRC/_catalog_checkpoint" "$DEST/"

Stop the service around the copy (systemctl stop influxdb3-core) if you can afford the downtime. To restore, stop it, copy the files back in reverse order (checkpoint, catalog, wal, dbs, snapshots), chown -R them back to the user the service runs as (note it with ls -l first) and start the service. Recovery reaches the latest snapshot in the backup. For S3, the docs do the same with aws s3 sync into a separate bucket. Before upgrading 3.11 to 3.12, back up catalog/: 3.11 can't read the catalog after 3.12 has started on it.

Enterprise on the upgraded storage engine (the default for new clusters) has built-in commands, run against a compactor node with an admin token. Since 3.11 they can be incremental:

influxdb3 create backup --name base --token "$ADMIN_TOKEN"

influxdb3 create backup --name inc-1 --incremental --parent base --token "$ADMIN_TOKEN"

create backup returns at once; wait for influxdb3 status backup --name base to say completed before chaining from it. influxdb3 create restore --backup inc-1 rolls the live cluster back to that point, walking the chain itself. Backups land inside the same object store, under <cluster_id>/backups/<name>/, so copy them elsewhere. Clusters that started on 3.10 or earlier and haven't upgraded their storage engine use Core's manual procedure.

Export line protocol: a copy any version can read

Line protocol is plain text that InfluxDB 1, 2 and 3 all accept, which makes it the copy to keep for moving between versions. On 2.x, find the bucket ID with influx bucket list, then:

influxd inspect export-lp --bucket-id 12ab34cd56ef --engine-path /var/lib/influxdb/engine --compress --output-path /var/backups/influxdb/telegraf.lp.gz

• It reads the TSM and WAL files directly, one bucket per run; --start, --end and --measurement narrow it.
• Load it into 2.x with influx write --bucket telegraf --file telegraf.lp.gz (gzip is detected from the .gz name). For InfluxDB 3, gunzip it and run influxdb3 write --database telegraf --token <token> --file telegraf.lp; the server accepts 10 MB per request by default (max-http-request-size), so split -l big files first.
• On 1.x the equivalent is influx_inspect export, imported with influx -import.
• influx export all is not a data backup: it writes dashboards, tasks and other resources as a template, with no points.

Run InfluxDB 2 backups every night

#!/bin/bash
set -euo pipefail
set -a
. /etc/influxdb/backup.env
set +a

DEST="/var/backups/influxdb/$(date +%F_%H%M)"
influx backup "$DEST"
find /var/backups/influxdb -mindepth 1 -maxdepth 1 -type d -mtime +1 -exec rm -rf {} +
echo "$(date -Is) backed up to $DEST"

sudo chmod 700 /usr/local/bin/influxdb-backup.sh

15 2 * * * root /usr/local/bin/influxdb-backup.sh >> /var/log/influxdb-backup.log 2>&1

The find line keeps about two days of backups on the server. The CLI creates the files readable only by the user who ran it (root here), so whatever copies them must read as root. Copy the directory off-site, per the 3-2-1 rule, and restore a backup into a scratch server each month to time it (testing restores).

Common errors

Frequently asked questions

Why does influx backup fail with read:authorizations is unauthorized?

Backups need an operator token, which covers every organization. An All Access token covers one organization and is refused. Use the token from influx setup or create one with influx auth create --operator.

Can I restore an InfluxDB 2 backup into an existing bucket?

No. Restore it under another name with --new-bucket, or delete the bucket first. influx restore --full replaces everything on the server.

Does InfluxDB 3 Core have a backup command?

No. You copy the object-store files in the documented order, ideally while the server is stopped or quiet. InfluxDB 3 Enterprise on the upgraded storage engine has influxdb3 create backup.

Can I restore an InfluxDB 1.x backup into InfluxDB 2?

Not with influx restore, which reads only 2.x backups. Upgrade the 1.x data with influxd upgrade, or export it as line protocol and write it into a 2.x bucket.

Does influx export back up my data?

No. It exports dashboards, tasks and other resources as a template. Use influx backup, or influxd inspect export-lp for the points themselves.