Not annoying at all 🙂 — these are exactly the kind of questions that help improve the plugin.

At the moment, the Docker container templates/configuration are not automatically included in an Appdata backup job.

For my own Appdata backups, I also back up:

/boot/config/plugins/dockerMan

This contains the Docker templates and configuration stored on the Unraid flash drive.

So yes, I think your suggestion makes sense: it would be useful to add an option to an Appdata backup job to include the Docker container templates/configuration automatically.

That way, the Appdata itself and the corresponding container configuration could be kept together in the same backup workflow, which would make a full restore much more convenient.

I’ll put this on the list for future improvements.

If you like, you can also create a feature request on GitHub so it can be tracked properly:

https://github.com/borgforge/borg-backup-ui/issues

Thanks again for the feedback — these kinds of real-world use cases are very helpful.

Hello Thorsten,

Thanks a lot for the great plugin. Regarding my issue:

1. I created an SSH storage box.

2. I created multiple repositories on this target.

3. A job was created for each repository.

4. All jobs can successfully write data to the repositories.

5. The restore test for all repositories completes without errors.

However:

Folders and files from these repositories cannot be restored to a new share. This applies to individual files as well. Only manually downloading a file to my workstation works; restoring it to an Unraid share does not. The "Start Restore" button does not become active. The error message "Precheck failed: The request contains invalid information" appears. This also happens during test runs. The target folder was manually created as a share in Unraid.

What am I doing wrong?

I am using plugin version v2026.17.1225 on

Unraid version 7.3.2.

Thx

Borg Backup UI – Update 2026.08.31.0907

A new stable version of Borg Backup UI is now available through Community Apps.

This update includes improvements to Browse & Restore, archive filter handling, job archive-prefix history, and additional safeguards around existing backup archives.

Please update through Unraid and let me know if you encounter any problems.

As always, verify your backups with a test restore before relying on them for important data.

Hallo,

vielen Dank zunächst für dieses tolle Plugin! Es ist genau das, wonach ich gesucht habe.

Mir ist allerdings eine kleine Sache aufgefallen, bei der ich mir nicht sicher bin, ob ich die Funktionsweise richtig verstanden habe.

Ich nutze Unraid 7.3.2 und habe zusätzlich einen eigenen Docker-Container für Borg Backup eingerichtet, den ich über User Scripts steuere.

Wenn ich damit beispielsweise um 8:00 Uhr ein Backup erstelle und anschließend Dateien im Dateisystem hinzufüge oder lösche, kann ich um 8:30 Uhr ein weiteres Backup erstellen. In diesem Fall werden beide Backups in der Historie angezeigt. Ich kann also später auf den jeweiligen Stand von 8:00 Uhr bzw. 8:30 Uhr zugreifen.

Mit dem Plugin verhält es sich bei mir jedoch anders: Wenn ich innerhalb eines Tages mehrere Backups erstelle, bleibt offenbar nur das letzte Backup erhalten.

Für den betreffenden Job habe ich folgende Aufbewahrungswerte eingestellt:

• Täglich: 20

• Wöchentlich: 40

• Monatlich: 20

• Jährlich: 23

Daher hätte ich erwartet, dass unter „Browser & Restore“ auch mehrere Archive desselben Tages angezeigt werden – beispielsweise das Backup von 8:00 Uhr und das von 8:30 Uhr – jeweils mit dem entsprechenden Dateistand zum Zeitpunkt der Sicherung.

Genau so verhält es sich bei meinem manuell eingerichteten Borg-Backup: Mehrere Backups am selben Tag mit unterschiedlichen Dateiständen werden als separate Archive bzw. Wiederherstellungspunkte in der Historie vorgehalten.

Daher meine Frage: Ist es beim Plugin beabsichtigt, dass innerhalb eines Tages nur das jeweils letzte Backup erhalten bleibt, oder müsste ich dafür eine bestimmte Einstellung ändern?

Vielen Dank schon einmal für die Erklärung und natürlich auch für die tolle Arbeit an dem Plugin!

Ich verwende die Storage Box von HETZNER

Viele Grüße
Michael

Backup von 8:05 Uhr (automatisch)

Backup von 8:55 Uhr (händisch gestartet)

2026-09-04__08_05_02.txt 2026-09-04__08_55_57.txt

Edited September 4Sep 4 by mikiunraid

Hallo Michael,

vielen Dank für dein ausführliches Feedback und natürlich auch für die netten Worte zum Plugin.

Du hast das Verhalten grundsätzlich richtig beobachtet. Die Einstellung „Täglich: 20“ bedeutet bei Borg nicht, dass 20 Backups pro Tag aufgehoben werden, sondern dass Borg bis zu 20 tägliche Wiederherstellungspunkte behält.

Borg beschreibt die Retention sinngemäß so, dass für jeden definierten Zeitraum jeweils ein Archiv erhalten bleibt. Bei "--keep-daily 20" bleibt also grundsätzlich ein Backup pro Tag erhalten – nicht jedes Backup, das an diesem Tag erstellt wurde.

Ein Beispiel:

- 08:00 Uhr: Backup A

- 08:30 Uhr: Backup B

- anschließend wird "prune" ausgeführt

Mit einer reinen Daily-Retention kann Borg danach eines dieser beiden Archive entfernen, da beide in denselben Tageszeitraum fallen. Unter „Browser & Restore“ bleibt dann entsprechend nur noch der Wiederherstellungspunkt übrig, der nach den Retention-Regeln behalten wird.

Wenn du mehrere Backups innerhalb eines Tages behalten möchtest, wären zusätzliche Borg-Regeln wie zum Beispiel "--keep-hourly" oder "--keep" sinnvoll.

Beispiel:

"--keep-hourly 24"

"--keep-daily 20"

"--keep-weekly 40"

"--keep-monthly 20"

"--keep-yearly 23"

Damit könnten auch mehrere Wiederherstellungspunkte innerhalb eines Tages erhalten bleiben.

Alternativ könnte man zusätzlich mit "--keep 10" zum Beispiel einfach die 10 neuesten Backups unabhängig von Tag, Woche oder Monat behalten.

Bei deinem manuell eingerichteten Borg-Backup wird daher sehr wahrscheinlich entweder nicht nach jedem Lauf gepruned oder es werden dort zusätzliche Retention-Regeln verwendet.

Deine Rückmeldung ist aber ein sehr guter Punkt für das Plugin. Die aktuelle Oberfläche mit „Täglich / Wöchentlich / Monatlich / Jährlich“ kann tatsächlich so verstanden werden, als würden mehrere Backups innerhalb eines Tages erhalten bleiben. Ich werde mir deshalb anschauen, ob ich zusätzlich Optionen wie „Stündlich“ bzw. „Neueste Backups behalten“ ergänze und die Beschreibung der Aufbewahrungsregeln eindeutiger gestalte.

Die Verwendung der Hetzner Storage Box hat auf dieses Verhalten keinen Einfluss – die Retention wird von Borg selbst gesteuert.

Vielen Dank nochmal für den Hinweis. Solches Feedback hilft sehr dabei, das Plugin verständlicher und praxisnäher zu machen.

Viele Grüße

Thorsten

Hello Michael,

thank you very much for your detailed feedback and, of course, for the kind words about the plugin.

You have observed the behavior correctly. The setting “Daily: 20” does not mean that Borg keeps 20 backups per day. Instead, it means that Borg keeps up to 20 daily restore points.

In Borg’s retention logic, one archive is kept for each defined time period. So with "--keep-daily 20", Borg generally keeps one backup per day – not every backup created on that day.

For example:

- 08:00 – Backup A

- 08:30 – Backup B

- afterwards "prune" is executed

With only a daily retention rule, Borg may remove one of these two archives because both belong to the same daily period. As a result, under “Browser & Restore” you may only see the restore point that remains according to Borg’s retention rules.

If you want to keep multiple backups within the same day, additional Borg retention rules such as "--keep-hourly" or "--keep" would be useful.

For example:

"--keep-hourly 24"

"--keep-daily 20"

"--keep-weekly 40"

"--keep-monthly 20"

"--keep-yearly 23"

This would allow multiple restore points within the same day to be retained.

Alternatively, something like "--keep 10" could be used to simply keep the 10 most recent backups regardless of day, week, or month.

So in your manually configured Borg setup, it is very likely that either "prune" is not executed after every backup, or additional retention rules are being used there.

However, your feedback is a very good point for the plugin. The current interface with “Daily / Weekly / Monthly / Yearly” can indeed be understood as if multiple backups within the same day would be retained. I will therefore look into adding options such as “Hourly” and/or “Keep latest backups” and also making the retention descriptions clearer in the UI.

The fact that you are using a Hetzner Storage Box does not affect this behavior – the retention logic itself is handled by Borg.

Thanks again for pointing this out. Feedback like this really helps to make the plugin easier to understand and more practical to use.

Best regards

Thorsten

Hello everyone,

with the new version 2026.09.04.1114, the retention behavior should hopefully be much clearer.

The Job Wizard now explains that retention values represent time periods, not the number of archives within each period. For example, “20 daily restore points” means that up to one matching archive is retained for each of 20 days—not 20 archives per day.

The following points are now explained more clearly:

• 0 disables only the corresponding retention rule; it does not mean “keep unlimited archives.”

• At least one retention rule must have a value greater than 0.

• The configured retention rules are applied automatically after a successful backup.

• Prune deletes archives that are not selected by any retention rule.

Additional retention options are already planned and tracked in GitHub Issue #459. These include:

• multiple restore points per day

• hourly retention

• keeping a specified number of the most recent archives

• keeping all archives within a specified period

• an explicit option to keep every archive

• separate controls for disabling the automatic Prune, Compact, and Check maintenance steps

These operations will be clearly distinguished:

• Prune removes archives according to the configured retention rules.

• Compact reclaims repository space after archives have been deleted.

• Check verifies repository integrity.

Disabling these maintenance operations will include clear explanations of the consequences. In particular, “keep all archives” will become an explicit setting instead of being represented through ambiguous retention values.

Thank you again for the feedback—it helped us make the current retention behavior much easier to understand.

@Thorsten
Vielen Dank für die Klarstellung und für die schnelle Anpassung des Plugins.

Ja, stimmt – ich verwende --keep-daily="$KEEP_DAILY".

Ich habe mir das Ganze anschließend noch einmal in der Borg-Dokumentation angesehen. Da hatte ich tatsächlich etwas falsch verstanden.

Ich habe inzwischen alle Einstellungen noch einmal auf die Werkseinstellungen zurückgesetzt. Allein die Möglichkeit, dies direkt über das Plugin machen zu können,

ist wirklich klasse. Dadurch konnte ich verschiedene Einstellungen testen und ausprobieren und anschließend wieder mit einer sauberen Ausgangsbasis neu konfigurieren.

Ich habe allerdings noch eine weitere Frage bzw. Beobachtung:

Bei meinem früheren, manuell über User Scripts gesteuerten Borg-Backup hatte ich immer wieder das Problem, dass Borg sehr viele Dateien als neu bzw. geändert erkannt

und erneut verarbeitet hat, obwohl sich deren eigentlicher Inhalt nicht verändert hatte.

Bei der Analyse bin ich darauf gestoßen, dass dies möglicherweise mit den von Unraid bereitgestellten Dateimetadaten zusammenhängt.

Da ich meine Backups über /mnt/user/... erstellt habe, erfolgt der Zugriff über die Unraid-FUSE-/shfs-Schicht.

Dadurch können sich für Borg sichtbare Metadaten wie Inode-Nummern oder ctime unter bestimmten Umständen verändern,

beispielsweise wenn Dateien durch den Mover zwischen Cache und Array verschoben werden.

Borg berücksichtigt standardmäßig unter anderem solche Metadaten bei der Entscheidung, ob eine Datei erneut untersucht werden muss.

Wenn sich diese Werte ändern, kann Borg eine Datei deshalb als verändert erkennen, obwohl sich der eigentliche Dateiinhalt nicht geändert hat.

Bei meinem damaligen manuellen Backup konnte ich dieses Verhalten durch die Verwendung von:

--files-cache=mtime,size

deutlich reduzieren.

Mein damaliger borg create-Befehl sah folgendermaßen aus:

borg create \
  --files-cache=mtime,size \
  --exclude-from "$EXCLUDE" \
  --compression auto,zstd,10 \
  --list --filter=AME \
  --stats \
  "${REPO}::{now:%Y-%m-%d__%H:%M}" \
  "$SRC"

Gibt es eine Möglichkeit sich bei einem laufenden Backup ebenfalls anzuschauen was Borg gerade macht?

Edited September 4Sep 4 by mikiunraid

Hallo Michael,

vielen Dank für die ausführliche Rückmeldung und den Hinweis zu --files-cache.

Borg Backup UI verwendet aktuell bereits:

--files-cache=ctime,size

Die Inode-Nummer wird damit schon nicht berücksichtigt. Der Unterschied zu deinem bisherigen User Script besteht darin, dass du dort:

--files-cache=mtime,size

verwendet hast.

Deine Beobachtung, dass mtime,size die erneute Verarbeitung vieler Dateien reduziert hat, ist technisch nachvollziehbar. Borg weist darauf hin, dass reine Änderungen an Dateimetadaten die ctime verändern können. Dadurch kann Borg eine Datei erneut untersuchen, obwohl sich ihr Inhalt nicht geändert hat.

Ob in deinem konkreten Fall tatsächlich der Unraid-Mover beziehungsweise die /mnt/user- oder shfs-Schicht dafür verantwortlich ist, können wir ohne einen direkten Vergleich allerdings nicht sicher bestätigen.

mtime,size ist außerdem mit einem Sicherheitsnachteil verbunden: Wenn sich der Inhalt einer Datei ändert, ihre Größe und mtime aber unverändert bleiben oder wiederhergestellt werden, kann Borg diese Änderung möglicherweise nicht erkennen. Deshalb würde ich mtime,size nicht ohne Weiteres als neuen Standard verwenden.

Sinnvoll wäre stattdessen eine erweiterte Einstellung, über die erfahrene Benutzer zwischen den unterstützten Files-Cache-Modi wählen können. Dabei müsste die Oberfläche deutlich auf den Unterschied zwischen Zuverlässigkeit und Geschwindigkeit beziehungsweise geringerer erneuter Verarbeitung hinweisen.

Zu deiner Frage nach einem laufenden Backup:

Borg Backup UI besitzt bereits einen Live-Log. Bei einem manuell gestarteten Job wird dieser automatisch geöffnet. Dort werden der Ablauf, Meldungen und abschließende Statistiken angezeigt.

Eine Ausgabe der gerade bearbeiteten einzelnen Dateien gibt es derzeit jedoch nicht. Der aktuelle borg create-Aufruf verwendet weder --list noch --progress. Eine solche detaillierte Ansicht könnten wir als optionale Funktion ergänzen – beispielsweise mit einer Dateiausgabe über --list --filter=AME oder einer kompakteren Fortschrittsanzeige.

Ich nehme daher zwei mögliche Erweiterungen mit:

• eine optionale Auswahl des Borg-Files-Cache-Modus, einschließlich eines deutlichen Warnhinweises für mtime,size

• eine optionale detaillierte Datei- oder Fortschrittsanzeige im Live-Log

Vielen Dank für den Hinweis und insbesondere für deine praktischen Erfahrungen mit Unraid und dem Mover. Das hilft uns, eine solche Erweiterung sinnvoll und sicher zu planen.

English Version:

Hello Michael,

thank you for the detailed feedback and for pointing out the --files-cache setting.

Borg Backup UI currently already uses:

--files-cache=ctime,size

This means that inode numbers are already ignored. The difference compared with your previous User Script is that you used:

--files-cache=mtime,size

Your observation that mtime,size reduced the number of files being processed again is technically plausible. Borg explains that metadata-only changes can update a file’s ctime. Borg may therefore examine a file again even though its actual contents have not changed.

However, without a direct comparison, we cannot confirm that the Unraid Mover or the /mnt/user/shfs layer is the actual cause in your specific case.

The mtime,size mode also comes with a safety trade-off: if a file’s contents change while its size and mtime remain unchanged or are restored, Borg may not detect the change. For this reason, I would not use mtime,size as the new default without further consideration.

A better approach would be an advanced setting that lets experienced users choose between supported files-cache modes. The interface should clearly explain the trade-off between reliability and potentially faster processing with fewer files being examined again.

Regarding your question about monitoring a running backup:

Borg Backup UI already provides a live log. When a job is started manually, the live log opens automatically and displays the workflow, messages, and final statistics.

However, it currently does not display each individual file being processed. The current borg create command uses neither --list nor --progress. We could add this as an optional feature—for example, detailed file output using --list --filter=AME, or a more compact progress display.

I will therefore keep the following possible enhancements in mind:

• An optional selection of the Borg files-cache mode, including a clear warning for mtime,size.

• An optional detailed file or progress display in the live log.

Thank you again for the helpful report and especially for sharing your practical experience with Unraid and the Mover. This helps us plan such an enhancement carefully and safely.

Borg Backup UI – Public Roadmap

Borg Backup UI now has a public roadmap on GitHub. It shows which topics are planned, what is currently being worked on, what is available in the test channel, and which changes have already been released.

The roadmap will be updated continuously. Priorities may change based on bug reports, required maintenance, or community feedback, so it should not be considered a binding release commitment.

➡️ Open the Borg Backup UI Roadmap

Feedback and suggestions are, of course, still welcome in the forum or through GitHub Issues.

The image below shows a current snapshot. Please use the link for the latest status.

Borg Backup UI – New version 2026.09.05.1319

The new version is available and includes the following improvements:

• Archives can now be browsed in read-only mode under Repositories → Archives.

• Optional file activity output in the live log can be enabled for each backup job, showing new, modified, and erroneous files.

• Minor usability and layout improvements.

Thank you for your feedback, and happy testing!

Hi Thorsten,

First of all, thanks for the plugin. I’m currently in the process of testing it, and so far it looks like I might switch my existing Borg backup scripts to your plugin. Everything is working well so far.

I only have one question.

During the job creation process, you can exclude folders from the selected source folder. Currently, I use Borg’s --exclude-if-present NAME option to exclude certain folders. I already have several folders containing .nobackup or .NOBACKUP files, and when I use --exclude-if-present .nobackup Borg skips those folders.

For example, I use this method to exclude the "files_versions" and "files_trashbin" folders for each Nextcloud user.

Would it be possible to implement this as an additional option in the source selection tab? It would be very useful, otherwise, I would have to add two folder exclusions for each user, as well as for other folders 😝

Thanks!

Hi,

thanks a lot for the feedback — and I'm glad to hear that the plugin is working well for you so far. 🙂

Yes, I know what you mean, and I think this would be a useful addition.

Borg supports this natively with "--exclude-if-present NAME". If a directory contains the specified marker file, Borg skips the complete directory and its contents. This is especially useful for cases like your ".nobackup" / ".NOBACKUP" files, because you don't have to maintain individual exclusion paths for every Nextcloud user.

I think the most logical place would indeed be in the source/exclusion section of the job configuration, for example as an additional option such as:

Exclude directories containing:

".nobackup"

".NOBACKUP"

It should also support multiple entries, since marker names are case-sensitive and users may want to use different marker files.

I'll add this to the feature list and have a look at how it can be integrated cleanly into the existing job configuration.

Thanks for the suggestion — this is exactly the kind of feedback that helps improve the plugin. 🙂

Vielen Dank, dass du meinen Wunsch, die Logs um die Dateiaktivitätsausgabe zu erweitern, so schnell umgesetzt hast.

Ich habe gestern ein 1,2-TB-Archiv erstellt und zu Hetzner hochgeladen. Es hat alles absolut reibungslos funktioniert.

Die Funktion von bastl wäre sehr schön. Vielleicht könnte man auch gleich direkt eine EXCLUDE-Datei einbinden.
Dann müsste man nicht in jedem Ordner eine .nobackup-Datei anlegen, sondern könnte Dateien bzw. Ordner direkt darüber ausschließen.

Ich habe schon echt ein schlechtes Gewissen, hier noch mehr Funktionen anzufragen. 🫣

Thank you very much for implementing my request to add file activity output to the logs so quickly.

Yesterday, I created a 1.2 TB archive and uploaded it to Hetzner. Everything worked absolutely flawlessly.

The feature suggested by bastl would be really nice. Perhaps it would also be possible to directly include an EXCLUDE file.
That way, you wouldn’t have to create a .nobackup file in every folder, but could exclude files or folders directly through it.

I already feel a little guilty asking for even more features. 🫣

Translated with ChatGPT.

18 minutes ago, Thorsten said:

I'll add this to the feature list and have a look at how it can be integrated cleanly into the existing job configuration.

Thanks!

I noticed something else. I had to search for the section where you set up the “allowed restore path” for the third time now. From a UI perspective, users generally work from left to right, with the relevant settings located on the right-hand side. Placing this option in another tab is why I couldn’t find it 😅

It would be better to place it either directly on the restore settings or on the general settings page, where all the other paths are already managed.

Thanks

Hi Thorsten,

I think I found a bug. I tried to edit an existing backup job, more specifically, I only changed the Type ID from “config” to “pfsense” and left everything else unchanged. As soon as I clicked save, I received the following error: Fehler: Der Job wurde gespeichert, aber der Zeitplan konnte nicht übernommen werden: Unknown job key: config_localThe job now shows “Noch kein Backup durchgeführt” in the jobs tab. On the dashboard, I can see a newly created location. There are now two locations: the old “config” location and a new “pfsense” location. I had already created a backup using the old Type ID, which is still displayed on the dashboard. The new “pfsense” location is shown with a message indicating that this job has not been run yet.

Edit:

In the reports section, I can also see the "old" naming "config"

Edited September 5Sep 5 by bastl

Hi @bastl, @mikiunraid ,

thank you very much for the detailed feedback. It is also great to hear that the 1.2 TB backup to your Hetzner Storage Box completed successfully.

Both suggestions make sense, although they cover two slightly different use cases:

• --exclude-if-present would allow a job to skip directories containing marker files such as .nobackup or .NOBACKUP. I have recorded this in issue #469.

• --exclude-from would allow experienced Borg users to attach a central exclusion pattern file to a job. This requires some additional planning so that the file remains reliable across reboots, job exports, restores and future job migrations. The implementation options are documented in issue #470.

The existing individual path exclusions would remain available, and these new mechanisms could complement them.

And please do not feel guilty about suggesting additional features. Real-world feedback like this is extremely helpful for improving the plugin and deciding what should be added next. Thank you!

50 minutes ago, bastl said:

Hi Thorsten,

I think I found a bug. I tried to edit an existing backup job, more specifically, I only changed the Type ID from “config” to “pfsense” and left everything else unchanged. As soon as I clicked save, I received the following error: Fehler: Der Job wurde gespeichert, aber der Zeitplan konnte nicht übernommen werden: Unknown job key: config_localThe job now shows “Noch kein Backup durchgeführt” in the jobs tab. On the dashboard, I can see a newly created location. There are now two locations: the old “config” location and a new “pfsense” location. I had already created a backup using the old Type ID, which is still displayed on the dashboard. The new “pfsense” location is shown with a message indicating that this job has not been run yet.

Edit:

In the reports section, I can also see the "old" naming "config"

Hi @bastl ,

thank you for the detailed report. You have found a known design problem that is tracked in issue #447.

At the moment, the Type ID is unfortunately also part of the internal job identifier. Changing it from config to pfsense therefore changes the internal job key from config_local to pfsense_local.

The job itself is saved under the new key, but the existing schedule, previous run status and reports still reference config_local. This causes the schedule validation error and explains why:

• the new job shows that no backup has been performed yet;

• the dashboard shows both the old and new identities;

• reports still display the old config name.

Your existing Borg archives have not been deleted or moved. However, the schedule may no longer run correctly, so please do not rely on it until the job configuration has been corrected.

As a temporary workaround, changing the Type ID back to config should restore the previous association. Please verify the schedule afterwards and avoid changing the Type ID of existing jobs until #447 is implemented.

I am sorry about this design flaw. The Type ID should never have been used for so many different purposes.

Issue #447 will introduce an immutable internal job ID. The job name and archive prefix can then be changed without creating a second logical job or disconnecting schedules, status information and reports.

Unfortunately, this change will take some time because it affects many parts of the application. It also requires a very carefully designed and thoroughly tested migration for all existing installations. I do not want to rush such a migration and risk losing or incorrectly associating existing job data, schedules, reports or restore-test results.

Once an initial migration candidate is ready, anyone interested in testing it before the regular release is very welcome to contact me. Additional real-world test configurations would be extremely helpful.

Thank you again for finding and reporting this exact scenario. It provides valuable confirmation of the problem that #447 is intended to solve.

Viele Grüße
Thorsten

Hallo,

ich habe einen Job erstellt und die neue Funktion „Dateiaktivität im Live-Log“ aktiviert. Nachdem der Job bereits mehrere Minuten gelaufen war, wollte ich mir das Live-Log ansehen.

Das Log wurde jedoch nicht mehr angezeigt. Gleichzeitig war es nicht mehr möglich, irgendeine Aktion im Webinterface auszuführen. Die Oberfläche reagierte nicht mehr.

Zusätzlich habe ich beobachtet, dass meine UniFi ebenfalls nur noch eine Upload-Geschwindigkeit von unter 10 Mbps angezeigt hat. Nachdem ich den Job beendet und die Funktion „Dateiaktivität im Live-Log“ deaktiviert hatte, normalisierte sich die Verbindung wieder und der Upload erreichte erneut über 300 Mbps.

Im Browser wurde währenddessen ein „Timeout“ angezeigt.

Es scheint daher einen Zusammenhang zwischen der aktivierten Funktion „Dateiaktivität im Live-Log“, der starken Beeinträchtigung der Netzwerkgeschwindigkeit und dem nicht mehr reagierenden Webinterface zu geben.




Hello,

I created a job and enabled the new “File Activity in Live Log” feature. After the job had been running for several minutes, I wanted to take a look at the live log.

However, the log was no longer displayed. At the same time, it was no longer possible to perform any actions in the web interface. The entire interface became unresponsive.

I also noticed that my UniFi system was showing an upload speed of less than 10 Mbps. After I stopped the job and disabled the “File Activity in Live Log” feature, the network performance immediately returned to normal, with upload speeds of more than 300 Mbps.

During this time, the browser displayed a “Timeout” error.

It therefore appears that there may be a connection between the “File Activity in Live Log” feature, the significant reduction in network performance, and the web interface becoming unresponsive.

Edited September 5Sep 5 by mikiunraid

13 minutes ago, mikiunraid said:

Hallo,

ich habe einen Job erstellt und die neue Funktion „Dateiaktivität im Live-Log“ aktiviert. Nachdem der Job bereits mehrere Minuten gelaufen war, wollte ich mir das Live-Log ansehen.

Das Log wurde jedoch nicht mehr angezeigt. Gleichzeitig war es nicht mehr möglich, irgendeine Aktion im Webinterface auszuführen. Die Oberfläche reagierte nicht mehr.

Zusätzlich habe ich beobachtet, dass meine UniFi ebenfalls nur noch eine Upload-Geschwindigkeit von unter 10 Mbps angezeigt hat. Nachdem ich den Job beendet und die Funktion „Dateiaktivität im Live-Log“ deaktiviert hatte, normalisierte sich die Verbindung wieder und der Upload erreichte erneut über 300 Mbps.

Im Browser wurde währenddessen ein „Timeout“ angezeigt.

Es scheint daher einen Zusammenhang zwischen der aktivierten Funktion „Dateiaktivität im Live-Log“, der starken Beeinträchtigung der Netzwerkgeschwindigkeit und dem nicht mehr reagierenden Webinterface zu geben.




Hello,

I created a job and enabled the new “File Activity in Live Log” feature. After the job had been running for several minutes, I wanted to take a look at the live log.

However, the log was no longer displayed. At the same time, it was no longer possible to perform any actions in the web interface. The entire interface became unresponsive.

I also noticed that my UniFi system was showing an upload speed of less than 10 Mbps. After I stopped the job and disabled the “File Activity in Live Log” feature, the network performance immediately returned to normal, with upload speeds of more than 300 Mbps.

During this time, the browser displayed a “Timeout” error.

It therefore appears that there may be a connection between the “File Activity in Live Log” feature, the significant reduction in network performance, and the web interface becoming unresponsive.

Vielen Dank für die ausführliche Rückmeldung. Das Verhalten ist so natürlich nicht vorgesehen und ich möchte versuchen, das Problem möglichst genau nachzustellen.

Könntest du mir dazu noch ein paar Informationen geben?

• Wie viele Dateien enthält die Sicherung ungefähr?

• Wie groß ist die gesamte zu sichernde Datenmenge?

• Handelt es sich überwiegend um viele kleine Dateien oder eher um größere Dateien?

• Welchen Repository-Typ verwendest du für diesen Job (Local, SMB oder SSH)?

• Nach ungefähr welcher Laufzeit ist dir der starke Geschwindigkeitseinbruch bzw. der Timeout aufgefallen?

• War zu diesem Zeitpunkt das komplette Borg Backup UI nicht mehr erreichbar oder nur das Live-Log?

• Falls du es beobachtet hast: War die CPU- oder RAM-Auslastung des Unraid-Servers zu diesem Zeitpunkt auffällig hoch?

Wenn möglich, wäre außerdem ein Support-Paket direkt nach Auftreten des Problems sehr hilfreich. Du findest die Funktion unter Settings → Import / Export. Persönliche Informationen werden darin entsprechend maskiert.

Bis ich die Ursache genauer untersucht habe, würde ich empfehlen, „Dateiaktivität im Live-Log“ vorerst deaktiviert zu lassen.

Vielen Dank fürs Testen! Das hilft mir sehr dabei, das Verhalten unter größeren realen Backups nachzustellen.

Support-Pakete immer nur per PN.

Thanks for the detailed feedback. This behavior is obviously not intended, and I'd like to reproduce the issue as accurately as possible.

Could you provide me with a few additional details?

• Approximately how many files are included in this backup?

• What is the total amount of data being backed up?

• Does the backup mainly consist of many small files, or mostly larger files?

• Which repository type are you using for this job (Local, SMB, or SSH)?

• Approximately how long had the backup been running when you noticed the significant performance drop and the timeout?

• At that point, was the entire Borg Backup UI unresponsive, or only the Live Log?

• If you happened to notice it: Was there unusually high CPU or RAM usage on the Unraid server at that time?

If possible, a support package created shortly after the issue occurs would also be very helpful. You can create one under Settings → Import / Export. Personal information is masked accordingly.

Until I've investigated the cause in more detail, I would recommend leaving “File activity in Live Log” disabled for now.

Thanks again for testing and reporting this. It will help me reproduce the behavior with larger real-world backup sets and identify what is causing the performance impact.

Please always send support packages via private message (PM) only.

Hi @mikiunraid ,

I was able to reproduce the performance issue on my system.

With “File activity in Live Log” enabled during an Appdata backup, the log file grew from approximately 18 KB to 4.6 MB.

During this single backup run, approximately 38,111 additional log lines were written due to the file activity logging.

This confirms that the current implementation can generate a very large amount of log output, which is likely contributing to the performance issues and the Live Log/UI becoming unresponsive.

I’ll investigate how to optimize the file activity logging so that it does not negatively affect backup performance or the web interface.
See Issue #463

Ich habe dir eine PM geschrieben.

Das den APPDATA Ordner habe ich ausgeklammert.

Edited September 5Sep 5 by mikiunraid

Update 2026.09.06.0112 – Live log improvements for file activity

Hi everyone,

This update improves the optional File activity in the live log feature. During large backups with many file entries, the log viewer could become increasingly slow or freeze the browser tab.

What has improved:

• The viewer now loads the log in sections, keeping the browser responsive. Every recorded entry is retained, and the complete log remains available for download.

• The viewer follows new lines through job completion. Scrolling back pauses automatic following; Jump to end resumes it.

• ↑ Previous section and ↓ Next section let you navigate through the log. Flickering and the temporarily half-empty view during small updates have been fixed.

Log storage has also changed: With file activity enabled, the active log is initially stored in RAM. Once the entire job has finished, including cleanup and restarting services, the complete log is saved to the configured log directory and its RAM is released.

This helps when the log directory itself is included in the backup: the current log no longer changes a file in that directory during the backup. It will therefore only be included in a subsequent backup.

RAM usage grows approximately with the log size. A server restart or power loss before saving will lose the log still held in RAM. Restarting only the WebUI process does not interrupt final log persistence.

With file activity disabled, the existing live viewer and direct logging to the configured directory remain unchanged. The option is still disabled by default and configured per job.

Habe es gerade getestet. Die Anpassung hat sehr gut funktioniert.
DANKE

Borg Backup UI 2026.09.07.0935 – Directory permissions fix

This version fixes a plugin installation and update issue: older packages could

change shared Unraid system-directory permissions from 755 to 775, including

/, /etc and /usr. This could also prevent SSH public-key login.

The corrected package preserves existing directory permissions and ownership.

A before/after installation test on Unraid 7.4.0 Beta 2 confirmed unchanged values

for all twelve inspected paths, immediately after installation and without a reboot.

If an earlier version has already changed your permissions:

On the tested system, a normal Unraid reboot restored the original permissions.

Borg Backup UI remained installed and was running afterwards. Please check the

permissions after rebooting. The update itself does not automatically repair

permissions that were changed previously.

Recovery instructions are included in both the German and English user manuals,

under 13.6 – Directory Permissions Changed After Plugin Installation. Recovery

by reboot was confirmed on Unraid 7.4.0 Beta 2.

Details and test results: [Issue #484](https://github.com/borgforge/borg-backup-ui/issues/484).

Edited September 7Sep 7 by Thorsten