Arguments for borg create are applied by repo, not by profile

[flixmart]

Description

While most settings go by profile, the "additional arguments for borg create" (shell-commands submenue under sheduling) do not, but globally apply to all profiles alike. I guess (hope) that is a bug, or is it on purpose?

I'm using that place to invoke borgs "--patterns-from PatternsFile" option, but would need to use different patterns files by profile. Is there another way to invoke that borg option via Vorta and pass different files by profile?

Reproduction

• [X] I tried to reproduce the issue.
• [X] I was able to reproduce the issue.

OS

Debian 12 stable

Version of Vorta

0.8.10

What did you install Vorta with?

Distribution package

Version of Borg

1.4.0

Logs

2024-08-05 22:16:25,660 - vorta.borg.borg_job - INFO - Running command /usr/local/bin/borg create --remote-path /usr/local/bin/borg --list --progress --info --log-json --json --filter=AM -C lz4 --one-file-system --exclude-caches --patterns-from /usr/local/bin/borgBackup/Fe_home.patterns --exclude-if-present .NO_BACKUP ssh://[email protected]/volume1/BorgBackup/zzz/Test::FeM70-2024-08-05-221625 /home/zzz

[m3nu]

Those are saved per-profile. Would be a very weird bug, since those are kept separate in the settings DB.

[flixmart]

Arghh. I had been doing all my evaluation against one test-repo only. Following up on your comment I've added additional repos and realized, that the borg create arguments are applied by repo, not by profile. If arguments are assigned in profile_1 using repo_1, changing repo_x in profile_x to repo_1 loads the create arguments assigned in profile_1 to profile_x. Changing them in either profile, immediately reflects in the other then. I've changed the topic accordingly, but not edited my first post, to keep the discussion intact. Does that make sense?

[m3nu]

You're right. This setting is saved per-repo, not per-profile. Would per-profile make more sense?

[flixmart]

IMHO: Yes

• First off, (only) that seems just logical, for the topical GUI See your own initial reaction. At least, any deviation from that principle might better be clearly stated in the GUI.
• Secondly, to me atm the cleanest way (targeting a mixed cli and Vorta strategy) seems to invoke --patterns-from per job instead of redundantly configuring Vorta and scripting. Cleanly documented, quickly and reproducable re-configured, if needed.. My Jobs shall be runable on different shedules. I do not see any benefit from using multiple repos by job, but was planning to use repos by user (and machine?) only. Vortas topical state would force to use separate repos by job, or identical shedules (as --patterns-from seems to be invokable several times) by repo, when using Vorta. Not optimal, but less problematic than I thought yesterday...

BTW:

• Without having at least one source named on the appropriate tab, Vorta complains "borg: error: Need at least one PATH argument." True, but recursion roots can as well come from any patterns-file ("R ") ;-)
• This discussion might also benefit from the above multi-invocation of patterns-files. Just using (editable) templates...

[goebbe]

If I am not mistaken, currently, in Vorta, there are two places where one can define extra borg arguments:

1. When creating a new repo in the Repository tab: This is very convenient to define e.g. a path to a borg repository, e.g. --remote-path='/usr/local/bing/borg1_4' In my opinion it is sensible to have a way to define these type of extra borg arguments at the level of the repository.
2. In the Schedule tab under Shell Commands: Here one can define extra borg arguments for the profile. This is convenient, for example, to call e.g. --patterns-from /path/paterns that contain includes and excluded that apply to different repos in a profile.

Since it is possible to change the repo within a profile, I think the current implementation is sensible. I.e. to have both: extra arguments per repo AND extra arguments per profile.

Note, that there is an open issue, since the extra borg arguments for the repo can only be seen/ edited when adding a repository. Once the repo is added, there is currently no way to see/ edit the extra borg arguments at a per repo level: https://github.com/borgbase/vorta/issues/1963

To avoid confusion, Vorta could display the extra borg arguments (per repo) in the Repository tab.

[Wonderer0]

Would per-profile make more sense?

It definitely would for me.

I have two profiles (say Linux_1 and Linux_2) that backup two similar root filesystems (mounted under /mnt/) to the same repo, saving space because they are very similar.

Both the profiles get the list of paths to backup using 'Extra arguments ...' of the form:

--paths-from-command -- get-backup-files.sh /mnt/Linux_n

The script generates paths of the form /mnt/Linux_n/./*

When I created the two profiles the only difference between them was the argument passed to the script, which specifies the directory to backup. I was extremely surprised to find that after creating Linux_1 profile with /mnt/Linux_1, and then Linux_2 profile with /mnt/Linux_2, the Linux_1 profile then had been changed to /mnt/Linux_2.

I had assumed that all the fields that can be filled in belong to the currently selected profile. Are there any others that are shared between profiles?

The archive names include the profile_slug, which is intended to show which system was backed up. But unless I check and change if necessary the script's argument every time before creating a backup there is a danger that the archive name won't correspond to what was backed up.