How Do You Back Up Docker Volumes and Databases Properly?
Tech GuruBack up Docker by backing up the data, configuration, and restore instructions, not the running container. For databases, use application-aware dumps or backup tools, then store those dumps with the volume backups and test restore into a new stack.
Design principle: Separate working data, local recovery, and offsite recovery. One box can help, but one box should not be the whole plan.
The Short Version
- Back up Docker by backing up the data, configuration, and restore instructions, not the running container. For databases, use application-aware dumps or backup tools, then store those dumps with the volume backups and test restore into a new stack.
- Use the decision matrix below, then prove the result with the validation checklist before making it the default.
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.
| Worksheet Item | What To Write Down | Why It Matters |
|---|---|---|
| Primary question | How do I back up Docker containers and databases properly? | This keeps the article tied to the reader's real decision instead of drifting into a generic product comparison. |
| Affected systems | People, apps, and devices that create or need the files, photos, backups, databases, or shares. | Readers should know who and what they are protecting before they choose hardware, software, or a cloud service. |
| Failure model | Deletion, ransomware, drive failure, bad sync, account lockout, theft, fire, and hardware replacement. | Different failures need different controls. This row prevents RAID, sync, VPN, or MFA from being treated as magic. |
| Proof test | Restore a real folder, one recently changed file, and one app-owned data set to a clean location. | A recommendation is not proven until it survives a small, repeatable test using realistic data, clients, or accounts. |
| Rollback path | Keep the original copy and credentials available until restores, permissions, and metadata are confirmed. | A reversible change is less stressful, easier to explain, and less likely to turn a weekend project into an outage. |
| Measurement to capture | Usable capacity after parity, mirrors, snapshots, and retention. | Numbers, logs, screenshots, or restore notes give the reader confidence that the decision was based on evidence. |
Database-Aware Backup Examples
A stopped container is easy to recreate; the live data is not. PostgreSQL wants pg_dump or pg_dumpall for logical backups. MariaDB and MySQL want mariadb-dump or mysqldump. SQLite often needs the app stopped or a proper online backup method. Redis may need RDB/AOF handling depending on the app.
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.
Adopt, Pilot, Defer, Avoid
- Adopt: Adopt the design when it separates working data, local recovery, and offsite or offline recovery.
- Pilot: Pilot with one folder, one app export, or one photo subset before reorganizing the whole data set.
- Defer: Wait when the current setup is stable, backed up, monitored, and the proposed change is mostly curiosity.
- Avoid: Avoid treating RAID, snapshots, sync, or cloud drive alone as a complete 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 dumps or snapshots.
- 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.
- Monthly: Check backup job status, drive health, free space, and the age of the newest offsite copy.
- 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.
Practical FAQ
How do I back up Docker containers and databases properly?
Back up Docker by backing up the data, configuration, and restore instructions, not the running container. For databases, use application-aware dumps or backup tools, then store those dumps with the volume backups and test restore into a new stack. The important next step is to validate the recommendation with one small test before treating it as the default.
Sources
- Docker Compose documentation
- PostgreSQL SQL dump documentation
- MariaDB dump documentation
- restic documentation
- BorgBackup documentation
- NIST SP 1800-11: Data Integrity and Recovery
Final Thought
The right answer is the one you can operate, document, test, and recover without guessing.
Need help applying this?
Bring TechGeeks into the real environment.
If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.
