Select containers to backup using labels

[julianwachholz]

The current image tag based selection approach is great for a quick setup.
However, we've been running in a few instances with 'ghost' images, where a previously deployed postgres:16 container will no longer be included in the backup, because a newer container has been deployed with the same tag, but newer minor version. Even tagging the specific version may break as docker image tags are overwritable by design.

A flexible approach would be selecting containers based on a simple label like e.g. auto-backup=mysql, which would also tell the script which backup provider to use. Since labels won't change when a container's image becomes stale, this method would keep working indefinitely.

[RealOrangeOne]

I'm not sure I understand the problem here. If the image is tagged postgres, it will be backed up. Are you wanting backup support for custom tagged images?

[julianwachholz]

Let's say you have some projects with a compose definition like this:

services:
  postgres:
    image: postgres:18

It will deploy it using the current postgres:18 tagged image which right now would be 18.2.
Once 18.3 is released, the postgres:18 tag will be retagged / overwritten.

In a different project, on the same Docker host, we setup and pull a new postgres:18 service (which then would be 18.3)

The previously pulled postgres:18 image now becomes stale and it causes container.image.tags to become an empty list, causing db-auto-backup to no longer back up this old service as there are no tags to match to a provider.

I've quickly drafted support for a customizable label, which seems like a clean and explicit solution to us:
#100