docker-volume-backup VS docker-db-backup

I am interested in coming up with a backup plan before I get too invested in this setup. I found the docker-volume-backup project that looks like it might be a possible solution. However I'm not sure how to implement it using docker swarm since I am new to all of this. I would be interested in learning what backup solution you use for your docker swarm servers.

How do people usually backup their self-hosted docker services using postgres? I have been using docker-volume-backup [0] and just saving the postgres data directory, but I've found it requires a minute of downtime to backup properly.

[0] https://github.com/offen/docker-volume-backup

Offen: https://github.com/offen/docker-volume-backup

To solve points 1,2 i 3 I think it would be best to make the copy by stopping the container first. I've been looking for utilities and I've found some like offen/docker-volume-backup. Again, the disadvantage is that you have to configure everything (mount points, files, users, passwords...) manually for each container, so it is very easy to forget to create the backup of one of them. Also, the scheduling would not be centralised, so the backup wouldn't be run sequentially container after container. I've searched a lot, but I haven't found any good alternative. How are you dealing with the backup of containers?

Since I'm using docker rootless, I've run into issues using convenient solutions such as offen. These solutions don't work in a rootless context due to file permissions. The user in the offen container cannot read some directories owned by other containers. This is usually an issue with databases.

FYI this looks like the actively developed version of that utility: https://github.com/offen/docker-volume-backup

You should have backup OS and data but using a separate backup jobs. Backup OS drive using Timeshift or Veeam Agent. Backup Docker server's containers using Offen or Borg. OS backup would allow you restore operating system while data backup would allow recover files.

There is the image docker-volume-backup that allows you to make backup but depending on the situation (databases, ...) it is not necessarily the best solution

I have several dozen containers and I want to establish a good backup policy. Currently, all containers that store data do so by bind mounts to directories on a BTRFS volume. The files are backed up directly from the host. For MySQL/PostgreSQL containers I've been using the fantastic utility tiredofit/db-backup, which does a hot dump of all the data.

this one (https://github.com/tiredofit/docker-db-backup) can be a solution, but it export only to S3 or compatible storage. ( i use Minio)

Then went with https://github.com/prodrigestivill/docker-postgres-backup-local for remote productive Postgres backups, https://github.com/foorschtbar/pyd2b2 for local self-hosted docker database backups and might check out https://github.com/tiredofit/docker-db-backup because it looks promising.

Take a look at tiredofit/db-backup. I run three containers, one for MariaDB, one for Postgres, and one for InfluxDB (also supports other DB types). It uses the database's native backup mechanism to create a database backup that your backup SW of choice can then pick up each day. Then set your backup SW to ignore the database files each night to eliminate the errors in your backups due to locks, open files, files changed during backup, etc.

Cron works just fine but if you’re lazy like me and don’t want to create your scripts yourself, there are prebuilt docker images like https://github.com/tiredofit/docker-db-backup that dumps, compress, encrypts and uploads your backups.

I like do deploy one of these with every database. https://github.com/tiredofit/docker-db-backup Super easy to set up and works with all sorts of databases.

I run a tiredofit/db-backup for each of my databases to backup the database on a nightly basis. I have a shared volume that I share between this container and my database container. I mount it in /backups in both containers for consistency. I retain 8 copies of the backups, just in case I don't catch something in time, and need to go back and restore to a previous date. This volume is kept on a separate drive from the actual database data (which I keep in /mnt/user/appdata (SSD backed cache pool).

I built an image a while back that allows you to take scheduled backups of your databases that you could allow your backup software of choice archive and do its thing.

I have MariaDB in a docker container, recently found out about db-backup and set it up to backup MariaDB and now also Postgresql and Redis, though it requires a separate instance for each backup.