[Feature] Automated backups of all named volumes

[Mushoz]

Is your feature request related to a problem? Please describe.
I have many different docker-compose files for different services. And I am fairly certain I am not the only one. If I want to add backups I either:

1. Have to add a backup service to each individual docker compose file, introducing a lot of duplication and maintenance.
2. Define one new docker compose just for the backup, change all my docker compose files to utilize explicitly named volumes, and then mount all these volumes in this newly created service.

Number 1 has a lot of duplication. Number 2 has a risk of forgetting to mount new named volumes, and not backing them up.

Describe the solution you'd like
Allow this tool to use the docker socket to create a list of ALL named volumes, and back them all up automatically. We could set a default policy for whether to stop containers using a volume or not. We could run an exclude list on volumes NOT to backup. But this way, we will at least have backups for new volumes in changed existing services or entirely new docker compose files by default even if we do not change anything.

Describe alternatives you've considered
Not aware of any alternatives.

[m90]

I would think this is pretty similar to #329

[Mushoz]

It does massively improve the situation. I REALLY like the idea of using labels at the volume level. That way, I can configure a single backup service, massively cutting down on duplication. And then label volumes when defining them accordingly.

However, I do not think it solves the issue of backing up everything automatically. I would really like it if I could set up the defaults via the backup service itself. Eg, adding the following to the service:

docker-volume-backup.stop-during-backup=true

Would then stop any containers using a volume by default, since that is the safest thing to do. I could then set the

docker-volume-backup.stop-during-backup=false

label at the volume level for those volumes that I know can be backed up safely without stopping the containers that are using it. That way, if I ever forget to set this label for new volumes, it will use the safe option of stopping containers when backing up, which is what I would want it to do. This idea could be extended to other existing labels as well. Eg, define the defaults at the service level, define overrides at the volume level.

Furthermore, to deal with the automated backups without any possible way of accidentally forgetting setting this up for newly created volumes, how about we introduce something like:

docker-volume-backup.automatically-backup-all-named-volumes=true

When this is set, the service would backup all named volumes, even those without any labels at all. We could then also introduce some new label at the volume level that would exclude that particular volume from the automated backup. That way:

1. Everything is backed up by default. I rather waste space than forget a backup.
2. I still have the flexibility of not backing up certain things, but it will have to be a conscious choice on a per-volume basis.

I feel my ideas do have a lot of overlap with the existing issue, but it does also introduce some new stuff (mainly the backup-by-default behavior). Would you prefer to keep this is a separate issue, or shall I move this feedback and add it to this existing issue? Thanks!

[m90]

Does Docker have the concept of a "named volume"? I.e. if the tool would list all volumes, how would it know which ones are named, and which ones aren't? This probably gets more complicated when running multiple compose stacks on the same host.

[Mushoz]

Docker compose labels all names volumes automatically, so generating a list of all named volumes is as easy as running the following command:

docker volume ls --filter label=com.docker.compose.volume

[Mushoz]

Alternatively, you can also find all anonymous volumes via this command:

docker volume ls --filter label=com.docker.volume.anonymous

[m90]

Thanks for elaborating. The difficult part when implementing this will be the same as in #329: since Docker can't mount/unmount volumes at runtime, the architecture of this tool - where we have a long running container that does scheduling, Docker interaction as well as backing up - does not work anymore. Instead, one-off containers will need to be spawned for each backup.

I'm not opposed to implementing such an approach, but it will require a dedicated effort and is not something that can easily be solved. If anyone wants to work on this I am happy to discuss implementation details. It would probably also make sense to work on this in conjunction with #329.