Gracefully fail if one of multiple repos is missing

[m3nu]

Discussed in #88

^{Originally posted by goebbe March 27, 2026}
Currently, I am looking for a good way to use the same config file for

• a backup to my NAS (that is scheduled to run regularly) AND
• a backup to a USB-disk, that I only attach from time to time.

With this setup, I face the following issue:

When the USB-disk is not attached / not mounted AND the scheduled backup is due,
there is a popup that proposes to initialize the (at this moment missing) USB repository.

Apparently vykar tries to get the information from the (un-mounted) USB-stick. Since the
repository is not mounted (the directory does not exist), vykar proposes to create initialize the repo.

Is there a way to prevent this type of behaviour?
What would be a good workaround?

[goebbe]

The following issue might be related - even though the framing is different: #63
I can use a hook to prevent vykar actions (backup, prune, ...) but there is no means to prevent vykar-gui to try to connect to the repo (for repo info and snapshots) - and throw error messages, for example if the repo on the home NAS is not available.

Perhaps a kind of hook / condition / config options that allows to check if repo is available?

1. for local backups/ USB-disk: Check if directory/ repo is available - before doing anything else
2. for remote repos: Check if repo condition is satisfied / can connect to repo - before doing anything else

For 2. it would be great if there would be a way to prevent vykar to even try to connect. (similar to a repo hook).
When travelling, I am often connected to corporate networks / hotel WIFI - and vykar trying to connect to other computers in the LAN (e.g. 192.168.0.x since this is the IP of my home NAS) - would not feel right.

[goebbe]

The following issue is still present in vykar 0.12.14, for me:

When the USB-disk is not attached / not mounted ,
there is a popup that proposes to initialize the (at this moment missing) USB repository.

This happens, when

• vykar-gui is started AND
• when the scheduled backup is due

Perhaps vykar.config could use as "type:" Element?

repositories:
  - label: 'usb-home'
  - type: 'USB'
    url: /media/goebbe/backup1/vykar-EB845-home-repo

OR perhaps: use "usb:" instead of "url:"?

repositories:
  - label: 'usb-home'
    usb: /media/goebbe/backup1/vykar-EB845-home-repo

So if type is 'USB' - vykar would NOT propose to initialize a repository if the repo is not present/ not available?

[m3nu]

Do you have multiple repos? It won't skip if there is only one. And do you run the 'bare' vykar. It won't skip repos for the backup subcommand.

[goebbe]

Do you have multiple repos? It won't skip if there is only one. And do you run the 'bare' vykar. It won't skip repos for the backup subcommand.

I am describing the behaviour of vykar-gui.
There are windows popping up, asking if the missing repo should be created:

I have two repositories in my config.
This is the relevant part of the config.yaml:

repositories:
  - label: 'usb-home'
    url: /media/user/backup_1/vykar-home-repo

  - label: 'NAS'
    url: 'sftp://user@192.168.0.5:22/backup/vykar_test_repo'

My backup USB-drive is not attached to the laptop, most of the time.
This is the standard mount point for USB-sticks on my System:
/media/user/
Only, when the usb stick is plugged in and mounted the repo is available:
/media/user/backup_1/vykar-home-repo

[goebbe]

Since this is only a problem of the GUI - the standard solution for this type of problem would probably be
adding a new selection field to the "Repository Not Initialized" Window:

[ ] Show this message again, if Repository is not initialized

The default would be to show this message exactly once, per repository.
But the user could opt in, to show this message whenever NO initialized repo is found.

Should this issue be re-opened?

[m3nu]

With the last update, it should check for the presence of the config file and then skip if multiple repos exist.

Most likely the 'init' code kicks in before that. If that's the case, it's an easy fix to get this intended behavior.