Backing up a Docker host: volumes, bind mounts and what an image does not hold

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Many small businesses and internal teams run several applications on one Linux server with Docker and Docker Compose. Recovery planning often stops at the thought that the images are on a public registry and can be pulled again. The images are rarely the problem. The data, settings and exact versions around them are.

This guide is for an administrator running containers on one server. It covers where state lives, how Docker documents volume backups, where that pattern needs care, and how to prove a rebuild works. Kubernetes clusters have different control-plane needs and are not covered.

Why it matters

Docker's storage overview is plain about the default: "Data written to the container layer doesn't persist when the container is destroyed." It also says: "The writable layer is unique per container."

Rebuilding a host means recreating containers, so anything written only inside a container is lost unless it was stored elsewhere (our reading). Saving the container does not help much either. The docker container commit reference states: "Commits do not include any data contained in mounted volumes."

Where state lives on a Docker host

The storage overview lists the mount types Docker supports "for storing data outside of the writable layer of the container": volume mounts, bind mounts, tmpfs mounts, image mounts and named pipes. For backup, the first two matter most (our reading).

Named and anonymous volumes

"Volumes are persistent data stores for containers, created and managed by Docker." The volumes page adds: "Volumes are the preferred mechanism for persisting data generated by and used by Docker containers." Their contents "exist outside the lifecycle of a given container."

With the default local driver, Docker's own inspect examples show a volume's data under a path such as /var/lib/docker/volumes/myvol2/_data. The page also warns that "Volumes are not a good choice if you need to access the files from the host, as the volume is completely managed by Docker." A host-level file backup that copies those paths directly is working underneath Docker, not with it (our reading).

Anonymous volumes need particular attention. "Anonymous volumes are given a random name that's guaranteed to be unique within a given Docker host." They persist when a container is removed, "except if you use the --rm flag when creating the container, in which case the anonymous volume associated with the container is destroyed." A random name gives no clue which application owns the data, so map them before you need them (our recommendation).

Bind mounts

"Bind mounts create a direct link between a host system path and a container, allowing access to files or directories stored anywhere on the host." The overview adds: "Since they aren't isolated by Docker, both non-Docker processes on the host and container processes can modify the mounted files simultaneously."

Bind-mounted folders are ordinary host paths, so a normal file backup can reach them. The bind mounts page notes they "rely on the host machine's filesystem having a specific directory structure available." A rebuilt host needs the same paths, ownership and permissions (our reading).

Configuration and versions

Containers are usually defined by Compose files. These often refer to an .env file or an env_file attribute, which Docker describes as a way to set "A container's environment". Those files may hold connection strings or secrets, so back them up and protect them accordingly (our recommendation).

Compose can also mark a volume as external, meaning it "already exists on the platform and its lifecycle is managed outside of that of the application." A rebuild must recreate such volumes, under the right names, before the application starts (our reading).

Image versions matter too. The docker image pull reference explains that with tags, "you can docker pull an image again to make sure you have the most up-to-date version of that image." Pulling by digest instead fixes the version; Docker says it lets you "guarantee that the image you're using is always the same." A rebuild that pulls latest may run newer software against older data (our reading). Record a pullable repository@digest, platform and required registry read access, and verify the registry retains and serves that image. A local image ID is not that pull reference. If an image lacks a usable repository digest or registry retention is uncertain, keep and test a docker image save archive, which saves "one or more images to a tar archive".

Swarm managers

If the host is a Swarm manager, it also holds cluster state. Docker's Swarm guide says manager nodes "store the swarm state and manager logs in the /var/lib/docker/swarm/ directory. This data includes the keys used to encrypt the Raft logs. Without these keys, you cannot restore the swarm." If auto-lock is on, "you need the unlock key to restore the swarm from backup."

Docker's documented volume backup pattern

The volumes page shows a pattern: start a temporary container that mounts the volume with --volumes-from and a host folder at /backup, then run tar over the volume. Restore is the reverse into a new container's volume. Docker says: "You can use these techniques to automate backup, migration, and restore testing using your preferred tools."

The example is a file-archive pattern, not an application-consistency guarantee. Archiving a database or other state while it changes can mix old and new content. Another container can share the same volume, and host processes can write through a bind mount, so stopping one container is not sufficient (our reading).

For Swarm state, follow Docker's complete manager backup procedure, including its stop-Docker step, quorum planning and unlock-key protection. A majority of managers must remain available for management operations; stopping a manager can remove quorum in an inadequately redundant swarm. Assess that effect and the recovery/change plan before maintenance. This single-host guide is not a standalone Swarm shutdown runbook.

For databases in containers, two approaches are safer (our recommendation):

• Prefer the database's supported backup tool inside or alongside the container. Confirm the dump/backup completes successfully, then protect that exact output together with required application state.
• For a file archive, coordinate every writer through the application's supported quiescence or clean-shutdown procedure: all sharing containers, host processes and any external writers. Verify the consistent state is held throughout the copy. Agree an owner, permitted interruption, restart checks and failure/resume procedure before beginning; do not assume stopping one container makes the volume safe.

Check paths for each image version. The PostgreSQL Official Image page notes an "Important Change: the PGDATA environment variable of the image was changed to be version specific in PostgreSQL 18 and above". For 18 it gives /var/lib/postgresql/18/docker, and says "The defined VOLUME was changed in 18 and above to /var/lib/postgresql". A backup job written for an older layout may archive the wrong folder after an upgrade (our reading).

What to keep for a rebuild

Pulling the pieces above together, a rebuild of one Docker host usually needs the following (our recommendation). Treat it as a starting list and add anything your applications need.

Two points are easy to miss. First, a backup of the image archives does not replace a backup of the volumes, because, as noted above, commits and images do not carry mounted volume data. Second, secrets in environment files are only useful in a rebuild if the backup holding them is itself protected and can be reached when the host is gone (our reading).

Keep this list with the backup, not only on the host. A rebuild record stored on the server that failed is of no help on the day (our recommendation).

Read-only checks

Run these in a bash shell on the Docker host as a user allowed to query Docker. They list and inspect; they do not change containers, volumes or images.

List containers and volumes:

docker ps -a
docker volume ls

See each container's mounts. Scope the output to Mounts, which shows each mount's Type, Name, Source and Destination. Unfiltered container inspection can expose environment secrets, so keep inventory output restricted and protected.

docker inspect --format '{{json .Mounts}}' <container-name>

Inspect a volume:

docker volume inspect <volume-name>

From these, build a table of container, mount type, volume name or host path, destination inside the container, and the application that owns it (our recommendation). Mark any anonymous volume and any container started with --rm.

Record image identity and availability. The container's .Config.Image is the configured tag/reference; .Image is its local image configuration ID. Record both, then inspect that local image for available repository digests and platform:

docker inspect --format '{{.Config.Image}} {{.Image}}' <container-name>
docker image inspect --format '{{json .RepoDigests}} {{.Os}} {{.Architecture}}' <local-image-id>

Record any platform variant required by the deployment. Do not treat the local .Image ID as a pullable registry manifest digest. .RepoDigests can be empty, especially for locally built images. Preserve a usable repository@digest plus registry read-access and retention arrangements, or a saved image archive, and verify the chosen route on an authorised isolated host. Merely recording a digest does not prove the image is obtainable.

Collect configuration. Find every Compose file, .env file and env_file reference, and confirm each is covered by the host backup.

These checks show what exists. They do not prove a backup is consistent or that a rebuild works (our reading).

Safe restore rehearsal

Use an authorised, isolated test host with no access to production networks, databases or registries' write credentials (our recommendation).

1. Record expected IDs, counts and application facts from a controlled synthetic fixture at a defined recovery point. Complete the supported dump/backup and verify its success, freshness, output identity and inclusion in the protected backup. Coordinate related application state to the intended consistent point; do not compare a past backup with later production data.
2. Install the same Docker and Compose versions on the test host.
3. Restore Compose files, environment files and bind-mounted folders with their ownership and permissions.
4. Recreate volumes, including any marked external, and restore their contents from backup, using Docker's restore pattern or the database's own restore tool.
5. Recover the exact images by either pulling the recorded repository@digest with authorised registry read access for the recorded platform, or loading the protected docker image save archive and verifying the expected image and platform. Loading an archive and pulling a digest are different recovery paths; test whichever the plan requires.
6. Start the applications and compare the restored facts with the baseline for that same recovery point. Verify dependent files and services as well as the database; record real data loss separately from a baseline mismatch.
7. Time each step and note anything that had to be found by hand.

Diagnosing what you find

• Application starts with empty data: the volume name differs from what Compose expects; an anonymous volume was never backed up; the data was in the container's writable layer; or a bind-mount path is wrong on the new host.
• Database refuses to start or reports damage: files were archived while it was writing; the image is a different major version from the data; or the volume path changed between image versions.
• Permission errors on bind mounts: ownership or permissions were not preserved; user IDs differ on the new host; or security labels differ.
• Application behaves differently: a tag pulled newer software; the .env file was missing or outdated; or an external volume was recreated under a different name.

Worked example (illustrative)

The following is invented. A small firm runs a wiki, a ticketing tool and a PostgreSQL database on one Docker host. Nightly backups copy /srv (bind mounts) and the Compose folder. A rehearsal shows the database starts empty. Its data was in a named volume under /var/lib/docker/volumes, which the backup job excluded. The ticketing tool also pulls latest and starts on a newer release than the data.

In the invented corrected workflow, each database dump writes to a unique output. The job checks completion, errors and freshness, preserves the last good copy on failure, and reports protection success only after the exact output and required related files are verified in the backup. The team records an obtainable image by repository digest and platform, with registry read access, or retains a tested image archive. An isolated rehearsal then restores the exact protected dump and related fixture files with that image and matches the IDs and counts recorded at the chosen synthetic recovery point. That hypothetical completed restore is the acceptance result; repeating it after upgrades is ongoing maintenance. No author-run lab test is claimed.

Risks and limits

• Volume drivers other than local, Docker Desktop and Windows containers behave differently.
• Applications may keep state in places not described here; check each one's documentation.
• No command in this guide was run in a lab. Test first in an isolated environment.

Sources

All accessed 14 November 2026.

• Docker, Storage: https://docs.docker.com/engine/storage/
• Docker, Volumes: https://docs.docker.com/engine/storage/volumes/
• Docker, Bind mounts: https://docs.docker.com/engine/storage/bind-mounts/
• Docker, Storage drivers: https://docs.docker.com/engine/storage/drivers/
• Docker, docker container commit: https://docs.docker.com/reference/cli/docker/container/commit/
• Docker, docker image save: https://docs.docker.com/reference/cli/docker/image/save/
• Docker, docker image pull: https://docs.docker.com/reference/cli/docker/image/pull/
• Docker, docker inspect: https://docs.docker.com/reference/cli/docker/inspect/
• Docker, docker volume inspect and docker volume ls: https://docs.docker.com/reference/cli/docker/volume/inspect/ and https://docs.docker.com/reference/cli/docker/volume/ls/
• Docker, Define and manage volumes in Docker Compose: https://docs.docker.com/reference/compose-file/volumes/
• Docker, Set environment variables within your container's environment: https://docs.docker.com/compose/how-tos/environment-variables/set-environment-variables/
• Docker, Administer and maintain a swarm of Docker Engines: https://docs.docker.com/engine/swarm/admin_guide/
• Docker Hub, postgres Official Image: https://hub.docker.com/_/postgres

Related future topics

• Database dumps from containers: scheduling and checking them
• Container registries and image retention as part of recovery
• Secrets in Compose files: storing and recovering them safely

This article was originally published on 14 November 2026.