Don’t backup the container!!

Map volumes with your data to physical storage and then simply backup those folders with the rest of your data. Docker containers are already either backed up in your development directory (if you wrote them) or GitHub so like the operating system itself, no need tk backup anything. The whole idea of Docker is the containers are ephemeral. They are reset at every reboot.

I have my config and data volumes mounted to a share on truenas, that share replicates its snapshots to another truenas server. This is likely not ideal for everyone, but it works for me. My friend that also uses docker has it backed up with duplicati.

KISS method: Script that copy the data on the fly to the /tmp dir, compress it, encrypt it and move it to destination using rclone. Running every hour, 4 hours or 24 hours, depending the container.

Never fails. The backups nor the restore.

I used to let root start the backup job

First, I try not to have it owned by root. But some containers have special privileges that need to be followed.

So rsync -O will copy the directory retaining permissions and ownership of all files.

I converted they to use Podman.

From my basic selfhosted experience… I run kopia as root , my shit uses bind mounts so all I care about is in that directory.

And so far it works fine, to just down old, rename the directory, copy from nightly backup back the directory and start container.

But yeah if there is something I care about I schedule database dumps like here in bookstack or vaultwarden…

To have something more if shit would not work start.

only backup of the data i need to backup (mapped volumes).

Restore: create fresh container and map volumes again.

This is one reason I prefer FreeBSD jails. They are each in a separate ZFS filesystem, with a separate filesystem for configuration files. So all I have to do is regular snapshots and send those to a backup pool.

All Docker containers have their persistent data in Docker volumes located on a BTRFS mount. A cronjob takes a snapshot of the BTRFS volume, then calls btrfs send, pipes that through tar and gpg and then directly to AWS S3.

i don’t, i created a docker VM (and a couple others) and then i backup the VMs (proxmox + PBS make this very easy) with all their data in /home/docker/config/*

i used to have them run off networked storage but i found it to be to slow/have other issues

this also means for the primary important services that VM runs in HA and moves to another node when needed

I use a Synology Nas with Active backup for business and back up the VMs that host the containers.

sudo crontab -e

I do this at the file system level, not the file level, using zfs.

Unless the container has a database, I use zfs snapshots. If it has a database, my script dumps the database first and then does a ZFS snapshot. Then that snapshot is sent via sanoid to a zfs disk that is in a different backup pool.

This is a block level backup, so it only backs up the actual data blocks that changed.

For backups I use Nautical Backup.

For the “owned by root” problem, I ensure all my docker compose files have [P]UID and [P]GID set to 1000 (the user my docker runs under). All my 20 containers have no issue running like this.

How are you launching your containers? Docker compose is the way, I have set the following in all mine:

environment:
  - PUID=1000
  - PGID=1000

user:
  1000:1000