How do I back up and restore the data of a self-hosted Tares instance?

Tares keeps its data in a single DuckDB file, so you back up a self-hosted instance by snapshotting the volume or copying that file. In a container the file is /data/tares.duckdb. You restore by putting the file back before you start Tares. If you set TARES_STATE_DSN, the state also lives in Postgres and you back that up too.

How it works

Tares is a single process writing to a single DuckDB file. There is no external database or broker to run, so there is one thing to protect.

• The data is the DuckDB file. In Docker and in the compose setup, the file is /data/tares.duckdb inside the tares-data volume.
• A local install keeps its data in ~/.tares. tares up uses that directory. The TARES_DB environment variable sets the path to the DuckDB file, and its default file name is tares.duckdb.
• One daemon, one volume. DuckDB is single-writer, so a deployment is exactly one taresd and one data volume. Do not run several replicas against the same data.
• A secured instance keeps its root token in the data directory. A bare tares up --auth generates a root token and persists it to the data dir, so a copy of the directory carries it.
• With TARES_STATE_DSN set, the data is split. The state (projects, tickets, agents, settings) is in Postgres and the events stay in the DuckDB file. The first start moves the state out of the DuckDB file once. After that the instance refuses to start without the Postgres database.

The deployment details, including the compose file, are on the Deployment page. If you run Tares as part of an incident workflow, the AI SRE guide shows what the stored data feeds.

Set it up

1. Find your data. On Docker or compose, it is the tares-data volume mounted at /data. Here is the Docker run command from the deployment page, where -v tares-data:/data is the volume to protect:

docker network create tares
docker run -d --name taresd --network tares -p 8787:8787 -v tares-data:/data \
  ghcr.io/glassflow/tares:latest
docker run -d --name tares-mcp --network tares -p 8788:8788 \
  ghcr.io/glassflow/tares:latest \
  tares mcp --transport streamable-http --host 0.0.0.0 --port 8788 --taresd http://taresd:8787

2. Back it up. Pick one of two ways:

   • Snapshot the tares-data volume, or the whole host, with the snapshot tooling you already use.
   • Copy /data/tares.duckdb to storage outside the host.

3. If you use Postgres state, back that up too. When TARES_STATE_DSN is set, take a database backup with pg_dump or your provider’s backups, in step with the DuckDB file backup. The two belong together.

4. Restore the file before start. Put the snapshot back, or copy tares.duckdb back to /data/tares.duckdb in the volume (or to the path TARES_DB points at), while Tares is not running.

5. Restore Postgres alongside it. If you use TARES_STATE_DSN, restore the database from the matching backup and keep TARES_STATE_DSN set to it. Restore the two together so state and events match.

6. Start Tares. Start the daemon as you normally do. On a local install that is:

tares up

On compose, start the stack again from its directory with your usual command. The daemon opens the restored file and picks up where the backup left off.

7. Keep the file name. The file must be named tares.duckdb, the default for TARES_DB. A restored file under any other name is not found unless TARES_DB points at it, and the daemon starts with an empty database.

What you get

• A recovery path that is one file for most instances, so there is nothing to coordinate across services.
• Backups that fit the tools you already run: volume snapshots, host snapshots or a plain file copy.
• A restore that is a file placement before start, with no import step.
• A clear rule for the split setup: DuckDB file and Postgres database are backed up and restored as a pair.
• A copy of the data directory on a secured local instance that also carries the persisted root token.

When something else fits

• If you run Postgres for state with TARES_STATE_DSN, your Postgres backup process matters as much as the volume snapshot, so use your provider’s backups there.
• If you only need to move a small piece of configuration between instances, the deployment page describes the catalog YAML that TARES_CATALOG imports on first boot, which is lighter than restoring the whole file.

Related