#235 allow passing arbitrary flags to borg

Closed
opened 1 month ago by anarcat · 6 comments
anarcat commented 1 month ago

What I’m trying to do and why

in #234, i tried to reproduce a backup script i had which was using --keep-exclude-tags. you have been very nice and immediately implemented support for it in release 1.4.4, but I’m wondering what would happen if a new borg release would come out while you’re on a holiday and we all want to use that shiny new feature.

Other notes / implementation ideas

Could we get a way to inject arbitrary commandline arguments into the various borg commands that borgmatic issues? i would understand why we wouldn’t want to do that if borgmatic talks directly to the (non-existent, really) borg API, but that’s not how it works. as I understand it, it shells out to borg commands, and generates the “right” combination of commandline arguments to make it do what’s specified in the config file.

#### What I'm trying to do and why in #234, i tried to reproduce a backup script i had which was using `--keep-exclude-tags`. you have been very nice and immediately implemented support for it in release 1.4.4, but I'm wondering what would happen if a new borg release would come out while you're on a holiday and we all want to use that shiny new feature. #### Other notes / implementation ideas Could we get a way to inject arbitrary commandline arguments into the various borg commands that borgmatic issues? i would understand why we wouldn't want to do that if borgmatic talks directly to the (non-existent, really) borg API, but that's not how it works. as I understand it, it shells out to borg commands, and generates the "right" combination of commandline arguments to make it do what's specified in the config file.
witten commented 1 month ago
Owner

If we’re going to give this a shot, some thoughts on design:

  1. There are several different Borg sub-commands that borgmatic invokes (prune, create, check, etc.), and the flags for each one are different.. with the exception of global parameters. So would there need to be support for passing arbitrary flags to each of the Borg sub-commands separately? Example borgmatic options that could support that: borg_create_options, borg_prune_options, borg_global_options.

  2. Due to the nature of this arbitrary flags feature, borgmatic can’t validate any of the arbitrary flags passed to Borg. That means that we’d need to add a prominent warning to the documentation that a user is responsible for reconciling any arbitrary flags with those flags produced by standard borgmatic configuration. In fact, if a user has a particular Borg flag configured as an arbitrary flag, and then a future version of borgmatic adds native support for that flag, the user’s configuration may stop working as intended.

If we're going to give this a shot, some thoughts on design: 1. There are several different Borg sub-commands that borgmatic invokes (prune, create, check, etc.), and the flags for each one are different.. with the exception of global parameters. So would there need to be support for passing arbitrary flags to each of the Borg sub-commands separately? Example borgmatic options that could support that: `borg_create_options`, `borg_prune_options`, `borg_global_options`. 2. Due to the nature of this arbitrary flags feature, borgmatic can't validate any of the arbitrary flags passed to Borg. That means that we'd need to add a prominent warning to the documentation that a user is responsible for reconciling any arbitrary flags with those flags produced by standard borgmatic configuration. In fact, if a user has a particular Borg flag configured as an arbitrary flag, and then a future version of borgmatic adds native support for that flag, the user's configuration may stop working as intended.
anarcat commented 1 month ago
Poster

having per-command variables and a global option sets is exactly what i had in mind. it does mean quite a good chunk of optons, unfortunately… maybe it could be a hash of some sort?

and yes, i think this is a “wheels off” approach: people can and might just shoot themselves in the foot, by design.

having per-command variables and a global option sets is exactly what i had in mind. it does mean quite a good chunk of optons, unfortunately... maybe it could be a hash of some sort? and yes, i think this is a "wheels off" approach: people can and might just shoot themselves in the foot, by design.
witten commented 1 month ago
Owner

maybe it could be a hash of some sort?

You mean a separate section in the YAML configuration just for these options?

> maybe it could be a hash of some sort? You mean a separate section in the YAML configuration just for these options?
anarcat commented 1 month ago
Poster

You mean a separate section in the YAML configuration just for these options?

i guess so? maybe something like:

extra_options:
  create: --keep-exclude-tags

?

> You mean a separate section in the YAML configuration just for these options? i guess so? maybe something like: ``` extra_options: create: --keep-exclude-tags ``` ?
witten commented 1 month ago
Owner

Got it. I could see that working in terms of organization.

Got it. I could see that working in terms of organization.
witten added the
design finalized
label 4 weeks ago
witten commented 1 week ago
Owner

This is now implemented for several (non-interactive) Borg sub-commands, and released in borgmatic 1.4.17. To configure, check out the new extra_borg_options in the storage section of borgmatic’s configuration. Here’s an example:

storage:
   extra_borg_options:
        init: --make-parent-dirs
        prune: --save-space
        create: --no-files-cache
        check: --save-space

Enjoy! And thanks for the suggestion.

This is now implemented for several (non-interactive) Borg sub-commands, and released in borgmatic 1.4.17. To configure, check out the new `extra_borg_options` in the `storage` section of borgmatic's configuration. Here's an example: ```yaml storage: extra_borg_options: init: --make-parent-dirs prune: --save-space create: --no-files-cache check: --save-space ``` Enjoy! And thanks for the suggestion.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.