#334 Suggestion: Limiting archive listings according to what's specified in the config file

Open
opened 4 months ago by s1shed · 2 comments
s1shed commented 4 months ago

What I’m trying to do and why

I’m listing archives while using multiple config files which all have the same respository defined.

On one system I have several config files in /etc/borgmatic.d/, one for each application. If I type borgmatic list, it will list all archives, one for each config file. If I have 5 config files that all point to the same repository, I’ll get the same output printed five times. Of course, I realize that I can print this all once with borgmatic --config /etc/borgmatic.d/app1.yaml.

Would it make sense that when borgmatic list is run that the output is limited to what is specified in the key storage.archive_name_format in the configfile that is currently in use (perhaps by specifying a parameter)? Maybe a new key in the config file? Or, if location.repositories is identical in all config files, de-duplicate the list and print the listing just once?

I can get the output I want by specifying a config file and `-P ‘{hostname}-appname’ but perhaps if it wouldn’t be a PITA others would find what I’m suggesting to be useful.

(I’d not be opposed to marking this “won’t fix” and closing)

#### What I'm trying to do and why I'm listing archives while using multiple config files which all have the same respository defined. On one system I have several config files in `/etc/borgmatic.d/`, one for each application. If I type `borgmatic list`, it will list all archives, one for each config file. If I have 5 config files that all point to the same repository, I'll get the same output printed five times. Of course, I realize that I can print this all once with `borgmatic --config /etc/borgmatic.d/app1.yaml`. Would it make sense that when `borgmatic list` is run that the output is limited to what is specified in the key `storage.archive_name_format` in the configfile that is currently in use (perhaps by specifying a parameter)? Maybe a new key in the config file? Or, if `location.repositories` is identical in all config files, de-duplicate the list and print the listing just once? I can get the output I want by specifying a config file and `-P '{hostname}-appname' but perhaps if it wouldn't be a PITA others would find what I'm suggesting to be useful. (I'd not be opposed to marking this "won't fix" and closing)
witten commented 4 months ago
Owner

Interesting idea! Thanks for submitting it. Given that storage.archive_name_format isn’t necessarily a prefix (and can contain things like {now} as part of the pattern), it would probably be necessary for the user to specify a separate prefix specific to listing. Maybe an output.prefix option. Then, that value could be passed to borg list --prefix as you suggest.

Or, if location.repositories is identical in all config files, de-duplicate the list and print the listing just once?

The main impediment I can see to this approach is that multiple configuration files may have differences in options that impact borgmatic list. Examples: local_path, remote_path, and lock_wait. So to be truly accurate, the de-duplication would have to take into account whether all of repository, local_path, remote_path, and lock_wait are identical across configuration files. Annoying, but doable. And may actually be preferrable to the user having to specific a prefix as above.

Let me know your thoughts.

Interesting idea! Thanks for submitting it. Given that `storage.archive_name_format` isn't necessarily a prefix (and can contain things like `{now}` as part of the pattern), it would probably be necessary for the user to specify a separate prefix specific to `list`ing. Maybe an `output.prefix` option. Then, that value could be passed to `borg list --prefix` as you suggest. > Or, if location.repositories is identical in all config files, de-duplicate the list and print the listing just once? The main impediment I can see to this approach is that multiple configuration files may have differences in options that impact `borgmatic list`. Examples: `local_path`, `remote_path`, and `lock_wait`. So to be truly accurate, the de-duplication would have to take into account whether all of repository, `local_path`, `remote_path`, and `lock_wait` are identical across configuration files. Annoying, but doable. And may actually be preferrable to the user having to specific a prefix as above. Let me know your thoughts.
s1shed commented 3 months ago
Poster

Interesting idea! Thanks for submitting it. Given that storage.archive_name_format isn’t necessarily a prefix (and can contain things like {now} as part of the pattern), it would probably be necessary for the user to specify a separate prefix specific to listing. Maybe an output.prefix option. Then, that value could be passed to borg list --prefix as you suggest.

The main benefit of having a configurable option would be that each config file could have its own prefix defined and one run of borgmatic list would cover it all. This is a possibility that I also considered, like the constraint that can be defined for pruning archives.

Or, if location.repositories is identical in all config files, de-duplicate the list and print the listing just once?

The main impediment I can see to this approach is that multiple configuration files may have differences in options that impact borgmatic list. Examples: local_path, remote_path, and lock_wait. So to be truly accurate, the de-duplication would have to take into account whether all of repository, local_path, remote_path, and lock_wait are identical across configuration files. Annoying, but doable. And may actually be preferrable to the user having to specific a prefix as above.

Let me know your thoughts.

This would definitely take care of the sort of situation that I described in this issue but I don’t know if the annoying effort would be worth it.

> Interesting idea! Thanks for submitting it. Given that `storage.archive_name_format` isn't necessarily a prefix (and can contain things like `{now}` as part of the pattern), it would probably be necessary for the user to specify a separate prefix specific to `list`ing. Maybe an `output.prefix` option. Then, that value could be passed to `borg list --prefix` as you suggest. The main benefit of having a configurable option would be that each config file could have its own prefix defined and one run of `borgmatic list` would cover it all. This is a possibility that I also considered, like the constraint that can be defined for pruning archives. > > Or, if location.repositories is identical in all config files, de-duplicate the list and print the listing just once? > > The main impediment I can see to this approach is that multiple configuration files may have differences in options that impact `borgmatic list`. Examples: `local_path`, `remote_path`, and `lock_wait`. So to be truly accurate, the de-duplication would have to take into account whether all of repository, `local_path`, `remote_path`, and `lock_wait` are identical across configuration files. Annoying, but doable. And may actually be preferrable to the user having to specific a prefix as above. > > Let me know your thoughts. This would definitely take care of the sort of situation that I described in this issue but I don't know if the annoying effort would be worth it.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.