I don’t think backing up the container is the right strategy, as containers (I think***) is built for portability. So you can spin one up in seconds, or migrate to another machine with very little hassle.

For me I backup the docker host itself and the docker config files in the volumes with a script. I make the somewhat redundant back up of the config files in addition to the host is because I like to tinker things, and usually nuke something in the process. Having a more frequent backup of the docker configs allows me to easily restore if something goes wrong.

My container are on lxc aswell as on Ubuntu VMs, so I just back up the entire vm or lxc container, when restoring it. Everything is just there as it was

I won’t say you cannot or shouldn’t backup a container since it it wrong imo, but as your using docker as a base i’d say just backup mapped volumes and configuration files. Docker is built around breaking and rebuilding your container and keep working anyways as long as your mapped volumes and docker configurations are the same (asuming you use a well maintained image for updates or something of your own).

That’s probably the sane way to do it and will save you space. I don’t see the benefit of a full container backup (unless it’s an lxc, lxd container or another full persistent container type).

As for the backup repository you can use whatever. If it were me i’d use another server or a NAS, but most cloud storage provider would fit. Storage is never free though.

I either use public available containers like from docker hub or other registry. Or if I build them myself I have them pushed to my own self hosted registry with a minio(s3 compatible) backend and mirror the MinIO instance to a VPS.

All dynamic data is saved with the VM backup the container runs on or is backed up with rdiff-backup to an offsite location.

I don’t back up containers but I have bind mounts, so all of my data is in a ZFS data set that I rclone to another location.

But people seem to like nautical

I have Synology and back up the entire volume.

No container backups, just volume backups.

When you run a program on your PC, say a CAD or an IDE, you won’t backup the software itself, but just data of your projects. The same is for containers. A container is the software, the volumes are your project data. You should store all the configuration of your container (e.g. config files, yaml files, databases directories, deployment files,etc. etc.) in one or more volumes that are persisted on your disk. By the way, the container lose all files not stored in volumes each time your server reboots, so the volume itself is a form of backups between power-ons.

Backing up containers is not a practice. It is not needed, it must not be done, never. Sometimes you want change the internal environment of your container, and in that case you want create/commit an image to restore that environment. This practice is more correctly called ‘image creation’ whose purpose is clearly not backing up something.

In ordet to recovery from some sort of disaster, you should backup your volumes and that’s all.

I have Synology, backup docker vm. You can restore files/volumes only or entire vm from backup for business.