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