Backup Docker Data

1

While running some services in Docker on a VPS, those docker images uses MariaDB/MySQL/PostgreSQL or whatever.

What’s the best backup strategy for backing up all the Docker data?
The files/data should all be in /var/docker/* and in the ./data_dir I defined in docker-compose.yml.
But should I make the backup script stop (docker compose down) the container(s) to make sure the databases would be restorable from backups?
Or maybe there’s some other smart function/way I should explore/utilize? :sweat_smile:

2

Borgmatic has you covered :slight_smile:

You can simply use Docker to run Borgmatic. Personally, I need to switch to borgmatic still as I’m on bash scripts I wrote a decade ago invoking Borg directly, but the concept is the same. I’m backing up all my volume mounts (they all live under ~/docker in my case) and dumps of the MySQL and Postgres databases (Borgmatic dumps them for you when you define databases in the configuration file which is very convenient, I’m invoking mysqldump and pq_dump from my script manually).

This way, you can take backups whilst your containers are online and simple restore from the database dumps when needed.

2 Likes
3

I just sync my databases to a shared hosting provider (which has its own backups) :joy:

4

Hm, borg needs something running on the target? Not possible to backup to an rclone target? :nerd_face:

5

How much data do you need to backup? 10G Free at https://www.borgbase.com/ or I’m pretty sure Hetzner’s boxen are Borg capable as well.

6

I am moving my bookmarks from Pocket to Raindrop and I ran in to this:

https://roll.urown.net/NAS/borg-backup-server.html

This is how to setup a Borg Backup Server on a Synology DiskStation, so it can be used by Borg Backup clients as backup storage location.

7

You need something on the target, for me personally that’s a slice + slab. I rclone to different alternative storages (e.g. Backblaze) from there.

8

Very possible. Rsync is particularly easy if you use docker bind mounts instead of volumes.

Edit: for Rclone, I guess tar first?

9

Yeah, all the regular options should be quite straight forward. I was mostly wondering if I need to treat the Docker database backups as regular database backups, or if Docker did something magical to make it easier to backup. :wink:

10

So, I think I’ll just try something like this in cron:

cd /srv/docker/appname && docker compose down && rsync -azuP --delete /srv/docker/appname/ [email protected]:/srv/bak/appname/ && docker compose up -d

Or bad idea? :sweat_smile:
After the initial rsync, is only takes like 10-20 secs to complete, and the downtime for this service (analytics) is acceptable I think …

I don’t think I’m using bind mounts (?) … :thinking:
df shows a few overlay type /var/lib/docker/overlay2/<UUID> mounts
I just defined volumes using ./appname/ in docker-compose.yml, and backup my entire /srv/docker/appname (which contains subdirs/volumes for nginx, plausible etc.) :nerd_face:

11

./appname/ isn’t a volume, it’s a bind mount :slight_smile: A volume would look like (using Docker run notation for simplicity) -v nginx:/var/html

12

:thinking: It says volumes: in the YAML file, like this for nginx:

services:
    nginx:
        container_name: nginx
        image: nginxproxy/nginx-proxy
        restart: unless-stopped
        ports:
            - 80:80
            - 443:443
        volumes:
            - /var/run/docker.sock:/tmp/docker.sock:ro
            - ./nginx/html:/usr/share/nginx/html
            - ./nginx/certs:/etc/nginx/certs
            - ./nginx/vhost:/etc/nginx/vhost.d
...

Did a couple of bind mounts manually, and it’s not easy to tell from df, mount or /proc/mounts that it’s a bind mount, it seems … :nerd_face: :sweat_smile:

BTW: Does these :point_up: look sane? Or should I use other rsync options? (Couldn’t find my cheatsheet note on rsync.)
Maybe I should make a less verbose version, easier, less spammy with cron … :nerd_face:

13

Yeah, that’s just the directive used to declare volumes or bind mounts. As you’ve specified paths, it’ll use bind mounts, rather than creating Docker volumes :slight_smile: You can check your volumes by running docker volume ls

14

Yeah the command looks sane, but it’s not really a backup. If you accidentally delete something and want to recover it the next day after your rsync ran, you’re out of luck.

1 Like
15

That’s true, plan is to rotate tar files of the rsync’ed dir on the storage node.
I figured making docker compose up -d dependent on successful rsync might not be the best idea, though … :wink: So I made it into a script I’ll run in cron.
I also should to make the backup script less verbose, I guess I’ll just have it report errors and otherwise don’t spam :slight_smile:

1 Like
16

That’s basically what I do. I just use rsnapshot to rsync the bind mounts and rotate for me.