Hallo zusammen.

Kurze Frage: Wo finde ich denn die Einstellungen um die Restore Jobs zu planen? Unter Restore-Tests finde ich nur ob geplant, Intervall und das Level, was ich konfigurieren kann, nicht welchen Tag des Monats oä. Der Hinweis "Die zentrale Steuerung erfolgt in Planung & Policy pro Job. Diese Seite führt den fälligen Plan aus und zeigt die Ergebnisse." hilft leider auch nicht viel, da unter den Job Einstellungen selbst nichts von Restore Test zu finden ist. Bin ich blind, läuft der Task dann automatisch nach dem Backup wenn das Intervall überschritten wurde, oder ist das noch noch nicht implementiert.

Danke

Hallo bastl,

Alle Restore Test Einstellungen sind diese hier:
Im Basis Bereich kann man den Intervall festlegen leider keine bestimmten Tag.
Dann das Test Level und welche Location alle getestet werden sollen. Man muss hier etwas probieren weil Test z.b auf einem SSH Storage lange dauern können Level 2 und 3 würden Daten vom SSH Storage herunterladen.

Die anderen Parameter beinflussen die Testabdeckung. z.B. 5 % oder maximal 1000 Files. Also wenn die 5% mehr als 1000 Files sind werde nur maximal 1000 Files geprüft.
Level 3 Sample Dateien also richtiger restore mit Checksummen vergleich gibt an viele Dateien wiederherstellt und geprüft werden sollen.

Wie gesagt hier muss man mit den Einstellungen etwas spielen wie lange so ein Test dauert. Leider gilt dieses zur Zeit noch Global also für alle Restore Tests gleich.

Nachtrag:
Bei den automatischen Restore-Tests ist ein Fehler aufgefallen: Die Einstellung „Geplant“ speichert zwar das Testintervall, legt aber keinen Cron-Eintrag an. Wenn noch kein entsprechender Zeitplan vorhanden ist, werden fällige Tests deshalb nicht automatisch gestartet.

Die Tests lassen sich weiterhin manuell ausführen. Der Fehler ist unter GitHub-Issue #493 erfasst

Edited September 7Sep 7 by Thorsten
Nachtrag

@bastl
Du kannst gerne auch Feature-Wünsche als GitHub-Issue einreichen:

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

Leider habe ich noch nicht alles berücksichtigt. Das Projekt ist ursprünglich aus Shell-Skripten entstanden, wurde später auf Python umgestellt und schließlich zu diesem Plugin weiterentwickelt.

Aktuell arbeite ich daran, einen Designfehler zu beheben: Die Jobs haben bisher keine dauerhafte, eindeutige ID. Damit hängt auch das von dir gemeldete Problem mit der Type-ID zusammen.

Die Type-ID wird derzeit für mehrere Zwecke verwendet. Wenn man sie ändert, kann es zu Problemen bei der Darstellung im Dashboard und der Zuordnung von Daten zum jeweiligen Job kommen. Künftig soll deshalb eine feste Job-ID für die eindeutige Zuordnung sorgen, während Jobname und Archivpräfix weiterhin änderbar bleiben.

Diese Korrektur hat momentan die höchste Priorität, da sie die gesamte Anwendung betrifft.

Edited September 7Sep 7 by Thorsten

18 minutes ago, Thorsten said:

Diese Korrektur hat momentan die höchste Priorität, da sie die gesamte Anwendung betrifft.

Kann ich nachvollziehen. Was ich von meinen Tests her sehen konnte, funktioniert das meiste ja auch schon super. Bisher sind mir nur Kleinigkeiten aufgefallen was Bedienerfreundlichkeit angeht, was keine prio hat, wie die recht versteckte Option für den Restore-Test-Pfad.

Eine genauere Job Planung für die Tests wäre dennoch in meinen Augen sinnvoll. Aktuell sag ich geplant, stell nen Intervall ein das Level, drücke Speichern und ein Klick auf "Jetzt Testen" entscheidet dann an welchem Tag und welche Uhrzeit der Test läuft. Ist so nicht gerade ideal keinen wirklichen Einfluß auf die Ausführungszeit zu haben. Dass so ein Test je nach größe des Repos und je nach Quelle auch schnell mal sehr lange dauern kann ist mir bewußt. Ein Hinweis dazu gibt es ja auch bereits, schonmal gut. Dennoch müßte man irgendwie dem User eine Option geben es detailierter konfigurieren zu können.

2 Kleinigkeiten hätte ich an dieser Stelle noch:

1. für die Zeitplanung sowie Retention eine stündliche Option -H, --keep-hourly wäre super und

2. ein Möglichkeit gezielt von Hand einzelne Backups aus einem Repo löschen zu können wäre noch toll. Durch meine Tests und durch die Typ-ID Umbenennung hatte ich in dem betreffenden Repo dann 3 Archive die angezeigt wurden aber nur 2 ausgelesen wurden. Löschen konnte ich über das WEB-UI das unter anderer "Typ-ID" erstellte Backup dann nicht und mußte übers Terminal ran.

Einen Github Account um Feature Requests einzureichen besitze ich nicht, sonst hätte ich das bereits getan, deswegen an dieser Stelle.

und vielen Dank nochmal für dieses Projekt.

20 minutes ago, bastl said:

Kann ich nachvollziehen. Was ich von meinen Tests her sehen konnte, funktioniert das meiste ja auch schon super. Bisher sind mir nur Kleinigkeiten aufgefallen was Bedienerfreundlichkeit angeht, was keine prio hat, wie die recht versteckte Option für den Restore-Test-Pfad.

Eine genauere Job Planung für die Tests wäre dennoch in meinen Augen sinnvoll. Aktuell sag ich geplant, stell nen Intervall ein das Level, drücke Speichern und ein Klick auf "Jetzt Testen" entscheidet dann an welchem Tag und welche Uhrzeit der Test läuft. Ist so nicht gerade ideal keinen wirklichen Einfluß auf die Ausführungszeit zu haben. Dass so ein Test je nach größe des Repos und je nach Quelle auch schnell mal sehr lange dauern kann ist mir bewußt. Ein Hinweis dazu gibt es ja auch bereits, schonmal gut. Dennoch müßte man irgendwie dem User eine Option geben es detailierter konfigurieren zu können.

2 Kleinigkeiten hätte ich an dieser Stelle noch:

1. für die Zeitplanung sowie Retention eine stündliche Option -H, --keep-hourly wäre super und

2. ein Möglichkeit gezielt von Hand einzelne Backups aus einem Repo löschen zu können wäre noch toll. Durch meine Tests und durch die Typ-ID Umbenennung hatte ich in dem betreffenden Repo dann 3 Archive die angezeigt wurden aber nur 2 ausgelesen wurden. Löschen konnte ich über das WEB-UI das unter anderer "Typ-ID" erstellte Backup dann nicht und mußte übers Terminal ran.

Einen Github Account um Feature Requests einzureichen besitze ich nicht, sonst hätte ich das bereits getan, deswegen an dieser Stelle.

und vielen Dank nochmal für dieses Projekt.

Vielen Dank für das ausführliche Feedback!

Die beiden Punkte nehme ich auf jeden Fall mit auf:

1. Stündliche Retention (--keep-hourly)

2. Gezieltes manuelles Löschen einzelner Archive/Backups über die Weboberfläche

Gerade die Möglichkeit, einzelne Archive manuell zu entfernen, ist für solche Fälle wie bei deiner Typ-ID-Umbenennung sinnvoll. Dafür sollte man nicht extra auf das Terminal ausweichen müssen.

Auch den Bereich Restore-Tests und deren Planung werde ich noch einmal grundlegend überarbeiten. Die aktuelle Planung ist tatsächlich noch nicht optimal und einige der Punkte sind mir bei meinen eigenen Tests ebenfalls schon aufgefallen.

Neben einer detaillierteren Zeitplanung – beispielsweise mit Wochentag und Uhrzeit – möchte ich dabei auch mögliche Überschneidungen mit regulären Backup-Jobs berücksichtigen. Bei der Planung sollte geprüft bzw. darauf hingewiesen werden, wenn ein Restore-Test zeitlich zu nah an einem geplanten Backup liegt.

Falls ein Restore-Test zum Zeitpunkt eines geplanten Backup-Jobs noch läuft, sollte der Backup-Job nicht einfach parallel gestartet werden. Denkbar wäre, diesen Lauf zu überspringen und das auch entsprechend in der History bzw. über die Benachrichtigungen zu melden, z. B. „Backup übersprungen – Restore-Test läuft noch“.

Gerade bei größeren Repositories und höheren Test-Leveln kann die Laufzeit schließlich erheblich sein. Das sollte die Planung entsprechend berücksichtigen.

Die bereits angesprochene etwas versteckte Einstellung für den erlaubten Restore-Pfad gehört ebenfalls zu den Punkten, bei denen ich die Bedienung noch verbessern möchte.

Du brauchst übrigens keinen GitHub-Account dafür. Solches Feedback hier im Forum ist genauso hilfreich – ich übernehme die entsprechenden Punkte dann in die weitere Planung bzw. in GitHub.

Vielen Dank fürs Testen und für die konkreten Rückmeldungen!

Ich suche etwa fünf freiwillige Tester für die Umstellung auf dauerhafte Job-IDs in Borg Backup UI.

Meine bisherigen Tests sind erfolgreich. Bevor ich die Version allgemein veröffentliche, möchte ich prüfen, ob die Migration auch mit anderen bestehenden Installationen und Konfigurationen zuverlässig funktioniert.

Bei Interesse bitte per PN melden, möglichst mit Unraid-Version, Anzahl der Jobs und verwendeten Speicherzielen wie Lokal, USB, SMB oder SSH. Die Testversion und weitere Informationen erhaltet ihr anschließend von mir.

Wichtig vor dem Update:

• Laufende Backup- und Restore-Vorgänge abschließen lassen und den Plugin-Dienst vor der Sicherung stoppen.

• Die bisherigen Konfigurations- und Datenverzeichnisse vollständig sichern, einschließlich versteckter Dateien. Die Sicherung außerhalb dieser Verzeichnisse aufbewahren.

• Beispielpfade sind /boot/config/borg-backup und /mnt/user/borg_backup_ui. Die tatsächlichen Pfade hängen von eurer Konfiguration ab. Separat konfigurierte Datenverzeichnisse ebenfalls berücksichtigen.

Hinweis zu bisherigen Exporten: Alte Job- und Profilexporte der Anwendung können mit dieser Testversion nicht mehr importiert werden. Nach erfolgreichem Update und abgeschlossener Migration müssen neue Exporte erstellt werden. Vorhandene Borg-Backup-Archive bleiben verwendbar und müssen nicht neu erstellt werden.

Beim ersten Start läuft die Migration automatisch. Je nach Anzahl der Jobs und Dateien sowie Geschwindigkeit des Speichers kann sie mehrere Minuten benötigen. Währenddessen ist die Weboberfläche noch nicht erreichbar, weil der Webserver erst anschließend gestartet wird. Bitte die laufende Migration nicht unterbrechen.

Den Fortschritt könnt ihr im Unraid-Terminal verfolgen:

tail -n 100 -F /var/log/borg_backup_ui.log

Im Log erscheinen beispielsweise folgende Meldungen, hier gekürzt:

Migration job_ids_v1: Saving recovery copies ...
Migration job_ids_v1: Updating job references ...
Migration job_ids_v1: Verifying migrated files ...
Startup migrations: status=ok, ... failed=[]
Borg Backup UI started: http://...

Die Fortschrittsmeldungen enthalten Dateizähler und die bisherige Dauer. Nach erfolgreichem Start bitte prüfen, ob Jobs, Einstellungen, Zeitpläne, History und Restore-Ergebnisse korrekt vorhanden sind.

Bei Fehlern bitte den relevanten Logausschnitt per PN melden und vorher auf vertrauliche Informationen prüfen. Vielen Dank fürs Mithelfen!

Hi everyone,

I’ve put together a short video showing Borg Backup UI for Unraid in action — from creating a backup job to restoring a file and checking that a backup can be restored.

The walkthrough covers:

• Storage profiles and repositories

• Creating jobs, scheduling backups and configuring retention

• Running a backup and reviewing its log and history

• Browsing archives and restoring individual files

• Automated restore tests and their reports

• Repository maintenance and notification settings

The video was recorded using the current test version with demo data. This version introduces permanent job IDs, keeping jobs consistently linked to their history and restore results when their names or archive prefixes change.

I hope this gives both existing users and anyone considering the plugin a useful overview. Questions and feedback are welcome!

Edited September 14Sep 14 by Thorsten

Borg Backup UI 2026.09.13.1711 – Flexiblere Aufbewahrung und Ausschlüsse

Die neue Version erweitert die Aufbewahrungsregeln, ergänzt neue Ausschlussmöglichkeiten und verbessert die Repository-Verwaltung.

Neue Aufbewahrungsoptionen

Im Job-Wizard stehen jetzt drei Strategien zur Auswahl:

• Gestaffelt: Stunden-, Tages-, Wochen-, Monats- und Jahresstände kombinieren. Optional zusätzlich alle Archive eines jüngeren Zeitfensters behalten.

• Letzte X Archive: Beispielsweise die letzten drei passenden Archive behalten, unabhängig davon, an welchen Tagen sie erstellt wurden.

• Alle behalten: Automatisches Löschen durch Prune für den Job ausschalten.

Bestehende Jobs behalten ihre bisherigen Aufbewahrungsregeln. Info-Dialoge erklären die Einstellungen anhand von Beispielen. Leere Regeln und reine Zeitfensterregeln sind gesperrt, damit eine längere Backup-Pause nicht alle Archive zur Löschung freigibt.

Die Aufbewahrung gilt für den aktuellen Archivpräfix des Jobs. Archive mit früheren Präfixen bleiben zusätzlich erhalten.

Eigener Wizard-Schritt für Ausschlüsse

Ausschlusspfade, Markerdateien und eine hochgeladene Ausschlussdatei sind jetzt gemeinsam auf einer eigenen Seite sichtbar.

• Mit einer Markerdatei wie .nobackup lassen sich ganze Ordner einschließlich ihrer Unterordner vom Backup ausschließen.

• Pro Job kann eine Textdatei mit Borg-Ausschlussmustern hochgeladen werden. Die Anwendung speichert eine eigene Kopie, die heruntergeladen, ersetzt, entfernt und mit dem Job exportiert werden kann.

• Alle neun Wizard-Schritte behalten dieselbe Fenstergröße. Breitere Eingabefelder machen lange Verzeichnispfade besser lesbar.

Weitere Verbesserungen

• Administratoren können einzelne Archive unter Repositories > Archive löschen. Zur zusätzlichen Bestätigung muss DELETE eingegeben werden. Protokolle und Laufhistorie bleiben erhalten. Compact gibt anschließend ungenutzten Speicherplatz frei.

• Die Archivanzahl im Reiter und in der Übersicht folgt jetzt der geladenen Archivliste.

• Apprise wurde auf 1.13.1 aktualisiert und bietet 141 Benachrichtigungsanbieter.

Kompatibilitätshinweise: Job-Exporte mit den erweiterten Einstellungen verwenden ein neues Format, das ältere Plugin-Versionen nicht importieren können. Apprise unterstützt NotificationAPI nicht mehr; betroffene Profile zeigen einen Hinweis zur Neukonfiguration. Gespeicherte Einstellungen und Zugangsdaten bleiben erhalten.

Das Update ist über Unraid > Plugins verfügbar. Vielen Dank für eure Rückmeldungen und Tests!

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!

Edited September 18Sep 18 by Thorsten

Fehler bei der Installation

Downloading plugin
plugin: 407DdGdQkgri_hHaOvYJ_orNBXjCwBLtnfIMw4N6oQI3OmYPr5c3tP1rH20nkBh0fVsilWiM1LRWYH4dG2ZlRwvyspyIyVhr8RxdO8JzUgt4jdLGPk9hK6ool-NcV-SypwMFkenBAeeuoOc9BkQ6KQ is not a plg file

8 minutes ago, dibux said:

Fehler bei der Installation

Downloading plugin
plugin: 407DdGdQkgri_hHaOvYJ_orNBXjCwBLtnfIMw4N6oQI3OmYPr5c3tP1rH20nkBh0fVsilWiM1LRWYH4dG2ZlRwvyspyIyVhr8RxdO8JzUgt4jdLGPk9hK6ool-NcV-SypwMFkenBAeeuoOc9BkQ6KQ is not a plg file

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

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

2 hours ago, Thorsten said:

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

Nur 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 konnte das plugin manuell über den plg link installieren. Scheinbar liegt es an meinem setting, denn pyhton ging auch nur über den plg link, ansonsten ähnliche Fehlermeldung

Danke für deine Rückmeldung und Arbeit. Werde jetzt nach der Installation auf dem neuen System ausgiebig testen. (PS: borgui (docker was ich sonst nutze, bietet ein cooles restore test feature, leider keine Ahnung wie es funktioniert, aber es geht sehr schnell und nicht wird irgendwohin restored ;-))

11 minutes ago, dibux said:

Ich konnte das plugin manuell über den plg link installieren. Scheinbar liegt es an meinem setting, denn pyhton ging auch nur über den plg link, ansonsten ähnliche Fehlermeldung

Danke für deine Rückmeldung und Arbeit. Werde jetzt nach der Installation auf dem neuen System ausgiebig testen. (PS: borgui (docker was ich sonst nutze, bietet ein cooles restore test feature, leider keine Ahnung wie es funktioniert, aber es geht sehr schnell und nicht wird irgendwohin restored ;-))

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.

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.

Hallo,

bei mir zeigt das Dashboard-Widget einen statischen Stand an (siehe Bilder)

Die Icons oben rechts sind auch schwer zu erkennen durch die Farbgebung

---

Beste Grüße Dirk

6 hours ago, dibux said:

Hallo,

bei mir zeigt das Dashboard-Widget einen statischen Stand an (siehe Bilder)

Die Icons oben rechts sind auch schwer zu erkennen durch die Farbgebung

---

Beste Grüße Dirk

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

Hallo, mir ist noch etwas aufgefallen (ich kann es erst mal nicht nachvollziehen, warum diese Warnung da ist) ;-) Der Job ist ja nach meinem Verstehen nicht überfällig

Danke und beste Grüße

Dirk

1 hour ago, dibux said:

Hallo, mir ist noch etwas aufgefallen (ich kann es erst mal nicht nachvollziehen, warum diese Warnung da ist) ;-) Der Job ist ja nach meinem Verstehen nicht überfällig

Danke und beste Grüße

Dirk

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

Edited September 29Sep 29 by Thorsten

Hab dir den Log gesendet.

Notification ja (unraid only)

Hallo Dirk,

ich sichere täglich mein appdata Verzeichnis, wozu auch die Docker gestoppt und später wieder gestartet werden. Normalerweise dauert ein "Backuplauf" etwa 6 Minuten. Es passiert aber manchmal, dass ein Backuplauf ca. 60 Minuten dauert, und so lange sind auch alle Docker gestoppt.

Ich denke es liegt an "check" was wohl im Backuplauf mit ausgeführt wird, wenn es fällig ist (bei mir z.b. alle 30 Tage).

Ginge es, dass die Docker schon vor check wieder gestartet werden? Ich habe z.B. Openhab als Docker laufen, und in der "Downtime" geht z.B. die Garagentüre nicht auf 🤔

Grüße

Jochen

BBUI-Appdata_mit_Dockerstop_local_6fce9dfd-15df-4f4c-9abb-93d5a2bde1a3--2026-10-05_02-40-01.log

7 hours ago, Jochen.K said:

Hallo Dirk,

ich sichere täglich mein appdata Verzeichnis, wozu auch die Docker gestoppt und später wieder gestartet werden. Normalerweise dauert ein "Backuplauf" etwa 6 Minuten. Es passiert aber manchmal, dass ein Backuplauf ca. 60 Minuten dauert, und so lange sind auch alle Docker gestoppt.

Ich denke es liegt an "check" was wohl im Backuplauf mit ausgeführt wird, wenn es fällig ist (bei mir z.b. alle 30 Tage).

Ginge es, dass die Docker schon vor check wieder gestartet werden? Ich habe z.B. Openhab als Docker laufen, und in der "Downtime" geht z.B. die Garagentüre nicht auf 🤔

Grüße

Jochen

BBUI-Appdata_mit_Dockerstop_local_6fce9dfd-15df-4f4c-9abb-93d5a2bde1a3--2026-10-05_02-40-01.log

Hallo Jochen,

ja das kann ich ändern kommt in der nächsten Woche.

Viele Grüße

Thorsten