Docker Backup Strategy for Self-Hosted Apps: Volumes, Databases, and Restore Testing

Overview

Containers are usually replaceable. The data attached to them is not. A new image can recreate an application, but it cannot restore a photo library, password vault, database, uploaded document, or carefully tuned configuration unless those items were backed up separately.

A practical Docker backup strategy starts with an inventory. For every service, record the Compose project, image reference, environment variables, bind mounts, named volumes, database type, external dependencies, and restore procedure. This inventory becomes the boundary of the backup: if an item is needed to start or recover the service, it belongs in the plan.

The 3-2-1 backup strategy is a useful baseline: keep at least three copies of important data, on at least two types of storage, with at least one copy off-site. The exact storage tools can vary. A home server, VPS, or private cloud can all work if the backup is isolated from the primary host and regularly tested.

Back up data at the application level where possible. Database dumps are generally easier to inspect and restore than raw database files copied while the database is active. For file-based applications, a consistent copy of the relevant directory may be sufficient, but the application’s own export or maintenance procedure should take priority when one exists.

If you are deploying several services on a VPS, first document their storage paths and recovery dependencies. The Docker deployment guide for self-hosting on a VPS provides useful context for organizing that environment. Platform users should also record whether deployment metadata lives in Coolify, Dokploy, CapRover, or another control plane; the comparison of Coolify, Dokploy, and CapRover can help frame those differences.

Checklist by scenario

For a simple file-based service

• List every bind mount and named volume used by the Compose file.
• Back up application data, user uploads, configuration files, and custom themes or plugins.
• Include the Compose file, environment-variable template, proxy configuration, and documented version information.
• Stop the service briefly or use its maintenance mode if a live copy could produce inconsistent files.
• Restore a sample directory into a temporary location and verify permissions, filenames, and file contents.

For a database-backed application

• Create scheduled logical dumps using the database’s supported dump utility.
• Keep the database dump separate from the application’s uploaded files and configuration.
• Record the database engine, major version, database name, user, and connection settings needed for recovery.
• Check that the dump completes successfully and produces a non-empty file of an expected type.
• Restore the dump into an isolated database container and run an application-level check, such as signing in or opening a recently created record.
• Retain raw database storage only as an additional measure, not as a substitute for consistent dumps.

For a Docker host with multiple apps

• Create an inventory of all Compose projects, volumes, bind mounts, secrets, certificates, and scheduled jobs.
• Back up the project files and deployment documentation without exposing plaintext secrets in an unsecured location.
• Define dependencies, such as a reverse proxy, shared network, object storage service, or external DNS provider.
• Separate backup jobs so one failed application does not silently prevent all other backups.
• Monitor job results and storage capacity. A backup that has stopped running is not a recovery plan.

When a reverse proxy is part of the stack, include its configuration and certificates or certificate automation settings in the recovery notes. The Traefik Docker Compose guide is relevant for readers whose services depend on a proxy-defined network and routing configuration.

For an off-site or encrypted backup

• Encrypt backups before they leave the primary server, or use a storage system with clearly understood encryption controls.
• Store encryption keys or recovery credentials separately from the backup destination.
• Restrict the backup account to the permissions it needs; avoid giving it unnecessary access to the whole server.
• Use retention tiers, such as recent daily copies, older weekly copies, and longer-lived monthly copies.
• Document how to access the off-site copy if the primary host, password manager, or network is unavailable.

Backup planning worksheet

For each service, record: service name; owner; data location; database type; backup method; schedule; retention; destination; encryption method; last successful backup; last successful restore; estimated recovery time; and the person responsible for recovery. Mark whether the service can tolerate downtime and whether the backup contains sensitive information.

What to double-check

Volumes versus bind mounts: Docker named volumes and host directories are different backup targets. Inspect the Compose file and the resolved configuration rather than assuming all persistent data is stored in one directory.

Databases: Confirm that a dump can be restored with the credentials and database version available in a clean environment. A successful file copy does not prove that the database is recoverable.

Secrets: Environment files, API keys, signing keys, SSH keys, and certificate material may be required for a complete recovery. Protect them separately and document how they are retrieved. Do not place secrets in a public repository or an unencrypted archive.

Permissions and ownership: A restore can fail when files return with the wrong UID, GID, mode, or extended attributes. Test the restored service as its normal container user, not only as root.

Integrity and visibility: Use checksums where appropriate, inspect backup logs, and alert on failures. Also watch for a different failure mode: a job that succeeds while backing up the wrong path or an empty directory.

Recovery time: Write down the order of operations: provision a host, install Docker, restore secrets, recreate networks, start the database, restore application data, start the app, update DNS, and verify access. This sequence turns an abstract backup into a usable recovery procedure.

Common mistakes

• Backing up containers instead of persistent data: A container image and writable layer do not represent the complete application state.
• Copying a live database directory: Files copied during active writes may not form a consistent database. Prefer supported dumps or database-aware replication.
• Keeping every copy on the same host: Disk failure, ransomware, accidental deletion, or a configuration error can affect all local copies.
• Never performing a restore drill: A green backup job only confirms that a process ran. It does not confirm that the service can be rebuilt.
• Forgetting configuration: Compose files, proxy rules, scheduled tasks, custom scripts, and version notes can be as important as the data.
• Ignoring retention and deletion: Unlimited retention can exhaust storage, while overly short retention can remove the copy needed after an unnoticed problem.
• Storing recovery keys with the only backup: If one incident removes both the archive and its key, encryption becomes permanent data loss.

Backups should also be part of routine server maintenance rather than an occasional emergency task. Pair this checklist with the self-hosted server maintenance checklist and review monitoring for backup failures. An uptime monitor can show that an application is reachable, but it cannot by itself prove that its data is protected; use monitoring and backup verification together.

When to revisit

Review the plan before seasonal planning cycles, infrastructure migrations, major application upgrades, and changes to storage or backup providers. Revisit it whenever you add a self-hosted app, move a service between a home server and a VPS, change database versions, replace a reverse proxy, or modify authentication and secret management.

At least periodically, perform a complete restore drill in an isolated environment. Time each stage and compare the result with your recovery-time target. Verify that users can authenticate, recent data is present, uploads open correctly, scheduled jobs work, and external integrations reconnect. Record what failed and update the runbook immediately.

Use this final recovery-time checklist:

1. Confirm the incident scope and preserve the original host if forensic or comparison work is needed.
2. Obtain an uncompromised host, the latest known-good backup, and the required recovery credentials.
3. Install the documented Docker and operating-system prerequisites.
4. Restore configuration, secrets, networks, databases, and application data in the documented order.
5. Validate the service with real application actions, not only a container health check.
6. Redirect traffic only after the restored instance is stable.
7. Record the recovery duration, missing information, and follow-up changes.

A Docker backup strategy is complete only when another person—or your future self—can use it under pressure. Keep the inventory current, encrypt off-site copies, monitor every job, and test restoration whenever the underlying workflow changes.