criticalFoundationSymptom-first#volumes#persistence#data-loss#ephemeral

Data lost after container removal — no volume mounted

Data written inside container is gone after docker rm

Likely source:data-lossconfiguration

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Data written inside container is gone after docker rm
  • docker run of the same image starts with an empty filesystem
  • Database files disappear between container restarts

Every Docker container has an ephemeral writable layer. Without a volume mount, all data written to the container filesystem is destroyed when the container is removed.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Container mount points

    docker inspect <CONTAINER> --format='{{json .Mounts}}'

  • Volume list

    docker volume ls

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • docker inspect shows no mounts on the data directory
  • Data persists only while the container is running (not after rm)

Confirm before fixing

docker inspect <CONTAINER> --format='{{range .Mounts}}{{.Destination}}{{println}}{{end}}'
READ

List mount destinations

Fix

docker run -v <VOLUME_NAME>:/var/lib/app/data <IMAGE>
CHANGE

Run with a named volume to persist data beyond the container

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
docker inspect <CONTAINER> --format='{{range .Mounts}}{{.Type}} {{.Source}} -> {{.Destination}}{{println}}{{end}}'
READ

Check what is mounted

2
docker volume ls
READ

List named volumes

3
docker volume create <VOLUME_NAME>
CHANGE

Create a named volume for persistence

4
docker run -v <VOLUME_NAME>:/data <IMAGE>
CHANGE

Re-run the container with the named volume attached

Prevention

  • Always mount volumes for any directory that must persist (databases, uploads, configs).
  • Use named volumes (not anonymous) so data survives docker system prune.
  • Back up volumes before running docker system prune or docker volume prune.
  • Document which paths must be mounted in the container's README or docker-compose.yml.

Related runbooks

Same stack, same failure family — worth a skim.

Bind mount appears empty — container sees no filesmedium

Container shows empty directory for a bind mount path

DockerFoundation3 causes
Open runbook
Bind mount permission denied — UID/GID mismatchmedium

Permission denied when writing to a bind-mounted directory inside the container

DockerIntermediate3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.