Persist Prometheus data when running in Docker

Mount a named volume or suitable host directory at Prometheus's configured TSDB path. In the official image's usual setup that path is /prometheus. Reuse the same storage when replacing the container; a volume alone does not provide a backup or protection against intentional volume deletion.

Run with explicit persistent storage

Create prometheus.yml first, then:

docker volume create prometheus-data
docker run -d --name prometheus -p 127.0.0.1:9090:9090 \
  --mount "type=bind,src=$PWD/prometheus.yml,dst=/etc/prometheus/prometheus.yml,readonly" \
  --mount type=volume,src=prometheus-data,dst=/prometheus \
  prom/prometheus

Select an approved pinned version or digest for production rather than relying on the moving default image tag. The loopback publication is suitable for local access; configure authenticated access and networking deliberately when exposing the service elsewhere.

An image can declare an anonymous volume, but relying on an unnamed volume makes reuse harder to manage. Explicit naming makes the intended data location clear.

Express the same layout in Compose

services:
  prometheus:
    image: prom/prometheus
    ports:
      - "127.0.0.1:9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus
volumes:
  prometheus-data:

Compose normally prefixes the volume name with the project name. Reusing a different project name can create a different volume and make the database appear empty. docker compose down -v removes declared nonexternal named volumes; do not use it when the data must remain.

Keep rule files and other referenced configuration available too. If you override the image command, retain the intended --config.file and --storage.tsdb.path arguments so the process still reads and writes the mounted locations.

Check ownership and storage suitability

For bind mounts, inspect the chosen image's runtime UID/GID and grant that identity the required access. Do not blindly apply chown 65534:65534 to an existing data tree: image versions, runtime user overrides, and user namespaces can change the relevant IDs.

Use a filesystem supported by Prometheus's local storage requirements. Network filesystems such as NFS are not a safe generic substitute. A named Docker volume can be production storage when its driver and underlying filesystem are suitable; bind mounts are not automatically more production-ready.

Back up and test recovery

Prometheus exposes a TSDB snapshot endpoint when --web.enable-admin-api is enabled:

curl -X POST http://127.0.0.1:9090/api/v1/admin/tsdb/snapshot

Keep that administrative endpoint restricted. A snapshot in the same volume is not an independent backup: copy the completed snapshot to separate storage and test a restore with a compatible Prometheus version. Alternatively, stop the process before taking a consistent filesystem copy of the TSDB; do not assume an arbitrary live directory copy is consistent.

For longer retention or cross-instance queries, evaluate systems such as Thanos, Mimir, or a compatible remote-storage destination with its required integration. A local volume does not provide those capabilities.

FAQ

Does container deletion always destroy the samples?

Writable-layer data is lost with the container, but volume data has a separate lifecycle. The key is knowing which path Prometheus uses and whether you retain and remount the storage.

Can I migrate by copying the directory?

Use a consistent stopped-data copy or a supported snapshot workflow, preserve access permissions, and check version compatibility. Test the target before retiring the source.

References: Prometheus Docker installation, storage and backups, snapshot API.