How to Backup Docker Volumes on a VPS: Practical Persistence Guide

Docker volumes are the point where the container abstraction meets the reality of the disk. A container is disposable — you rebuild it from the image in minutes. A volume is where the real state lives: databases, user uploads, persistent settings. Losing a volume means losing production data.

Despite this, volume backups are the most neglected part of the Docker stack. Most VPSes running containerized applications have no backup routine in place, only the false security that “everything is in a container”. When the disk fails or someone runs docker volume prune distractedly, the loss is final.

This tutorial walks through practical strategies for backing up Docker volumes on a Linux VPS, covering static data, databases, and cron-based automation. Estimated execution time: 25-40 minutes to configure the first backup and validate the restore.

Prerequisites

Confirm the Docker version and list your volumes before starting:

docker --version
docker volume ls

Identifying affected volumes and containers

Before backing up, map which containers use each volume. A blind backup that ignores dependencies causes inconsistency — you may capture the database file in the middle of a transaction if the container is writing.

docker volume ls --format '{{.Name}}'

docker ps -a --filter volume=volume_name --format '{{.Names}}: {{.Image}}'

docker volume inspect volume_name

sudo du -sh /var/lib/docker/volumes/volume_name/_data

Backing up static data with tar

Static data — user uploads, configs, assets — can be copied while the container is running. The risk of inconsistency is low because atomic writes (mv, rename) preserve the previous state until the operation completes.

The standard strategy uses a temporary Alpine container with the volume mounted in read-only mode, creating the tarball in a directory on the host.

sudo mkdir -p /var/backups/docker-volumes
sudo chmod 700 /var/backups/docker-volumes

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

Consistent database backups

Databases are the most delicate case. Copying the binary files (MySQL datadir, PostgreSQL base/) while the engine is running yields a corrupted backup — writes in flight, unflushed WAL, inconsistent indexes. The solution is to use the engine’s native dump tool.

docker exec mysql_container_name \
  sh -c 'mysqldump --single-transaction --quick \
    -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases' \
  | gzip > /var/backups/docker-volumes/mysql-$(date +%Y%m%d-%H%M%S).sql.gz

docker exec pg_container_name \
  pg_dumpall -U postgres \
  | gzip > /var/backups/docker-volumes/postgres-$(date +%Y%m%d-%H%M%S).sql.gz

docker exec mongo_container_name \
  mongodump --archive --gzip \
  > /var/backups/docker-volumes/mongo-$(date +%Y%m%d-%H%M%S).archive.gz

Automation with cron

Manual backups don’t scale — you forget, or only do it when you remember (usually when you need to restore). Cron solves this. The recipe below creates a script wrapping the routine and schedules daily execution.

#!/bin/bash
set -euo pipefail

BACKUP_DIR=/var/backups/docker-volumes
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=14

# Backup MySQL
docker exec mysql_container \
  sh -c 'mysqldump --single-transaction --quick \
    -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases' \
  | gzip > "$BACKUP_DIR/mysql-$TIMESTAMP.sql.gz"

# Backup static volume
docker run --rm \
  -v uploads_volume:/source:ro \
  -v "$BACKUP_DIR":/backup \
  alpine \
  tar czf "/backup/uploads-$TIMESTAMP.tar.gz" -C /source .

# Clean up old backups
find "$BACKUP_DIR" -name "*.gz" -mtime +$RETENTION_DAYS -delete

sudo chmod 700 /usr/local/bin/docker-backup.sh
sudo crontab -e

0 3 * * * /usr/local/bin/docker-backup.sh >> /var/log/docker-backup.log 2>&1

Verification and restore

A backup that has never been tested isn’t a backup — it’s a file. Validate the restore periodically, ideally on a staging VPS.

To restore a static-data volume:

# Create empty volume
docker volume create uploads_restored

# Restore content
docker run --rm \
  -v uploads_restored:/target \
  -v /var/backups/docker-volumes:/backup \
  alpine \
  sh -c 'cd /target && tar xzf /backup/uploads-20260529-030000.tar.gz'

To restore MySQL:

gunzip -c /var/backups/docker-volumes/mysql-20260529-030000.sql.gz \
  | docker exec -i mysql_container mysql -u root -p"$MYSQL_ROOT_PASSWORD"

After restoring, validate integrity — for MySQL, run CHECK TABLE on the main tables; for application data, start a container pointing to the restored volume and verify functionality.

Troubleshooting

”Cannot create container: volume in use”

Appears when you try to delete or rename a volume mounted on an active container. Stop the container first with docker stop before manipulating the volume. Backing up with :ro mounts the volume in parallel without conflict.

Corrupted tarball during restore

Symptom: tar: Unexpected EOF in archive. The common cause is the disk filling up during backup — the file was truncated. Always monitor free space (df -h) before running the backup, and add a verification step to the script: tar tzf file.tar.gz > /dev/null && echo OK.

Slow backup even on SSD

Check whether the backup is being written to the same disk as the original volume — I/O contention cuts throughput in half. Backing up to a separate disk (additional block storage or network) speeds things up significantly. On a Hostini VPS, you can add a separate block volume via the panel to dedicate to the backup area.

Next steps

With backups configured and validated, consider the next levels of maturity: implementing incremental backups with restic or borg for large volumes (cuts time and space by ~80%), configuring alerts in the script to notify on failure via webhook or email, and separating backups by window (daily 14 days, weekly 8 weeks, monthly 12 months) to cover different recovery scenarios.

If you’re putting this into production, a Hostini VPS comes with NVMe SSD and an optional dedicated block volume for backups, which eliminates I/O contention between live data and backup copies. For critical workloads, also consider synchronous replication to another region — backups solve data loss, replication solves downtime.