Borg Backup UI 2026.09.15.1531 – Restore multiple files and folders

With this update, you can select several files and folders from one archive and restore them together.

• Easier navigation: An expandable folder tree helps you find your data. Selected entries remain selected when moving between folders.

• Clearer selection: A compact, searchable list keeps larger selections manageable.

• Review before starting: The restore plan shows the source, planned action and destination for every entry. The folder structure below the common parent is preserved.

• Dry run without writing: Check the selected data with Borg without writing files to the destination.

Other improvements:

• Messages no longer shift page controls. Information, success and warning messages close automatically; errors have no automatic timeout.

• In Restore Tests, action buttons stay side by side in both languages and keep their position when saving.

• Migration backup cleanup correctly recognizes existing job-ID and job-settings recovery copies. Incomplete or ambiguously associated copies remain protected.

No new data migration is required for this update. Thank you for your feedback and testing!

8 hours ago, Thorsten said:

USB backup fix in Borg Backup UI 2026.09.15.1019

This version fixes an issue where USB backups were incorrectly skipped with “USB is not mounted”, even though the drive was mounted and the USB profile check reported OK.

This affected profiles pointing to a subfolder, for example:

• Drive mount point: /mnt/disks/USBHDD

• Configured storage path: /mnt/disks/USBHDD/borg-backup

The profile check and backup startup used different checks. Both now use the same validation and support the drive’s mount point or an existing subfolder. This issue was unrelated to the job-ID migration.

Missing drives, inaccessible folders and read-only targets still prevent backups from starting.

No configuration changes, repository imports or data moves are required. Update the plugin and run your affected backup job again. The log now shows the configured storage path, detected mount point and check result.

Thanks to everyone who reported the issue and helped identify the cause!

Thanks for the Update. USB Backup jobs are up & running again. But a small note: I had to refresh the repositories to get them going again. Without a new refresh, the job still failed.

4 hours ago, JayDee73 said:

Thanks for the Update. USB Backup jobs are up & running again. But a small note: I had to refresh the repositories to get them going again. Without a new refresh, the job still failed.

To narrow down why refreshing was necessary, could you please check the following?

• What was the exact error message from the failed backup before refreshing?

• Is the repository unencrypted, and had you restarted Unraid beforehand?

• Did you click “Refresh info” for the repository or the general “Refresh” button at the top of the page?

If the failed backup still reported “USB is not mounted”, please also include this line from that backup’s log:

USB storage check: path=…; mount=…; result=…

This will help us distinguish a USB mount detection issue from a separate Borg repository access issue.

Borg Backup UI 2026.09.16.1126 - faster restores and fewer status-file writes

This update improves Browse & Restore, particularly when restoring many small files.

In my real-world test, restore time dropped from 1 hour 58 minutes 15 seconds to 16 minutes 10 seconds - approximately 7.3 times faster, or 86.3% less time. The second run used Replace mode; the selected data was still fully extracted again. This is a single comparison on my system, not a guaranteed improvement for every setup.

One source of overhead was status persistence: previously, every file-output line caused the restore status file to be rewritten. By default, this file is stored on the Unraid USB boot device. Status is now saved only at key points during the operation.

An automated test with 5,000 simulated log lines now requires just 6 saves of this status file. Compared with saving once per line, that is approximately 99.9% fewer status-file updates in this test. Other writes, such as the final history records, are not included; physical USB writes were not measured.

Also included:

- Compact restore status with phase, elapsed time, source and destination.

- An explanation of the temporary extraction folder.

- File and folder counts on completion, including visible zero values.

- Green success indicators and a completion check mark.

- /mnt/cache and its subfolders can be explicitly allowed under Settings > Restore > Browse & Restore.

Thanks for your testing and feedback!

19 hours ago, Thorsten said:

To narrow down why refreshing was necessary, could you please check the following?

• What was the exact error message from the failed backup before refreshing?

• Is the repository unencrypted, and had you restarted Unraid beforehand?

• Did you click “Refresh info” for the repository or the general “Refresh” button at the top of the page?

If the failed backup still reported “USB is not mounted”, please also include this line from that backup’s log:

USB storage check: path=…; mount=…; result=…

This will help us distinguish a USB mount detection issue from a separate Borg repository access issue.

This is the error message:

Log said:

2026-09-15 18:14:50 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2026-09-15 18:14:50 INFO   PHASE 3: BORG BACKUP (CREATE)
2026-09-15 18:14:50 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2026-09-15 18:14:50 INFO Repository: /mnt/disks/USBHDD/borg-backup/borg-backup-data
2026-09-15 18:14:50 INFO Backup paths: /mnt/user/photos /mnt/user/music /mnt/user/data/Backup /mnt/user/data/Hausbau /mnt/user/syncthing /mnt/user/immich /mnt/user/immich-gen
2026-09-15 18:14:50 INFO Excluded paths: none
2026-09-15 18:14:50 INFO Exclusion markers: none
2026-09-15 18:14:50 INFO Performance: Compression=lz4
2026-09-15 18:14:50 INFO File activity output: disabled
2026-09-15 18:14:50 INFO Cache: /mnt/user/borg-backup-ui/cache/usb_data_photos_music_usb
2026-09-15 18:14:50 INFO 
2026-09-15 18:14:50 INFO Borg create starting... (7 paths, compression=lz4)
2026-09-15 18:14:52 INFO Warning: Attempting to access a previously unknown unencrypted repository!
2026-09-15 18:14:52 INFO Do you want to continue? [yN] Aborting.
2026-09-15 18:14:52 INFO Cache initialization aborted
2026-09-15 18:14:52 INFO terminating with error status, rc 2
2026-09-15 18:14:52 ERROR ERROR: Borg create failed (exit 2)

And because of this "previously unknown..." I did a Refresh. We had this error already in another situation a couple of weeks ago, and you told me to refresh. I did remember this and did it again. ;-)

So, to answer your next question: Yes, the backup is unencrypted. No, I didn't have restarted Unraid straight beforehand. But wait....I restarted it about 4 days ago because of a new network card driver. So yes...between the last successful job and the latest failed one there was a restart. And yes, you told me that a permanent fix for this is still in the making and until then, a Unraid restart leads to this behaviour. So in the end it's not related to the USB mount problem, but to the "unencrypted backup" problem?!

And regarding the last questions: I refreshed every job, not all of them with the general button.

JD

19 minutes ago, JayDee73 said:

This is the error message:

Log said:

2026-09-15 18:14:50 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2026-09-15 18:14:50 INFO   PHASE 3: BORG BACKUP (CREATE)
2026-09-15 18:14:50 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2026-09-15 18:14:50 INFO Repository: /mnt/disks/USBHDD/borg-backup/borg-backup-data
2026-09-15 18:14:50 INFO Backup paths: /mnt/user/photos /mnt/user/music /mnt/user/data/Backup /mnt/user/data/Hausbau /mnt/user/syncthing /mnt/user/immich /mnt/user/immich-gen
2026-09-15 18:14:50 INFO Excluded paths: none
2026-09-15 18:14:50 INFO Exclusion markers: none
2026-09-15 18:14:50 INFO Performance: Compression=lz4
2026-09-15 18:14:50 INFO File activity output: disabled
2026-09-15 18:14:50 INFO Cache: /mnt/user/borg-backup-ui/cache/usb_data_photos_music_usb
2026-09-15 18:14:50 INFO 
2026-09-15 18:14:50 INFO Borg create starting... (7 paths, compression=lz4)
2026-09-15 18:14:52 INFO Warning: Attempting to access a previously unknown unencrypted repository!
2026-09-15 18:14:52 INFO Do you want to continue? [yN] Aborting.
2026-09-15 18:14:52 INFO Cache initialization aborted
2026-09-15 18:14:52 INFO terminating with error status, rc 2
2026-09-15 18:14:52 ERROR ERROR: Borg create failed (exit 2)

And because of this "previously unknown..." I did a Refresh. We had this error already in another situation a couple of weeks ago, and you told me to refresh. I did remember this and did it again. ;-)

So, to answer your next question: Yes, the backup is unencrypted. No, I didn't have restarted Unraid straight beforehand. But wait....I restarted it about 4 days ago because of a new network card driver. So yes...between the last successful job and the latest failed one there was a restart. And yes, you told me that a permanent fix for this is still in the making and until then, a Unraid restart leads to this behaviour. So in the end it's not related to the USB mount problem, but to the "unencrypted backup" problem?!

And regarding the last questions: I refreshed every job, not all of them with the general button.

JD

Yes, you're right. This is not related to the USB mount issue, but to the already known issue tracked in #498.

The underlying reason is actually Borg itself and how its local security state works on Unraid.

Borg stores information about previously known repositories locally in its cache/security directory. On Unraid, this directory is currently located in the non-persistent root filesystem, which is recreated after every reboot.

So after an Unraid restart, the repository and all backup data are still perfectly fine, but Borg has lost its local record that it already knows this repository.

For an unencrypted repository, Borg then intentionally displays:

Warning: Attempting to access a previously unknown unencrypted repository!

and asks for confirmation. Since a scheduled backup cannot answer this interactive prompt, the job aborts.

Refreshing the repository causes Borg to recognize it again and recreate the required local security state, which is why the backup works afterwards.

Issue #498 is intended to fix this permanently by making the relevant Borg state persistent across Unraid reboots. This requires a migration for existing installations, which is why the implementation is taking a little longer.

Until then, a refresh may still be required after an Unraid reboot.

Borg Backup UI – Update 2026.09.17.1618

This update includes two improvements:

• Backups after an Unraid reboot: Borg’s repository security state is now stored persistently. Unencrypted backup jobs can run directly after a reboot without manually refreshing repository information first. Existing security records are automatically migrated during the update.

• Clearer History filter: Job names now include their storage location, such as “Appdata – Local” or “Appdata – USB”, making identically named jobs easier to distinguish.

The fix has been successfully tested, including an Unraid reboot.

22 hours ago, Thorsten said:

Yes, you're right. This is not related to the USB mount issue, but to the already known issue tracked in #498.

The underlying reason is actually Borg itself and how its local security state works on Unraid.

Borg stores information about previously known repositories locally in its cache/security directory. On Unraid, this directory is currently located in the non-persistent root filesystem, which is recreated after every reboot.

So after an Unraid restart, the repository and all backup data are still perfectly fine, but Borg has lost its local record that it already knows this repository.

For an unencrypted repository, Borg then intentionally displays:

Warning: Attempting to access a previously unknown unencrypted repository!

and asks for confirmation. Since a scheduled backup cannot answer this interactive prompt, the job aborts.

Refreshing the repository causes Borg to recognize it again and recreate the required local security state, which is why the backup works afterwards.

Issue #498 is intended to fix this permanently by making the relevant Borg state persistent across Unraid reboots. This requires a migration for existing installations, which is why the implementation is taking a little longer.

Until then, a refresh may still be required after an Unraid reboot.

Fixed with Borg Backup UI – Update 2026.09.17.1618

Borg Backup UI 2026.09.17.2204 – Scheduled restore tests

Restore tests can now be scheduled per job at a fixed daily, weekly or monthly time. Test level and evidence validity are configured separately. The overview shows the next test time and schedule status. Schedules are restored automatically after an Unraid reboot.

Other improvements:

• Backups and restore tests cannot use the same repository simultaneously. The later operation is skipped with a logged reason, preserving the previous verification result.

• For the new schedules, overdue reminders follow the configured evidence validity period. “Next test” and “Overdue after” are displayed separately.

• Improved planning table, clearer labels and validation messages in the selected plugin language.

Upgrade note: Existing interval schedules and test reports are preserved. If a job was previously marked “Scheduled” without a cron schedule, please set an execution time under Restore Tests → Edit plan.

All times use the server’s local time. Missed or skipped tests are not automatically retried. “Test now” remains available.

Preview: Grafana dashboard for Borg Backup UI

I’m currently working on optional Prometheus integration and a dedicated Grafana dashboard for Borg Backup UI.

The dashboard brings backup status, storage statistics and restore verification together in one overview:

• Color-coded status cards for each backup job and location.

• Repository sizes, archive counts, and savings from compression and deduplication.

• Comparisons of the largest archives and newly stored data.

• Restore verification results, evidence validity and upcoming scheduled tests.

• Indicators for overdue backups and restore tests.

• Filters for server, location, repository and job.

The exporter is built directly into the plugin and can be enabled or disabled. You’ll need your own Prometheus and Grafana installations. Metrics use existing status data and cached repository information, without starting additional Borg commands.

The dashboard is currently being tested. The screenshots show the current design.

What information would you find most useful? Feedback on the layout is welcome tool

Edited September 18Sep 18 by Thorsten

Borg Backup UI 2026.09.23.0926 – Prometheus, Grafana and more flexible restores

This update adds optional Prometheus integration and a dedicated Grafana dashboard to Borg Backup UI.

The included dashboard brings together backup results, active jobs, duration, storage sizes and savings, restore-test evidence and planned tests. Server, location, repository and job filters help you find the information you need.

Set it up under Settings > Integrations > Prometheus & Grafana. You will find a separate access token, a matching Prometheus configuration and the dashboard download. Prometheus and Grafana run separately; no additional exporter is required. The integration is disabled by default.

Metrics collection reads existing plugin data with an in-memory cache. It does not run additional Borg commands or refresh repositories. Historical charts begin when Prometheus starts collecting; running-job visibility follows the collection and refresh intervals.

Browse & Restore is now more flexible too. Alongside the existing job filter, you can show all archives in the assigned repository or use a custom name pattern, such as documents-*. This also lets you select archives created with naming schemes from other applications, without changing backup names or retention rules. A job assigned to the repository is still required for now.

Setup guidance and the new archive-filter interface are available in German and English. The Grafana dashboard uses English labels.

Hallo,

ich habe schon wieder genau das gleiche Problem

Unraid schon neu gestartet
Das PlugIn schon deinstalliert und neu installiert

Jetzt startet es nicht mehr.

20 minutes ago, mikiunraid said:

Hallo,

ich habe schon wieder genau das gleiche Problem

Unraid schon neu gestartet
Das PlugIn schon deinstalliert und neu installiert

Jetzt startet es nicht mehr.

Schicke mir bitte das log File unter /var/log/borg_backup_ui.log damit ich mir das anschauen kann.
Am 08.09.2026 habe ich dir zu diesem Fehler auch ein PN geschickt mit Fragen.

Edited September 29Sep 29 by Thorsten

Das LOG ist leer

Ich habe den Fehler gefunden.


das Log hat volle 128M gebraucht.
Das ist passiert weil ein DOCKER Container ein beschädigtes ICON hat.
Habe das Log gelöscht und jetzt funktioniert das PlugIn wieder.

Jetzt muss ich das mit dem DOCKER Icon erst einmal in den Griff bekommen.

Edited September 29Sep 29 by mikiunraid

Borg Backup UI – Version 2026.10.09.1435

This release introduces general Pre/Post scripts, reduces Docker downtime during backups, and improves error reporting.

• Less downtime for Docker and VMs: Containers and virtual machines restart after archive creation. Retention cleanup, repository compaction (compact), and integrity checks (check) continue afterward.

• General Pre/Post scripts: Manage reusable Bash scripts under Settings → Scripts and assign them in the job wizard. Pre runs before backup preparation; Post runs after maintenance and cleanup. Post can optionally run after failed, skipped, or cancelled backups.

• Improved script editor: Bash syntax highlighting, line numbers, syntax validation on save, and navigation to syntax errors. Scripts can also be duplicated, imported, and exported as .sh files.

• Clear job assignments: A collapsible list shows which jobs use each script. Assigned scripts cannot be deleted. Changes to centrally stored scripts apply from the next job run.

• Clearer error reporting: Pre and Post have their own phase separators in the log. History and logs identify script failures and their exit codes. A failed Pre explicitly reports that the backup was not started. A Post failure preserves any archive already created.

• UI improvements: Consistent script settings layout and corrected background colors in History details.

• Unraid dashboard widget: Updated time labels, clearer distinction between skipped backups and warnings, and improved contrast in light and dark themes.

Syntax validation does not execute scripts. Imports also validate the Bash shebang and file format.