Thorsten

Ich werde mein möglichstes versuchen... bisher habe ich noch keine Informationen zum SDK für Plugins und zur den neuen Berechtigungen bekommen. An die Beta Phase zu Unraid 8 habe ich mich bereits angemeldet. Ggf. wird es so sein das es eine Version für ältere Unraid Version und eine für Unraid 8 geben wird. Von den Funktionen und Daten sind beide gleich. Nur intern wird es unterschiede in dem Aufbau geben was die kompabilität angehen wird. Weiteres kann ich erst sagen wenn ich weitere Informationen habe. Vielleicht wird es auch eine Docker Version geben, die unabhängig von Unraid sein wird. Gleiches betrifft auch dem Plugin Python3 for Unraid was mit dieser Version Unraid 7.x eingestellt wird. Ob Python3 auf Fedora Core standard mässig zur verfügung gestellt sein wird, weiß ich auch noch nicht. Es geht auf jedenfall weiter.... VG Thorsten

Hi Axel, thanks for reporting this. I checked the code and found a possible explanation: when creating a new job, “Enable schedule” is off by default. You can still change the time and weekdays, but those settings are only saved if you enable the schedule. In the three-dot menu, a new schedule is enabled by default. Could you please check the following? Which plugin version are you using? Was “Enable schedule” switched on when you saved the new job? If you repeat this with the switch enabled, is the schedule still missing after saving and reopening the job? Does any error message appear when saving? If it still happens, please send me a screenshot of the schedule settings before saving and any error message. Best regards, Thorsten

Mit der neuen Version kannst du ein Pre Skript und Post Skript pro Job Konfigurieren und über diese Skripte das WoL einbauen. Das wäre erstmal eine Lösung bis es Nativ unterstützt wird. Unter Einstellungen Skripte. Skripte für WoL anlegen fürs starten und herunterfahren des Zielssystems Skripte je Backup Job einbinden. Vielleicht wäre das eine vorab Lösung.

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.

Borg Backup UI – Version 2026.10.09.1435 Mit dieser Version kommen allgemeine Pre-/Post-Skripte hinzu. Außerdem verkürzen wir die Ausfallzeit von Docker-Containern während des Backups und verbessern die Fehleranzeige. Weniger Ausfallzeit für Docker und VMs: Container und virtuelle Maschinen werden nach der Archiverstellung wieder gestartet. Aufbewahrungsbereinigung, Komprimierung des Repositorys (compact) und Integritätsprüfung (check) laufen anschließend weiter. Allgemeine Pre-/Post-Skripte: Bash-Skripte lassen sich zentral unter Einstellungen → Skripte verwalten und im Job-Wizard zuordnen. Pre läuft vor allen Backup-Vorbereitungen, Post nach Wartung und Aufräumen. Optional läuft Post auch bei Fehlern, übersprungenen oder abgebrochenen Backups. Komfortabler Skripteditor: Bash-Syntaxhervorhebung, Zeilennummern, Syntaxprüfung beim Speichern und direkte Navigation zu Syntaxfehlern. Zusätzlich stehen Duplizieren sowie Import und Export als .sh-Datei zur Verfügung. Übersichtliche Zuordnungen: Eine einklappbare Liste zeigt, welche Jobs ein Skript verwenden. Zugeordnete Skripte sind gegen Löschen geschützt. Zentrale Änderungen gelten ab dem nächsten Jobstart. Klarere Fehleranzeige: Pre und Post erhalten eigene Phasen-Trenner im Log. History und Protokoll zeigen Skriptfehler samt Exitcode. Bei einem Pre-Fehler wird ausdrücklich angezeigt, dass das Backup nicht gestartet wurde. Ein Post-Fehler lässt ein bereits erstelltes Archiv bestehen. Verbesserte Oberfläche: Einheitliches Layout der Skriptverwaltung und korrigierte Hintergrundfarben in den History-Details. Unraid-Dashboard-Widget: Aktualisierte Zeitangaben, klarere Unterscheidung zwischen übersprungenen Backups und Warnungen sowie bessere Kontraste im hellen und dunklen Theme. Die Syntaxprüfung führt Skripte nicht aus. Beim Import werden zusätzlich die Bash-Kennzeichnung und das Dateiformat geprüft.

Hallo Jochen, ja das kann ich ändern kommt in der nächsten Woche. Viele Grüße Thorsten

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.

Hallo Dirk, danke für die Bilder! „Überfällig“ bezieht sich auf einen möglicherweise ausgebliebenen vergangenen Lauf. Deshalb kann gleichzeitig schon der nächste Termin angezeigt werden. Die Warnung deutet darauf hin, dass der Lauf am Montag, 28.09., um 03:15 Uhr nicht als erfolgt erkannt wurde. Ob das korrekt ist, muss ich noch prüfen. Auffällig sind außerdem die unterschiedlichen nächsten Termine in Übersicht und Zeitplandialog. Dein Cron-Ausdruck steht für Montag, Mittwoch und Freitag jeweils um 03:15 Uhr. Kannst du mir den Eintrag des letzten Laufs aus der History mit genauer Uhrzeit und Status schicken? Wurde der Zeitplan kürzlich geändert, und sind beide Screenshots unmittelbar nacheinander entstanden? Schau auch mal unter Einstellungen -> Erweitert Hast du eine Notification eingerichtet ? Hier würde man auch den zeitpunkt des lezten laufs sehen und die anderen Zeiten ggf. wann er als Überfällig makiert wird. Es kann durchaus sein das bei bestimmten Zeitplänen dieses akutell nicht passt. Beste Grüße

Hallo Dirk, danke für die Rückmeldung und die Screenshots! Das Widget liest einen zwischengespeicherten Status. Dabei können Zeitangaben wie „vor 14 Minuten“ unverändert bleiben, obwohl das Widget regelmäßig nach Daten schaut. Ob bei dir zusätzlich die Statusaktualisierung hängt, muss ich noch prüfen. Die schlechten Kontraste im hellen Theme sind ebenfalls nachvollziehbar. Außerdem zählt das Widget übersprungene Backups momentan als Warnung – daher die unterschiedliche Anzeige zum Dashboard. Ich habe die Punkte in Issue #546 aufgenommen. VG Thorsten

Hi, also ich würde mal folgendes probieren bzw. den Fehler in diesem Bereich suchen. Community Applications / Installationsaufruf kaputt Browser-/Session-/CSRF-Problem, bei dem statt der .plg-URL ein Token übergeben wird beschädigte Dateien unter /boot/config/plugins/ Probleme mit dem USB-Stick / Dateisystem eventuell ein kaputter Cache oder veraltete Plugin-Metadaten Was wird hier angezeigt ? ls -lah /boot/config/plugins/ ls -lah /boot/config/plugins-error/ ls -lah /var/log/plugins/Wenn du ein Plugin installierst was wird im syslog angezeigt ? tail -n 100 /var/log/syslog Der grüne Haken ist hier ziemlich sicher ein False Positive der GUI. Die relevante Meldung bleibt: is not a plg fileDas heißt praktisch: Der Installer bekommt schon den falschen Wert übergeben was man am Namen das Plugins sehen kann: plugin: WRcYEXqhIpdHeZiSN4reLQXFt0V2PDzHP80ZGZNydBKM_et9eRpVE7zDpqkDFs82AGOs4STueh3nX-cn7KPwaVOH_lkBb2dpPO4YLBqGGOT-2sXK4szchQtwWUHpyzHs-4vY2RyeIhGCHr4dVRpYf-v9i0wl so sollte es aussehen: Downloading plugin plugin: installing: activestreams.plg Executing hook script: CA_preHook Clearing Community Applications plugin cache Im syslog steht folgendes: Sep 25 15:29:34 TheTwist plugin-manager: executing inline script: /bin/bash '/tmp/inline1-activestreams.sh' Sep 25 15:29:34 TheTwist plugin-manager: creating: /boot/config/plugins/activestreams/activestreams-2026.08.20.txz - downloading from URL https://raw.githubusercontent.com/gthrift/activestreams-unraid/main/archive/activestreams-2026.08.20.txz Sep 25 15:29:34 TheTwist plugin-manager: checking: /boot/config/plugins/activestreams/activestreams-2026.08.20.txz - SHA256 Sep 25 15:29:34 TheTwist plugin-manager: running: upgradepkg --install-new --reinstall /boot/config/plugins/activestreams/activestreams-2026.08.20.txz Sep 25 15:29:34 TheTwist plugin-manager: executing inline script: /bin/bash '/tmp/inline3-activestreams.sh' Sep 25 15:29:35 TheTwist plugin-manager: activestreams.plg installed Vielleicht auch mal den Unterschied ein Plugin manuell installieren und per Community Apps was sagt das syslog ? Hast du vielleicht das aktiv? Adblocker / Pi-hole / AdGuard / DNS-Filter / Proxy. GitHub bzw. raw.githubusercontent.com kann blockiert oder umgeschrieben werden. Unraid-Threads nennen DNS- bzw. GitHub-Blocking ausdrücklich als Ursache für Plugin-Installationsprobleme.

Borg Backup UI 2026.09.23.0926 – Prometheus, Grafana und flexiblere Wiederherstellung Mit diesem Update erhält Borg Backup UI eine optionale Prometheus-Anbindung und ein eigenes Grafana-Dashboard. Das Dashboard zeigt Backup-Ergebnisse, aktive Jobs, Laufzeiten, Speicherverbrauch und Speichereinsparung sowie Restore-Testnachweise und geplante Tests. Filter nach Server, Standort, Repository und Job ermöglichen gezielte Ansichten. Die Einrichtung findet ihr unter Einstellungen → Integrationen → Prometheus & Grafana – inklusive Zugriffstoken, Konfigurationsvorlage und Dashboard-Download. Prometheus und Grafana werden separat benötigt; ein zusätzlicher Exporter ist nicht erforderlich. Die Integration ist standardmäßig deaktiviert. Die Metrikerfassung verwendet vorhandene Plugin-Daten und startet keine zusätzlichen Borg-Befehle. Verlaufsdaten entstehen ab Beginn der Prometheus-Erfassung. Auch Browse & Restore wird flexibler: Ihr könnt jetzt alle Archive des zugeordneten Repositories anzeigen oder ein eigenes Namensmuster wie documents-* verwenden. Damit lassen sich auch Archive anderer Anwendungen auswählen. Backup-Namen und Aufbewahrungsregeln bleiben unverändert. Ein zugeordneter Job ist vorerst weiterhin erforderlich.

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.

Okay ich habe mal geschau was die Doku von borg-ui sagt. Es gibt drei verschiedene Modi. Modus Was passiert Aufwand Managed Canary Payload Kleine Testdatei wird beim Backup mitgesichert und später extrahiert + geprüft sehr schnell Selected Probe Paths Bestimmte echte Dateien/Ordner werden testweise extrahiert abhängig von Auswahl Full Archive Drill Komplettes Archiv wird extrahiert langsam + hoher Platzbedarf Borg UI legt beim Backup einen kleinen verwalteten Canary-Payload mit ins Archiv. Beim Restore-Test wird dieser aus dem neuesten Archiv extrahiert und anschließend auf Vorhandensein, Größe und Hash geprüft. Das ist richtig, der Test ist dadurch sehr schnell. Meiner Meinung nach sagt er aber nur begrenzt etwas darüber aus, ob die eigentlichen Nutzdaten („Main Data“) im Backup vollständig und korrekt wiederherstellbar sind. Im Wesentlichen wird damit geprüft, ob das Repository zugänglich ist und die Testdatei erfolgreich aus dem Archiv wiederhergestellt werden kann. Die grundsätzliche Integrität bzw. Lesbarkeit des Repositories lässt sich auch auf andere Weise prüfen. Die anderen von BorgUI angebotenen Testmethoden bieten wir ebenfalls an. Je nachdem, wie die entsprechenden Parameter gesetzt werden, können gezielt echte Daten oder umfangreichere Restore-Tests durchgeführt werden. Die Einstellungsmöglichkeiten dafür sind aktuell allerdings noch etwas eingeschränkt bzw. nicht optimal gelöst. Das werde ich in einer späteren Version überarbeiten und benutzerfreundlicher gestalten. Bei Borg-Backup-UI Restore Test: L3 umfasst aktuell die Prüfungen von L1 und L2 plus eine zusätzliche Dateistichprobe: Repository-Zugriff: Erreichbarkeit und Zugriff mit den hinterlegten Zugangsdaten. Archiv: Neuestes Archiv ermitteln und Metadaten lesen. Restore-Probelauf: borg extract --dry-run – vollständig oder bei großen Archiven stichprobenartig, abhängig von den Einstellungen. Dateiinhalte extrahieren: Standardmäßig bis zu 5 zufällige Dateien vollständig als Datenstrom lesen, ohne sie auf dem Ziel abzulegen. Auch abhängig von den Einstellungen.

Der Fehler scheint mir der gleiche zu sein wie bei diesem Post: https://forums.unraid.net/topic/199361-plugin-borg-backup-ui-f%C3%BCr-unraid/page/2/#findComment-1635048 Damals habe ich umfolgendes gebeten mal diese befehle auszuführen. ls -la /boot/config/plugins/borg-backup-ui ls -la /usr/local/emhttp/plugins/borg-backup-ui installplg https://raw.githubusercontent.com/borgforge/borg-backup-ui/main/borg-backup-ui.plgNur mit dem oben gennanten Text kann ich nichts anfangen. Diese Meldung habe ich bisher nur einmal bekommen und ist bei mir noch nie aufgetreten. Egal ob ich vom Release oder Test Chanel installieren.

Ich habe eine APC Back UPS PRO BR900G-GR So sieht es in Unraid aus. Der Verbrauch kann hoch sein ja. Habe 10x Segate Exos Festplatten drin. Aktuell läuft der Parity Check und es läuft eine VM Linux mit einer RTX 3060 im Passthrough. Ich bin sehr damit zufrieden und hat mir schon einpaar mal den Arsch gerettet. USV für Computer, Multimedia und SoHo-Anwendungen Kapazität: 900VA, 540W (ca. 4,6 Min. Autonomie bei Vollast) Ausgänge: 5x Schuko (2 nur Überspannschutz) 1x RJ-45, 1x RJ-11, Automatische Spannungsregulierung (AVR) Grüner Betriebsmodus, Shutdown-Software

Vorschau: Grafana-Dashboard für Borg Backup UI Ich arbeite aktuell an einer optionalen Prometheus-Anbindung mit einem passenden Grafana-Dashboard für Borg Backup UI. Damit bekommt ihr eure Backups, den Speicherverbrauch und die Restore-Tests übersichtlich auf einen Blick: Farbige Statuskarten für jeden Backup-Job und Standort. Repository-Größen, Archivanzahl und Einsparung durch Kompression und Deduplizierung. Vergleich der größten Archive und der neu gespeicherten Datenmenge. Restore-Testnachweise, deren Gültigkeit und die nächsten geplanten Tests. Hinweise auf überfällige Backups und Restore-Tests. Filter nach Server, Standort, Repository und Job. Der Exporter ist direkt im Plugin integriert und lässt sich aktivieren oder deaktivieren. Benötigt werden eine eigene Prometheus- und Grafana-Installation. Die Datenerfassung nutzt vorhandene Statusdaten und zwischengespeicherte Repository-Informationen – zusätzliche Borg-Aufrufe werden dafür nicht gestartet. Das Dashboard befindet sich aktuell in der Testphase. Die Screenshots zeigen den aktuellen Entwurf. Welche Informationen würdet ihr dort besonders gerne sehen? Feedback zur Darstellung ist ebenfalls willkommen!

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

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.

Fixed with Borg Backup UI – Update 2026.09.17.1618

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.

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 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!

Kann ich als langjähriger Informatiker nur unterschreiben. Ich bin mittlerweile 50 und nutze KI selbst täglich – beruflich wie auch privat. KI ist ein unglaublich mächtiges Werkzeug und kann einem enorm viel Arbeit abnehmen. Aber sie hat eben auch ihre Tücken und macht manchmal Dinge, die man weder erwartet noch wollte. Gerade deshalb sollte man zumindest verstehen, was die KI da eigentlich macht, und Ergebnisse auch kritisch hinterfragen können. Ein Punkt, den man dabei ebenfalls nicht unterschätzen sollte, ist der Umgang mit sensiblen Daten. Wer einer KI bzw. einem KI-Agenten weitreichenden Zugriff auf sein Unraid-System gibt, sollte sich bewusst sein, dass dieser dabei unter Umständen auch mit Konfigurationen, API-Tokens, SSH-Keys, Passwörtern oder anderen Zugangsdaten in Berührung kommen kann. Man sollte sich daher genau anschauen, welche Daten an den jeweiligen Dienst übertragen werden können, welche Berechtigungen man erteilt und wie der Anbieter mit diesen Daten umgeht. Am Ende ist KI eben ein Werkzeug – und wie gut oder sicher das Ergebnis wird, hängt auch stark davon ab, wie man damit umgeht. Daher kann ich meinem Vorredner nur zustimmen. 👍

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.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!