I have a bunch of different applications to backup, each with slightly different options. But they have many options in common, and I don't want to repeat those options for each application.
I could use the existing include merging feature, but that results in an awkward configuration files where you have to do multiple includes, one per section.
It would be great if there was a more supported way to inherit and reuse common configuration options across the entire configuration file.
Other notes / implementation ideas
One idea is to update the existing include merging feature to do "deep merging". That might look something like this:
This would perform a deep merge of all sections including the retention section, such that the resulting interpreted option values would be a keep_daily of 5 and a keep_hourly of 2.
If you tried this today with a current borgmatic version, the entireretention section in /etc/borgmatic.d/myapp.yaml would replace the entire retention section from the common file—not what the user wants under this use case.
Note that if this deep merging change were made, it would technically be a breaking change to the existing include merging behavior.
#### What I'm trying to do and why
I have a bunch of different applications to backup, each with slightly different options. But they have many options in common, and I don't want to repeat those options for each application.
I could use the existing [include merging](https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/#include-merging) feature, but that results in an awkward configuration files where you have to do multiple includes, one per section.
It would be great if there was a more supported way to inherit and reuse common configuration options across the *entire* configuration file.
#### Other notes / implementation ideas
One idea is to update the existing include merging feature to do "deep merging". That might look something like this:
`/etc/borgmatic/common.yaml` contents:
```yaml
location:
...
retention:
keep_daily: 1
keep_hourly: 2
```
And `/etc/borgmatic.d/myapp.yaml` contents:
```yaml
<<: !include /etc/borgmatic/common.yaml
retention:
keep_daily: 5
```
This would perform a deep merge of all sections including the retention section, such that the resulting interpreted option values would be a `keep_daily` of `5` and a `keep_hourly` of `2`.
If you tried this today with a current borgmatic version, the *entire* `retention` section in `/etc/borgmatic.d/myapp.yaml` would replace the entire `retention` section from the common file—not what the user wants under this use case.
Note that if this deep merging change were made, it would technically be a breaking change to the existing include merging behavior.
And it'll do the right thing and produce a keep_hourly value of 24 and an overridden keep_daily value of 5.
Implemented in master! Now you can do this:
```yaml
<<: !include /etc/borgmatic/common.yaml
location:
...
retention:
keep_daily: 5
```
... where `common.yaml` is:
```yaml
retention:
keep_hourly: 24
keep_daily: 7
```
And it'll do the right thing and produce a `keep_hourly` value of `24` and an overridden `keep_daily` value of `5`.
What I'm trying to do and why
I have a bunch of different applications to backup, each with slightly different options. But they have many options in common, and I don't want to repeat those options for each application.
I could use the existing include merging feature, but that results in an awkward configuration files where you have to do multiple includes, one per section.
It would be great if there was a more supported way to inherit and reuse common configuration options across the entire configuration file.
Other notes / implementation ideas
One idea is to update the existing include merging feature to do "deep merging". That might look something like this:
/etc/borgmatic/common.yamlcontents:And
/etc/borgmatic.d/myapp.yamlcontents:This would perform a deep merge of all sections including the retention section, such that the resulting interpreted option values would be a
keep_dailyof5and akeep_hourlyof2.If you tried this today with a current borgmatic version, the entire
retentionsection in/etc/borgmatic.d/myapp.yamlwould replace the entireretentionsection from the common file—not what the user wants under this use case.Note that if this deep merging change were made, it would technically be a breaking change to the existing include merging behavior.
Implemented in master! Now you can do this:
... where
common.yamlis:And it'll do the right thing and produce a
keep_hourlyvalue of24and an overriddenkeep_dailyvalue of5.Released in borgmatic 1.6.0!