Would it make sense to add a stack-back.restic.arguments label?

[elmotec]

That label would then be use to pass arguments to the underlying restic backup call. I can think of multiple use cases:

• pass extra --exclude-* options to skip certain files, directories, or files exceeding a certain size.
• pass extra -v or -vv for debugging.
• pass --tags to identify snapshots.
• ...

See restic help backup. Not all options can be pass as an environment variable like --host.

[lawndoc]

I like this idea! You can go ahead and create an issue, and I'll get to this when I can. Currently I'm in crunch time studying for an exam at the end of February, and then I should have some time freed up again to churn though the open issues. I'll be prioritizing bug fixes over new features like this one. If this is an urgent need for you, it might be faster to make a PR yourself.

[elmotec]

Hi @lawndoc, I realized that the labels are attributes of the backed up container but (ignoring database for now) the backup process is really on the volumes; in fact, all the volumes are backed up with one restic call.

I also feel stack-back.restic.backup.options is a better name than stack-back.restic.arguments.

I see 2 options:

1. put the stack-back.restic.backup.options on the stack-back container (backup in the test compose file) but (i) it feels like environment variables are currently the way we roll (AUTO_BACKUP_ALL, LOG_LEVEL, EXCLUDE_BIND_MOUNTS, ...)
2. put the stack-back.restic.options on the volume and back up each volume separately but (i) I am not sure how it will work for bind mounts and (ii) we will end up having one snapshot per volume.

I think option 1. is the way to go, possibly as an environment variable but it seems labels have more flexibility because they can be specified as multi-line.

I created I created #101 for your consideration.