How to Back Up Docker Volumes in 2026: A Self-Hosted Guide

To back up a Docker volume, you mount it into a temporary container and archive it — you cannot just copy the folder under /var/lib/docker/volumes and trust it. The one-liner that works for most volumes is a throwaway Alpine container that tars the data to a file you control. The harder truth, and the part most tutorials skip, is that a live database volume copied this way is often subtly corrupt, and a backup you have never restored is not a backup. This guide covers the exact commands, how to handle databases correctly, how to automate and push copies off-site, and how to prove the backup actually works.

How do you back up a Docker volume?

The standard method is to run a short-lived container that mounts your named volume read-only and writes a compressed tarball to a bind-mounted directory on the host. A single command handles it:

docker run --rm \
  -v mydata:/source:ro \
  -v $(pwd)/backups:/backup \
  alpine tar czf /backup/mydata-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

This spins up Alpine, mounts the mydata volume as /source (read-only), and writes a timestamped .tar.gz into ./backups on the host. The OneUptime backup guide uses this same read-only tar pattern, which is the closest thing to a canonical approach. It works because Docker's own docs note volumes are easier to back up than bind mounts — the data lives in one managed location. For a stateless app cache or a file store, this is all you need. For anything holding a database, it is not.

Why copying a live volume is not enough

Filesystem-level backups assume the files on disk are in a consistent state at the moment you read them. A running database rarely is. Postgres, MySQL, and MongoDB buffer writes in memory and flush them to disk on their own schedule, so tarring a live data directory can capture a half-written transaction or an index that points at rows that have not landed yet. The restore then fails, or worse, silently loads corrupt data. The rule of thumb from practitioners is that database-specific dumps are transactionally consistent, unlike filesystem-level backups. You have two safe options: stop the container before the tar (fine for a home lab, bad for anything that needs uptime), or use the database's own dump tool while it keeps running. The second is almost always the right answer.

Back up databases with dumps, not tar

For a containerised database, take a logical dump with the engine's native tool and back up the dump file instead of the raw volume. This produces a consistent snapshot even while the database serves live traffic. For Postgres, pg_dump with --single-transaction gives a consistent point-in-time export without long locks, per the official PostgreSQL documentation:

docker exec -t my-postgres \
  pg_dump -U postgres --single-transaction mydb \
  | gzip > backups/mydb-$(date +%Y%m%d).sql.gz

MySQL and MariaDB use mysqldump --single-transaction (consistent for InnoDB tables); MongoDB uses mongodump. The order matters when you automate: dump the database first, then run your volume or off-site backup over the directory that now contains the fresh dump. If you self-host a full backend stack, the same logic applies to Postgres running under it — the production Supabase self-host guide leans on the same dump-then-store pattern rather than copying data files.

Automate it: tools vs restic

Running these commands by hand once is easy; remembering to run them every night is where self-hosters fail. Two mature approaches automate the whole loop. A purpose-built container like offen/docker-volume-backup handles scheduling, rotation, and upload in one image: it backs up volumes to S3, WebDAV, Azure Blob, Dropbox, Google Drive or SSH targets, with optional GPG encryption and automatic rotation of old backups, and can stop a container during the run for integrity when you label it to. The alternative is restic, which gives encrypted, deduplicated, incremental backups to almost any backend — a common pattern keeps --keep-daily 7 --keep-weekly 4 --keep-monthly 6 and, because of deduplication, each nightly run only stores what changed.

Method	Online (no stop)?	Off-site targets	Encryption	Best for
tar one-liner	No (stop for DBs)	Manual copy	None (add GPG)	Quick, ad-hoc snapshots
offen/docker-volume-backup	Optional stop	S3, WebDAV, Azure, Dropbox, GDrive, SSH	GPG	Set-and-forget volume backups
restic	Yes (with dumps)	S3, B2, SFTP, REST, local	Built-in	Deduplicated, versioned history
DB dump (pg_dump)	Yes	Pipe to any of the above	Via target	Databases, always

For most self-hosted stacks the winning combination is a nightly pg_dump (or mysqldump) feeding a restic run that pushes an encrypted, deduplicated copy off the box.

Apply the 3-2-1 rule and go off-site

A backup on the same VPS as the data protects you from a bad deploy, not from the server dying, a billing lapse, or ransomware. The long-standing 3-2-1 rule fixes that: keep 3 copies of your data, on 2 different media, with 1 off-site. In practice that means the live volume, a local backup directory, and one copy on remote object storage. Off-site storage is cheap enough that cost is no excuse. As of July 2026, Hetzner's Storage Box BX11 is €3.20/month for 1 TB over SSH/SFTP — a natural restic or rsync target — while Backblaze B2 runs about $7 per TB per month with an S3-compatible API that both restic and offen/docker-volume-backup speak natively. Either turns off-site backup into a few euros a month. If you are already watching your bill after the 2026 VPS price increases, object storage for backups is the last place to cut.

Restore it — and test the restore

The restore is the only part of a backup that actually matters, and it is the step almost everyone skips. To restore a tar backup, stop the container, then extract the archive back into the (empty) volume:

docker run --rm \
  -v mydata:/target \
  -v $(pwd)/backups:/backup:ro \
  alpine tar xzf /backup/mydata-20260717-120000.tar.gz -C /target

For a database dump, load it into a fresh container and check the schema and row counts before you trust it. Schedule a real restore drill — monthly is reasonable — into a throwaway container, bring the app up against the restored data, and confirm it works. A backup you have never restored is a hope, not a recovery plan. Bake this into your workflow the same way you would harden a new box in the secure first hour of a VPS setup.

Frequently asked questions

Can I back up a Docker volume without stopping the container? Yes, with a caveat. For file stores and caches, mounting the volume read-only and tarring it while the container runs is fine. For databases, do not tar the live volume — use the engine's dump tool (pg_dump, mysqldump, mongodump) instead, which produces a consistent export without stopping the service.

Where are Docker volumes actually stored? On Linux, named volumes live under /var/lib/docker/volumes/<name>/_data. You can technically copy that directory, but backing up through a container (or a dump for databases) is safer and portable across hosts, which is why Docker's documentation recommends the volume-mount approach.

What is the best tool to automate Docker volume backups? For hands-off volume backups with built-in scheduling, rotation, and cloud upload, offen/docker-volume-backup is the most popular single-container option. For deduplicated, encrypted, versioned history across many backends, restic is the stronger choice. Many setups combine a nightly database dump with a restic push off-site.

How often should I back up? Match the frequency to how much data you can afford to lose. Nightly is the common default for self-hosted apps; a busy database might warrant hourly dumps. Whatever the cadence, keep several generations (for example 7 daily, 4 weekly, 6 monthly) so a corruption you notice late is still recoverable.

Sources

• OneUptime — How to Back Up and Restore Docker Volumes: the read-only tar backup and restore commands, and the point that database dumps are transactionally consistent where filesystem backups are not.
• Docker Docs — Volumes: official guidance that volumes are easier to back up and migrate than bind mounts, and where volume data is stored.
• PostgreSQL Documentation — pg_dump: the --single-transaction consistent-dump behaviour for live databases.
• offen/docker-volume-backup (GitHub): supported storage backends, GPG encryption, scheduling, container stop-during-backup, and rotation.
• restic: encrypted, deduplicated, incremental backups across multiple storage backends.
• Hetzner Storage Box and Backblaze B2 pricing: off-site storage costs cited (July 2026).