Docker Compose backups: volumes, bind mounts and restore tests

Your containers are replaceable. Your data needs a way back. A useful Compose backup brings back the database, uploaded files, configuration and keys together. Finish the job by restoring a separate copy and opening something you recognise in the application.

Volumes keep data through container replacement; backups give you a separate recovery copy. Your finish line is a working application with the expected data.

Procedure from Docker and PostgreSQL documentation; examples are illustrative.

What you’ll need

We earn a commission if you buy through our links — it doesn’t change our picks. How we make money → As an Amazon Associate I earn from qualifying purchases.

Build the recovery kit: Keep a separate backup destination, protected copies of configuration and keys, and spare storage for the restore drill. If that destination is a separate compatible NAS, the WD Red Plus 4 TB (WD40EFZZ) is the small-capacity drive pick in our NAS-drive buying guide. Choose enough capacity for your recovery sets and retention; the drive needs a suitable NAS enclosure and connection.

Decide what a successful restore looks like

Start with the operation the restored application must perform. A useful requirement might be that it can open an existing record and retrieve its associated uploaded file from the selected restore point. That is more specific than asking whether an archive exists.

Identify the components that own that state and how they interact. A database and a directory of uploaded files may need a coordinated recovery point. An application may also depend on encryption keys, configuration, identities or another state store. Write these dependencies down rather than assuming that everything important is under one mount.

Use the RAID, snapshots and backups guide for independent copies, history and surviving access. This guide addresses the application-consistency and restoration work that must happen around those copies.

Decide what may be regenerated and what must be preserved. Excluding a cache can be reasonable when its regeneration is supported and understood; excluding something merely because its name looks temporary is an unverified assumption. Keep the reason for each exclusion in the recovery record.

Inventory volumes, bind mounts and recovery dependencies

Docker’s volume documentation describes volumes as Docker-managed persistent storage outside an individual container’s lifecycle. It also notes that a volume can be mounted by multiple containers. Therefore, identify all potential writers before treating one stopped container as a complete consistency boundary.

A bind mount instead exposes a file or directory from the Docker daemon host. Record the host-side source as well as the destination inside the container. A path available to the client running a command is not necessarily the path used by a remote daemon.

Use this recovery manifest for each application. Keep identifiers and protected configuration in your private recovery notes.

Recovery item	What to record	Question to resolve
Compose definition and overrides	Required deployment configuration and how it is selected	Can the intended configuration be reconstructed?
Application images	Required version or image identity and availability	Can compatible application code be obtained?
Named or anonymous volumes	Actual storage identity, mounts and writers	Which dataset is captured and restored?
Bind-mounted state	Daemon-host source, destination and required metadata	Does the replacement environment map the intended files?
Database state	Native backup method, scope and recovery requirements	Is the capture coherent and complete for this method?
Keys and recovery credentials	Protected recovery route and required access	Can the restored state be decrypted and used?
Related files and external state	Dependencies that must agree with the database	Do the selected copies represent a usable application point?

Record both the application’s logical names and the storage resources they actually resolve to. During recovery, that mapping is more useful than a list of attractive directory names without their owners or mount destinations.

Keep the data alongside the container recipe

The Docker container export reference explicitly excludes mounted-volume contents. When a volume obscures an underlying container directory, the export contains the underlying directory rather than the mounted data.

A large container archive can still miss your mounted data. Keep the Compose definition as the launch recipe and capture persistent state separately.

Keep reproducible application code, deployment configuration and mutable state as separate entries in the manifest. For each entry, identify how it will be obtained during recovery and what evidence confirms that it belongs to the intended version and restore point.

Do not rely on a single artifact’s size or successful creation as a completeness check. Compare its documented coverage with the manifest. If an item has no recovery source, name that gap before accepting the plan.

Get a consistent copy

Use your application’s supported backup procedure. A changing database needs a capture method that keeps its files consistent.

Choose a starting method below, then follow the application’s rules for writers and coordination.

State and requirement	Starting method	Evidence needed
Files that can be made stable for the capture	Documented stopped or quiesced file copy	All relevant writers controlled and required files/metadata included
Database with a supported logical export	Database-native backup and documented restore procedure	Successful export, its scope, compatibility and required global state
Running database with a supported physical backup method	The database’s documented physical-backup procedure	Required logs, metadata and complete recovery inputs
Snapshot-based capture	Application-supported consistent snapshot across the required storage	Supported coordination, included logs and matching capture boundaries
Multiple stores that must represent one application point	Application-specific coordination	Database, files and other state can be restored together meaningfully

Document the chosen method beside the dataset. “Stored in a Docker volume” identifies a location; it does not answer the consistency question.

Use the database’s rules, not a container shortcut

The PostgreSQL 18 file-backup documentation provides a concrete example. An ordinary file-copy backup requires the database server to be stopped. The same document permits a properly implemented consistent snapshot of a running database, with the required WAL included.

It also warns about data spread across filesystems: the relevant snapshots must be simultaneous for that documented approach. Independent snapshots taken at unrelated moments should not be assumed to satisfy it.

For another database engine, use its own backup process, including the required logs and recovery steps.

For a logical-backup example, the PostgreSQL 18 SQL-dump documentation describes pg_dump as internally consistent for its database. It excludes cluster-wide roles and tablespaces. The document explains how pg_dumpall includes cluster-wide definitions, while explicitly noting that its separate database snapshots are not synchronized.

Record the export’s scope and any additional recovery inputs, especially when the application spans several databases.

Coordinate database state with related files

Suppose your application records an uploaded file in a database. A database export and a file copy taken at unrelated moments need an application-specific explanation of why the relationship will remain valid after restoration.

Your recovery notes should state which writers are controlled, which operations are allowed during capture and what establishes the shared point. If downtime is acceptable, a documented stop-and-capture process may be simpler to support. If work must continue, use the application’s supported coordination or online-backup method.

Do not assume that stopping the visible frontend stops every writer. The inventory should identify other components that can change the same state. Likewise, a consistent per-database dump should not silently be described as a synchronized multi-database export.

Keep this practical: choose a method you can explain and repeat with the actual application documentation. Resolve any missing coordination before relying on the backup.

Keep the recovery set together—and a separate copy

Before copying artifacts onward, record which capture actually completed. Preserve the method, application/database version, scope, completion status and relevant errors. If the operation has several stages, each required stage needs a usable result.

Record the relationship between the artifacts, not merely their filenames. A database export, uploaded files and protected configuration should be identifiable as the intended recovery set. If a required stage failed, explain how the application was returned to its normal state and which recovery point remains usable.

Move the required artifacts into the independent-copy and retention plan. A capture left only beside its source has not answered the failure scenario of losing that storage. Keep the recovery instructions available through a route that survives the same incident.

Verify archive integrity, then go further: recover the application and use its restored state.

Isolate restore destinations before starting containers

A restore test needs separate destinations that cannot accidentally resolve to the original application state. Check every volume and bind mapping before startup, including configuration overrides and externally managed resources.

The Compose volume reference says that an external volume already exists outside the application’s lifecycle. It also states that an explicit volume name is used without stack-name scoping. For those resources, set separate restore destinations explicitly; changing the Compose project name is insufficient.

Map each dataset to its restore destination and verify the mapping. Bind mounts need the same attention: the test must reference the intended restored host-side files, rather than the original location.

Use the application’s supported way to prevent unintended external actions in the test environment. Validate that requirement before allowing the application to start. Redirect external dependencies as well as filesystem destinations.

Keep the original recovery artifacts unchanged while testing a separate restored copy. Do not turn a drill into an undocumented in-place replacement of the working application’s data.

Restore compatible versions and required access

Record the compatible application and database versions required by the chosen recovery method. Make image availability part of the plan rather than assuming that the original code will always be obtainable when needed.

Restore required ownership, permissions and protected dependencies according to the application and storage documentation. Do not resolve an unexplained access failure by broadly weakening permissions. Verify that the restored processes read the intended files with the expected identities.

Account for startup behaviour, including any automatic migration that the application may attempt. Use a supported version and test copy so that a recovery experiment does not modify the only surviving artifact or the original state.

The Proxmox versus bare-metal Docker guide covers host and guest recovery boundaries. Recovering a host or guest can be one stage of this process, but the application still needs its own state and operation checks.

Open a record, retrieve a file, restart

Define a known test fixture before the drill. In the database-and-files example, verify that a restored record is visible and its associated uploaded file can be retrieved through the application. Check the selected historical point, not merely whether some data appears.

Then perform a supported restart and confirm that the restored state remains usable. Record exactly which operations succeeded and which dependencies were not exercised. Use the application operation you defined at the start as your acceptance test.

If recovery timing matters, time your drill with explicit start and end points and record the hardware and method.

Your backup earns its place when you can use it. Keep the recovery set, the restore steps and the results together, so the next drill starts with a recipe you can repeat.