Silently not backed up

[hephaisto]

Description

Two days ago I looked into my backup log to find that there were no archives created since 2025-06-12. I did not see any notification from vorta about missing backups. I attached log files of 5 days. They all contain:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/vorta/network_status/network_manager.py", line 35, in get_current_wifi
    active_connection = self._nm.get_active_connection_info(active_connection_path)
  File "/usr/lib/python3/dist-packages/vorta/network_status/network_manager.py", line 135, in get_active_connection_info
    connection=read_dbus_property(active_connection, 'Connection'),
               ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/vorta/network_status/network_manager.py", line 162, in read_dbus_property
    return get_result(msg)
  File "/usr/lib/python3/dist-packages/vorta/network_status/network_manager.py", line 169, in get_result
    raise DBusException("DBus call failed: {}".format(msg.arguments()))
vorta.network_status.network_manager.DBusException: DBus call failed: ['Object does not exist at path “/”']
2025-08-20 18:09:38,105 - vorta.scheduler - ERROR - Conditions for backup not met. Aborting.
2025-08-20 18:09:38,105 - vorta.scheduler - ERROR - Pre-backup command returned non-zero exit code.

I am unsure whether the D-Bus call failure is relevant for this case.

My current setup is that I have two external hard disks, which I swap regularly. One is connected to the machine to be backed up, the other is placed in a safe location. Therefore, only one of the backup repos is available at the same time, it is expected that one of the backup fails while the other succeeds. In the list of archives, currently the failing backup is placed before the one that should work.

I tried explicitly running the working configuration with the "Start Backup" button, which did not create an archive either, without any error message. I manually ran the pre-backup command (mount $(dirname $repo_url)) to mount the repo, which succeeded. The problem persisted after manually mounting/unmounting the disk. I did not try to mount manually and remove the pre-backup command from the config, though.

After I manually created a new archive, vorta was again able to create new archives. So I assume that something with the repo was broken. Unfortunately, since then, , I am unable to reproduce the issue.

Regardless of the underlying cause, I think the following are relevant issues:

1. Vorta did not display any warning about failed backups.
2. The logs do not include the reason for failing the backup.
3. Starting the backup manually did not display any error message.

In apt.txt you can find a list of packages installed/upgraded between the last successful backup and the time where the first failed backup would have been scheduled.

Logs in upload-files due to length: vorta.2025-08-19.log vorta.2025-08-20.log vorta.2025-08-22.log vorta.2025-08-23.log vorta.2025-08-25.log

Reproduction

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

OS

Linux ... 6.12.38+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.38-1 (2025-07-16) x86_64 GNU/Linux, XFCE 4.20, GTK 3.24.49

Version of Vorta

0.10.3

What did you install Vorta with?

Distribution package

Version of Borg

1.4.0

Logs

See attached files.

[goebbe]

Thanks for reporting! Did you activate the related notifications? There is an option: "Display notification when background tasks fail" in the Vorta Settings/ About dialogue.
Not sure it this applies for failures of the "pre backup command", however.

[hephaisto]

The notification was not enabled 🤦 Maybe I misread "background" as being related to repo checks or prunes. So in general, I think the "no notification" was my fault.

But I am still unsure about why the backup actually failed. I only see one failure, and I would have expected either two failures or one failure and one success.

I played around a bit, and I think I have an idea: I expected that all repos which are listed in the "repository" dropdown list are backed up to, and the selection only refers to the repo currently being edited. Is the meaning that only the currently selected repo is actually backed up to?

[goebbe]

I think you may have found the source of your failed backups.
As far as I know, you can only have one active repository per profile.

For the described use-case, I would have expected you to create two distinct profiles - one profile for each external hard-disk and enable scheduled backups for each.
If you use different names for your repositories, like repo-disk-1 on the first hard-drive and repo-disk-2 on the second hard-drive - then only the profile with the available repo will be backed up. The backup in the other profile will fail, since the repo cannot be accessed if the disk is not connected/ mounted.

[m3nu]

Yes, 1 profile = 1 repository. Though there might be an open suggestion to have multiple repos.