How Do You Back Up Docker Volumes and Databases Properly?
Tech GuruQuick Answer
Back up each Docker application's data, Compose definition, approved image versions, configuration, and recoverable secrets. Use the database engine's supported backup method, and coordinate it with uploaded files and other writable state. Keep encrypted local and offsite recovery copies. Test the complete set in an isolated stack with empty volumes: an archive that opens or a container that starts does not prove the application has recovered.
Why This Matters Now
Define the recovery unit before choosing a backup command: the Compose application, its database engine, uploaded files, bind mounts, named volumes, secrets, and external dependencies. A container image can be recreated; live state and database consistency cannot. The useful answer depends on whether the application can be quiesced, dumped correctly, and rebuilt in a clean stack within its required recovery window.
A Compose file is easy to recreate; the volume and database state are the valuable parts.
Copying a live database directory can produce a broken backup unless the database is stopped or dumped correctly.
Restore testing is the only way to know whether secrets, networks, volume paths, and database credentials were captured.
The workflow below builds one recovery set from the Compose definition, approved image versions, configuration, protected secrets, application files, and a database-aware dump, then stores it in an encrypted repository and restores it under a new project. A backup job passes only when the rebuilt application can authenticate and read its expected records and files, not when an archive command merely exits successfully.
Recommended Baseline
Keep production volumes and databases separate from a fast local backup repository and an offsite repository copy with independent credentials. Place a PostgreSQL or MariaDB logical dump beside the protected bind mounts and named-volume data, then include the Compose file, approved image references, configuration, and secret-recovery instructions. The offsite copy must remain usable when the Docker host and its local credentials are unavailable.
Do not treat a live database volume as an ordinary folder for sync or file-copy tools. A copy taken across active transactions may be inconsistent, and synchronization can propagate damaged state over a good copy. Use pg_dump, pg_dumpall, mariadb-dump, mysqldump, or the engine's documented backup method, or stop the writer when a filesystem-level copy requires it, then retain versioned history under separate credentials.
Decision Matrix
| Choice | Best Fit | Watch Point |
|---|---|---|
| Volume file copy | Static app data and uploads. | Unsafe for busy databases. |
| Database dump | PostgreSQL, MariaDB, MySQL, Redis exports. | Needs scheduling and retention. |
| Restic/Borg/Kopia | Encrypted deduplicated backups. | Still needs app-aware pre/post hooks. |
| Storage snapshots | Fast local rollback. | Not a full offsite backup alone. |
Decision Worksheet
List every service, approved image reference, named volume, bind mount, database engine and name, dump command, secret location, network, external dependency, exclusion, recovery point, recovery time, and startup order in the worksheet. A static web container and a photo application backed by PostgreSQL need different consistency controls, even when both appear as a few services in one Compose file.
| Record | Capture | Restore check |
|---|---|---|
| Application | Compose project, approved images, engine/version, and dependencies. | Start a separate project without borrowing production state. |
| Writable state | Every bind mount, named volume, upload path, and its writer. | Confirm the database and files belong to a coordinated recovery point. |
| Database | Supported backup method, dump timestamp, roles, extensions, and restore order. | Import into a compatible empty instance and verify application records. |
| Secrets | Protected retrieval location and authorized recovery account; do not record secret values here. | Recover credentials without access to the failed Docker host. |
| Recovery targets | Maximum tolerable data loss and outage, backup interval, retention, and capacity. | Compare the restored recovery point and elapsed time with those targets. |
| Acceptance | Login, required uploads, representative reads/writes, ownership, and errors. | Keep the original data and previous backups until the isolated test passes. |
Database-Aware Backup Examples
Choose the engine's supported backup method: PostgreSQL logical dumps, MariaDB/MySQL dumps, SQLite's supported online backup method or a stopped writer, and the application's documented Redis persistence procedure. In PostgreSQL, pg_dump covers one database, not cluster-wide roles and tablespaces; capture required globals separately. Its consistent database snapshot does not synchronize uploaded files or other databases. Coordinate those writers before treating their backups as one recovery set.
A safe pattern is pre-backup dump, encrypted repository backup with Restic/Borg/Kopia, repository check, and restore into a clean Compose stack. If the restore requires secrets that exist only in the dead host's .env file, the backup is incomplete.
Real-World Example
Consider a Compose application with PostgreSQL, uploaded files, and a reverse proxy. Its recovery set needs a logical database dump, the upload bind mount, application configuration, the Compose definition, the tested image versions, and a protected way to recover secrets. Back up that set to local and offsite repositories. The example succeeds only when a new project can import the dump, attach the restored files, and start without borrowing live state from production.
Protect state in recovery order: database dumps and user uploads first, then application configuration, keys and secrets, Compose definitions, approved image versions, and operator notes. Regenerable thumbnails, package caches, transcode scratch space, and container layers can usually be excluded. Map each protected path to the service that writes it and the command that restores it; a volume name by itself does not explain consistency or startup order.
Copying /var/lib/docker/volumes while a database is active may capture an unusable point in time; saving only the database dump can omit uploads and configuration; saving only Compose recreates empty services. Pair an application-aware export with protected filesystem state and host-independent credentials, then validate the combination under a different Compose project name and network instead of writing over production.
Rollout And Recovery Plan
Implement backup one stack at a time. Pin the image versions, inventory state, create the database dump step, back up the dump with volumes, bind mounts, configuration, and recovery material, check the repository, and restore into an isolated project. Start with a lower-criticality application, and do not prune previous snapshots until the dump, repository check, retention behavior, and full application restore have been reviewed.
For the recovery test, provision empty volumes and directories, restore the Compose and configuration material, recover secrets through the documented protected path, load the database dump with the engine's supported command, and restore uploads with the intended ownership. Start dependencies in order and verify login, expected records, and required files. Record exact application and database versions and never perform this test by overwriting production data.
Implementation Details
Choose a backup window in which application writes can pause or the selected database tool guarantees a consistent online dump. Notify users, stop only the writers required by the method, create the dump, capture filesystem state, restart services, and review application health. Do not combine a new backup procedure with an image or database major-version upgrade; rollback needs the previous image, schema-compatible dump, configuration, and files.
- List every Compose project, volume, bind mount, database, and secret file.
- Add database dump jobs for PostgreSQL, MariaDB/MySQL, SQLite, Redis, and app-specific exports.
- Back up Compose files,
.envtemplates, reverse proxy config, and documentation. - Encrypt backups before sending them offsite.
- Run a restore drill into a clean Docker host.
Record these details while you build, not after the memory has already gone fuzzy:
- Usable capacity after parity, mirrors, snapshots, and retention.
- Restore time for a realistic folder, VM, app database, or photo library.
- Offsite copy age and whether backup credentials are separate from normal user credentials.
- Drive health, scrub status, alert delivery, and UPS shutdown behavior.
Evidence To Collect
Keep a backup record containing the dump command and result, dump size trend, repository snapshot identifier, included and excluded paths, integrity-check outcome, isolated restore steps, and application acceptance result. Redact secrets from logs and screenshots. These are checks for the reader to perform; TechGeeks did not execute the example commands, and an archive listing alone does not establish database consistency.
- A data inventory that separates irreplaceable, painful-to-recreate, and disposable data.
- Screenshots or logs from the latest backup job, snapshot job, scrub, SMART check, and offsite sync.
- A restore note showing what was restored, where it was restored, how long it took, and what did not come back cleanly.
- A credential note proving backup administration is separate from normal daily user access.
- Capacity math that includes snapshots, retention, app databases, photo growth, and replacement-drive budget.
Failure Signals
- Backups complete but nobody has restored from them.
- Snapshots and sync jobs live on the same system as the only important copy.
- Drive, UPS, or scrub alerts go to an inbox nobody checks.
- Cloud-only files, app databases, or metadata are missing from the backup plan.
Validation Checklist
- A new host can start the Compose stack from backed-up files.
- Database dumps import cleanly.
- Uploaded files and app media are present after restore.
- Secrets are restored from a secure location, not committed to Git.
- Backup logs and alerts are checked.
Common Mistakes
- Backing up only the Compose YAML.
- Copying live database directories without the engine's supported consistency procedure; an uncoordinated snapshot is not a substitute.
- Committing
.envsecrets to a public repository. - Using one backup job for every app without understanding data consistency.
- Never testing restore after changing volume paths.
Troubleshooting
| Symptom | Likely Cause | First Check |
|---|---|---|
| Restore fails | Backup captured files but missed app state, permissions, keys, or database exports. | Restore to a clean folder or VM and compare timestamps, permissions, and app behavior. |
| Storage feels slow | Network, disks, protocol overhead, Wi-Fi, or client limits are the real bottleneck. | Test wired transfer speed, disk health, and client link speed separately. |
| Backups look successful but feel risky | Jobs report completion without proving recovery. | Schedule a restore drill and record exactly what did and did not come back. |
Maintenance Cadence
Monitor dump age and size trends, repository checks, retention, offsite replication, and the availability of decryption keys and repository credentials on a schedule tied to the application's recovery point. Repeat the isolated restore after a database major upgrade, application schema migration, image change, new volume, changed bind path, secret rotation, or backup-tool update; yesterday's working command may no longer describe today's stack.
- After each backup: Check dump and repository results and alert when local or offsite recovery points exceed the allowed age. Review drive health and free space routinely.
- Quarterly: Restore a real folder or app export to a clean location and confirm permissions, metadata, and versions.
- Yearly: Review capacity, replace aging drives or UPS batteries as needed, and confirm the offsite copy still matches the risk.
The Docker restore test must rebuild an application, not merely extract files. Create an empty project with the recorded image versions, restore volumes and bind mounts, recover secrets, import the logical database dump, apply ownership, and verify expected records and uploads. Reach the encrypted offsite repository without relying on credentials stored only on the Docker host; otherwise a dead host still blocks recovery.
When To Spend Money
Before choosing an external SSD, NAS target, or cloud repository, calculate protected volume and dump size, change rate, retention, recovery point, recovery time, encryption, and any retrieval constraints. Fast local media can shorten a common restore; an offsite repository covers host or site loss. Buy more throughput only after an observed backup or restore misses its window, because storage cannot compensate for an omitted dump, secret, or bind mount.
| Stage | Signal | Practical Buying Guidance |
|---|---|---|
| Do not buy yet | Restore has not been tested, data has not been tiered, or the existing bottleneck is unknown. | Spend time on inventory, restore proof, labels, and documentation before buying another enclosure. |
| Small useful spend | Backups are working but the weak point is power, replacement media, or offsite transport. | UPS with shutdown signaling, external backup drive, spare drive, drive labels, or a safe storage case. |
| Larger upgrade | Capacity, restore time, drive bays, network throughput, or app-data reliability is now a measured constraint. | NAS, larger disks, 2.5GbE/10GbE path, offsite target, or a separate compute host. |
Useful Gear And Buyer Notes
The product links below are intentionally search links, starting with external SSD 2TB, because model numbers, bundles, and prices change quickly. Use them to compare categories, then verify exact specifications against the article's decision points before buying. For infrastructure gear, prioritize firmware support, replaceability, warranty, idle power, and recovery behavior over headline specs.
Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.
- Amazon search: external SSD 2TB
- Amazon search: NAS hard drive 8TB
- Amazon search: mini PC Docker server
- Amazon search: USB hard drive dock
Related TechGeeks resources
- Media Server Storage Design: NAS, CIFS/NFS Mounts, Permissions, and Local Cache
- Backup and Disaster Recovery for Plex, Sonarr, Radarr, Tdarr, Prowlarr, and SABnzbd
- Monitoring and Health Checks for a Plex and Arr Homelab
What This Does Not Protect or Validate
A successful database dump does not prove bind mounts, uploaded files, encryption keys, secrets, compose definitions, or external dependencies were captured. A backup job exit code also does not prove the archive is readable or transactionally consistent. This guide is documentation-backed; TechGeeks did not execute the example commands against a production database.
Backups may contain credentials, personal data, application tokens, and deleted records, so encrypt them, separate backup credentials from the Docker host, restrict retention, and follow contractual or legal deletion requirements. Recovery requires documented image versions, configuration, keys, application-aware dumps, and a restore test into an isolated stack before the original data is overwritten.
Docker named volumes, host snapshots, RAID, sync, and repository copies each protect a different layer; none alone proves transactionally consistent database state or a complete application rebuild. Recovery is demonstrated only when the recorded image, Compose definition, configuration, secrets, logical dump, and filesystem data restore into an isolated stack that starts with the expected state. This documentation-backed guide does not report such a TechGeeks test.
