Backup Docker Volumes: Destroyed, Restored, and Timed

I deployed WordPress on a fresh server, filled it with posts and a thousand checksummed database rows, backed it up three ways, and then deleted every byte of its data while the site was running. On purpose. Then I brought it back from each backup tool, with a stopwatch running. Most backup guides stop at "and now your data is safe." This one starts where they stop, because a backup you have never restored is a hope, not a backup.

Everything on this page ran on a fresh Ubuntu 24.04 droplet, the same kind of box my Self Hosting 2.0 course starts from. The app is WordPress with MariaDB, but nothing here is WordPress-specific: n8n, Ghost, Nextcloud, any app with a database and a files folder has exactly the same two problems.

You are protecting two different things

Every self-hosted app with state stores it in two shapes. Files: uploads, themes, config, certificates. And a database: posts, users, orders, settings. Both usually live in Docker volumes, and if you want the full story of where a volume actually sits on disk, I took one apart in the volumes and networking guide.

The reason this distinction matters: files can be copied while the app runs. A database cannot. It rewrites its files constantly, and a copy taken mid-write is a corrupted copy. So every honest backup plan is the same two moves:

My test stack for this whole page: WordPress 6.9.4 and MariaDB 11.8.8 in Docker compose, two named volumes, seeded with posts, an uploaded image, and a sentinel table of 1,000 rows with a checksum I can verify after every restore. If the checksum matches, the restore is real. If it does not, the backup lied to me. You will see this checksum come back several times.

The trap: never copy a live database

The most common advice for Docker backups is a one-liner: tar the volume. It is in the official docs, it is all over Stack Overflow, and for a files volume it is fine. So I did exactly that to a database volume, while a writer hammered the database with inserts, the way a live app would. Three runs, same protocol each time: tar the live volume, take a proper dump under the same load, restore both, count the rows.

root@cf-docker-backups:~# bash e2_live_tar_trap.sh
--- run 1: naive tar of the LIVE db volume (what the internet tells you to do)
tar: ./ib_logfile0: file changed as we read it
--- run 1: restore the naive tar into a fresh MariaDB
NAIVE_RESTORE,run1,state=started,rows=4800,source=15400
--- run 1: restore the dump instead
DUMP_RESTORE,run1,rows=15000,source=15400,sentinel=1000 883940643
--- runs 2 and 3: same story
NAIVE_RESTORE,run2,state=started,rows=5000,source=14800
NAIVE_RESTORE,run3,state=started,rows=5600,source=15800
DUMP_RESTORE,run2,rows=14400,source=14800,sentinel=1000 883940643
DUMP_RESTORE,run3,rows=15400,source=15800,sentinel=1000 883940643

Notice tar itself tried to warn me: file changed as we read it. That warning scrolls past in a cron log and nobody reads it. Meanwhile the proper dump, taken under the exact same write load, restored a consistent snapshot all three times, sentinel checksum intact. And it was faster: the dump took 0.3 seconds against 10 seconds for the tar.

docker exec your-db-container mariadb-dump -uroot -p"$DB_PASS" --single-transaction --quick yourdb > /root/backups/db.sql

--single-transaction is the flag doing the work: it gives the dump one consistent view of the whole database while writes continue. Postgres users get the same behavior from plain pg_dump by default. That dump file now joins the files backup, and the database volume itself stays out of the backup set entirely.

The off-box destination (DO Spaces)

A backup on the same server does not help if the server itself dies. Disk failure, account lockout, a deleted droplet: same blast radius for the app and its "backup". So the backups on this page go to object storage in a different failure domain: DigitalOcean Spaces, which is S3-compatible and costs $5/mo flat for 250 GB. All three snapshots repositories from this page's tests together used 0.08% of that quota. If you would rather own the storage side too, a self-hosted MinIO on a second box speaks the same S3 protocol and every command below works unchanged.

Create a bucket (mine is cf-docker-backups in fra1), generate a Spaces access key, and note the endpoint: fra1.digitaloceanspaces.com or your region's equivalent.

restic: the default

restic is a single binary, no dependencies, and it treats S3 as a first-class home. Install it, point four environment variables at your bucket, and initialize the repository once:

cd /tmp
curl -sLo restic.bz2 https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic.bz2 && chmod +x restic && mv restic /usr/local/bin/

export AWS_ACCESS_KEY_ID=your-spaces-key
export AWS_SECRET_ACCESS_KEY=your-spaces-secret
export RESTIC_REPOSITORY="s3:https://fra1.digitaloceanspaces.com/your-bucket/restic"
export RESTIC_PASSWORD="pick-a-strong-one-and-store-it"

restic init

Then a backup is one command: the volume directory, plus the database dump from the previous section.

restic backup /var/lib/docker/volumes/yourapp_wp_data/_data /root/backups/db.sql

Here is what that actually looked like against my stack, real output:

root@cf-docker-backups:~# restic backup /var/lib/docker/volumes/cf-docker-backups_wp_data/_data /root/lab/dumps/db.sql
Files:        3354 new,     0 changed,     0 unmodified
Dirs:          372 new,     0 changed,     0 unmodified
Added to the repository: 76.140 MiB (30.648 MiB stored)

processed 3354 files, 75.155 MiB in 0:02
snapshot bb9b371f saved
root@cf-docker-backups:~# restic check
check snapshots, trees and blobs
no errors were found

The trade-off is honest: restic is a command-line tool. No dashboard, no browse button. You list snapshots with restic snapshots and restore with restic restore. If that sentence made you comfortable, restic is your tool and you can jump to the drill. If it made you uncomfortable, the next two tools trade some speed for a UI.

Kopia: the middle ground

Kopia is the same idea as restic (encrypted, deduplicated snapshots in an S3 bucket) with two additions: a policy engine that handles retention automatically at snapshot time, and an optional web UI served by kopia server. Setup follows the same shape:

curl -s https://kopia.io/signing-key | gpg --dearmor -o /etc/apt/keyrings/kopia-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main" > /etc/apt/sources.list.d/kopia.list
apt update && apt install kopia

kopia repository create s3 \
  --bucket=your-bucket --prefix=kopia/ \
  --endpoint=fra1.digitaloceanspaces.com \
  --access-key=your-spaces-key --secret-access-key=your-spaces-secret \
  --password=pick-a-strong-one

kopia snapshot create /var/lib/docker/volumes/yourapp_wp_data/_data /root/backups

Kopia was the fastest tool in my benchmarks: 2.2 seconds for the first full backup, 0.7 to 0.8 seconds for incrementals. But its bucket usage told a different story: 105 MB where restic used 43 MB for the same three snapshots.

The web UI is genuinely useful for browsing and restoring single files. One detail I respect: when I tried to expose the UI on a public port without authentication, Kopia refused to start, calling the idea exactly what it is (--allow-extremely-dangerous-unauthenticated-server-on-the-network is the flag you would have to type). Run kopia server start bound to localhost and reach it through an SSH tunnel.

Duplicati: the full GUI

Duplicati is the tool for people who want a backup product with screens: configure the job in a browser, pick sources with checkboxes, restores through a wizard. It runs happily as a Docker container itself:

docker run -d --name duplicati \
  -p 8200:8200 \
  -e DUPLICATI__WEBSERVICE_PASSWORD=pick-a-ui-password \
  -v /var/lib/docker/volumes/yourapp_wp_data/_data:/source/wp:ro \
  -v /root/backups:/source/dumps:ro \
  -v duplicati-config:/data \
  duplicati/duplicati:latest

Then open port 8200 (through an SSH tunnel, not the public internet), create a backup job, and point its destination at S3 with your Spaces endpoint and keys. The volume paths are mounted read-only into the container, which is a nice safety property: the backup tool physically cannot modify your app's data.

The honesty section: Duplicati was the slowest tool in every single test I ran. The first full backup took 26.5 seconds against 2.5 for restic and 2.2 for Kopia. The 5 MB incremental took 7 to 9 seconds against about one. The restore, which you will see next, took twice as long as the others. For a 75 MiB site none of that hurts. For 50 GB it will. Storage was fine: 44.7 MB for three snapshots, compressed and encrypted (AES) by default.

The restore drill: destroy and recover

Now the part nobody publishes. All three tools had three snapshots of the healthy site sitting in DO Spaces. I verified the app was serving, recorded the sentinel checksum one more time, and then destroyed the running app's data. Not a polite docker compose down. This:

rm -rf /var/lib/docker/volumes/cf-docker-backups_db_data/_data/*
rm -rf /var/lib/docker/volumes/cf-docker-backups_wp_data/_data/*

Both volumes emptied while the containers were live. Here is what a visitor saw four seconds later:

The recovery, per tool, is the same three moves in reverse: restore the files into a fresh volume, start the database and import the dump, start the app. I scripted the full cycle and ran it three times per tool, wiping everything back to empty volumes between runs. The clock ran from empty volumes until the site answered with the right content and the sentinel checksum matched. Nine drills, nine verified recoveries:

And the after picture, same URL that served the 403:

The restore commands, condensed to the restic version since it is my pick (the other two are the same shape through their own restore commands or UI):

restic restore latest --target /root/restore
docker volume create yourapp_wp_data
cp -a /root/restore/var/lib/docker/volumes/yourapp_wp_data/_data/. /var/lib/docker/volumes/yourapp_wp_data/_data/
docker compose up -d db          # fresh, empty database container
docker exec -i yourapp-db-1 mariadb -uroot -p"$DB_PASS" yourdb < /root/restore/root/backups/db.sql
docker compose up -d

My pick, and when to pick differently

My default is restic. It is one binary with nothing to babysit, it was at or near the front of every benchmark, its repository was the smallest, and the whole nightly setup is a 5-line script plus a systemd timer you will see in the next section. When something goes wrong at 2 AM, a single static binary with four environment variables is the tool I want to be debugging.

Pick Kopia over restic if you want to browse snapshots and restore single files through a web page, or if you like retention living inside the tool instead of inside your cron script. Turn compression on first. Pick Duplicati if you want the entire experience to be a GUI and your data is small enough that a 10× slower full backup does not matter, which for a blog or a small app it honestly does not.

In my experience the tool choice is the least important decision on this page. The dump-not-copy rule and the off-box destination are what save you. Pick any of the three, run the drill once, and you are ahead of most production setups I have seen.

Put it on a schedule (with retention)

A backup that depends on you remembering it is a backup that stops the week you get busy. Here is the complete nightly setup for restic. First the script. Save it as /usr/local/bin/backup-stack.sh and make it executable: it does the dump, the backup, and retention in one pass.

#!/usr/bin/env bash
set -euo pipefail
docker exec yourapp-db-1 mariadb-dump -uroot -p"$DB_PASS" --single-transaction --quick yourdb > /root/backups/db.sql
restic backup /var/lib/docker/volumes/yourapp_wp_data/_data /root/backups/db.sql
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Then a systemd service, saved as /etc/systemd/system/backup-stack.service. Credentials live in a root-only env file, not in the script:

[Unit]
Description=Nightly restic backup of the docker stack
[Service]
Type=oneshot
EnvironmentFile=/root/restic.env
Environment=HOME=/root
ExecStart=/usr/local/bin/backup-stack.sh

And its timer, saved as /etc/systemd/system/backup-stack.timer:

[Unit]
Description=Run the stack backup nightly
[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=15m
Persistent=true
[Install]
WantedBy=timers.target

systemctl daemon-reload && systemctl enable --now backup-stack.timer

The forget line is retention: keep 7 daily, 4 weekly, 6 monthly snapshots, delete what falls outside, and --prune actually reclaims the space. I tested that it does what it claims by planting backdated snapshots: 10 snapshots went in, the policy kept 8, and the two oldest were really gone from the bucket afterward. Kopia does the same thing without the cron line, through kopia policy set --global --keep-daily 7 --keep-weekly 4 --keep-monthly 6, applied automatically every time a snapshot is created. Duplicati takes --retention-policy="1W:1D,4W:1W,12M:1M" as a job option.

That is the whole system. Nightly dump, nightly off-box backup, automatic retention, and a restore you have personally watched work. The last piece is knowing your schedule actually fires: systemctl list-timers backup-stack.timer shows the next run, and this pairs well with the container update habit, because "backup before updating" stops being advice and starts being one command you already have.

FAQ

• Updated August 2026
• Tested on Ubuntu 24.04
• restic 0.19.1
• Kopia 0.23.1
• Duplicati official Docker image
• Restore drills 9/9 verified
• Difficulty Beginner-friendly

Related

• Docker Volumes & Networking what a volume actually is and where your data lives on disk
• Keep Docker Containers Updated the other half of the maintenance habit: backup, then update
• Self-Host WordPress the app this page deliberately destroyed, set up properly
• Self Hosting Hub every self-hosting guide on the site

Restore once. Then it is a backup.

Hasan Aboul Hasan builds open-source tools and teaches solo developers how to build, host, and sell AI-powered products. Founder of LearnWithHasan.com, creator of SimplerLLM and PyRunner.