Encrypted Docker volume backups.
xbackupman backs up Docker named volumes by reading them directly from the daemon — no need to stop your containers. The volume contents are tarred, encrypted with AES-256-GCM in the worker, and stored in a bucket you own.
What gets captured
- The full contents of a named Docker volume — database data dirs, uploads, or any persisted state.
- A tar archive read straight from the daemon, so running containers keep serving during the backup.
- In-stream gzip compression and AES-256-GCM encryption applied in the worker before upload.
- A SHA-256 checksum stored with each snapshot for on-demand integrity verification.
How it works
Reach the Docker host
Give xbackupman access to the Docker host over SSH and name the volumes you want to protect. No sidecar container is left running on your host.
Read the volume live
The worker archives the named volume's contents directly through the daemon, so you don't have to stop or pause the containers that use it.
Compress, encrypt, upload
The archive is gzipped and sealed with AES-256-GCM in the worker, then the ciphertext is uploaded to your own S3-compatible bucket.
Verify and retain
Every archive is SHA-256 checksummed. Schedule it on any cadence and let retention prune old snapshots while keeping your last remaining copy safe.
Your storage, your keys
Your volume archives are written to your own bucket — S3, R2, B2 or MinIO. The archive is encrypted in the worker before upload, so your storage provider only ever holds ciphertext. Your persisted container state stays fully in your custody, on infrastructure you control.
xbackupman never stores your backups on its own servers. It orchestrates the pipeline and records metadata — the encrypted artifacts live only in the S3-compatible bucket you connect. See how encryption works.
One-click restore
Restore unpacks the volume archive onto a target volume — a fresh, empty one by default — so you can rehydrate state without disturbing the live volume. Because it is a standard gzipped tar of the volume contents, you can also download it and unpack it into any Docker host yourself.
Questions
QDo I have to stop my containers to back up a volume?
No. The volume is read live through the daemon, so containers keep running. For strict consistency of a database volume you can still quiesce the container, but it isn't required to capture a backup.
QWhich volumes can I back up?
Any named Docker volume — a Postgres or MySQL data directory, an uploads volume, or any other persisted state your containers mount.
QCan I restore into a different Docker host?
Yes. The archive is a portable gzipped tar of the volume contents, so you can rehydrate it into a fresh volume on the same host or a different one entirely.
QShould I back up the volume or dump the database inside it?
Both are valid. A volume backup captures on-disk state as-is; a logical database dump (Postgres, MySQL, Mongo) is more portable across versions. Many teams run both on different cadences.
Back up more
One engine covers every source you run — on a single schedule, in one dashboard, encrypted into the same storage.