Persist container data

A container’s writable layer is disposable. Every file a process writes inside the container, outside a mounted volume, is deleted the moment the container is recreated — and updates recreate containers. Persistent application state needs an explicit storage location and backup plan, declared in the Compose file where you can see it.

Declare the volume

First find where the application keeps its state — the image’s documentation states it (databases often use /var/lib/<name>, apps often use /data or /config). Add a named volume where the chosen lab service expects data:

services:
  app:
    volumes:
      - app-data:/var/lib/app

volumes:
  app-data:

The top-level volumes: key declares a named volume called app-data; the service line mounts it at /var/lib/app inside the container. Docker manages the volume’s lifecycle separately from the container, which is the entire point. The alternative is a bind mount like /srv/data/app:/var/lib/app, which puts the files on a host path you own — pair it with the ownership lesson’s UID setup if you go that way.

Prove it survives recreation

Never trust persistence you haven’t tested. Create test data, remove and recreate the container, and confirm the data remains:

docker compose exec app sh -c 'echo probe > /var/lib/app/probe.txt'
docker compose down
docker compose up -d
docker compose exec app cat /var/lib/app/probe.txt
# probe

docker compose down removes the container entirely (named volumes survive by default). If probe comes back after the recreate, the state lives in the volume. If the file is gone, the app writes its data somewhere you didn’t mount — go back to the image docs and fix the path.

Then locate and document the volume:

docker volume inspect whoami_app-data

The Mountpoint field shows where the bytes live on the host, typically under /var/lib/docker/volumes/. Put that in your notes; the backup lesson needs it.

The failure mode

Confusing surviving a restart with surviving anything else. Persistence is not backup. Deletion, corruption, and host failure can affect both container and local volume — the volume is on the same disk, in the same house. A volume protects you from container recreation, nothing more. The operate-and-recover module handles the rest.