Thorsten

Eine MQTT-Anbindung ist geplant. Ich würde sie in zwei Schritten umsetzen: In der ersten Version würde Borg Backup UI seine Statusinformationen an einen vorhandenen MQTT-Broker senden. Über Home Assistant MQTT Discovery sollen die passenden Geräte und Sensoren automatisch erkannt werden. Diese könnt ihr dann in eure Dashboards und Automationen aufnehmen. Geplant wären beispielsweise: Backup läuft gerade Ergebnis und Dauer des letzten Backups Zeitpunkt des letzten erfolgreichen Backups Nächster geplanter Lauf und überfällige Backups Status und Gültigkeit des letzten Restore-Tests Erreichbarkeit von Borg Backup UI Broker-Adresse, Zugangsdaten und optional TLS wären im Plugin konfigurierbar. Als Standard für die Topics würde ich borg-backup-ui verwenden. Mehrere Unraid-Server sollen sich eindeutig unterscheiden lassen. Die erste Version wäre damit zunächst für Anzeige und Überwachung gedacht. Ein nicht erreichbarer MQTT-Broker darf die Backups nicht beeinträchtigen. Nach einer Wiederverbindung sollen die aktuellen Zustände erneut übertragen werden. In einer weiteren Version könnte ich mir zusätzlich eine ausdrücklich aktivierbare Steuerung aus Home Assistant vorstellen – etwa einzelne Backup-Jobs oder Restore-Tests starten. Dabei würden weiterhin die bestehenden Job-Sperren und Prüfungen von Borg Backup UI gelten. Das wäre zunächst der geplante Umfang; einen festen Veröffentlichungstermin gibt es noch nicht.

Ja, eine MQTT-Integration ist grundsätzlich machbar und würde gut passen. Mit Home Assistant MQTT Discovery könnten beispielsweise Backup-Status, letzter erfolgreicher Lauf, Laufzeit und überfällige Backups automatisch als Sensoren bereitgestellt werden. Die benötigten Daten sind größtenteils bereits im Plugin vorhanden. Aktuell ist MQTT noch nicht integriert; es wäre eine sinnvolle Erweiterung. :-)

Borg Backup UI – Update 2026.11.02.1337 This update adds configurable Docker ordering per backup job, interface improvements, and notification and security updates. Docker ordering per job: Containers can now be reordered using drag-and-drop or arrow buttons in the job wizard. After the backup, they start from top to bottom; before the backup, they stop individually in reverse order. A database placed at the top therefore stops last and starts first. Many thanks to JonaxScript for this contribution! More compact Docker help: Start and stop ordering guidance is available through a help link in the wizard. More visible overdue backups: Collapsed job cards now show an overdue indicator alongside the last run result. Improved navigation: The location selector in the Jobs view no longer overlaps headings or cards while scrolling. Expanded Job and Restore Test cards scroll into view when needed. Background refreshes do not move the page. Updated notifications: Apprise has been upgraded to 2.1.0, with 158 base providers available. Notification timeouts are now respected during background delivery and profile tests. Security updates: Bundled certifi, OAuthlib and urllib3 libraries have been updated to address reported security issues in these dependencies. Update notes: Existing notification profiles and credentials are preserved. Amazon Chime is no longer supported; affected profiles display a warning and require a different provider. URL options are validated more strictly, and legacy PGP email options have changed. Saved URLs and credentials are not automatically rewritten. A notification timeout counts as a failed attempt. Requests already in progress may still arrive later, so retries can result in duplicate notifications. A custom Docker order replaces the existing backup.start.priority groups and their pauses for the listed containers. It does not wait for application readiness. Jobs without a custom order retain their previous behavior.

Borg Backup UI – Update 2026.11.02.1337 Das neue Update bringt eine konfigurierbare Docker-Reihenfolge pro Backup-Job, Verbesserungen an der Oberfläche sowie Aktualisierungen für Benachrichtigungen und Sicherheit. Docker-Reihenfolge pro Job: Im Job-Assistenten lassen sich Container per Drag-and-drop oder Pfeiltasten sortieren. Nach dem Backup starten sie von oben nach unten, vor dem Backup stoppen sie einzeln in umgekehrter Reihenfolge. Eine oben einsortierte Datenbank stoppt damit zuletzt und startet zuerst. Vielen Dank an JonaxScript für diesen Beitrag! Kompaktere Docker-Hilfe: Die Erklärung zur Start- und Stoppreihenfolge ist über einen Hilfelink im Assistenten erreichbar. Überfällige Backups besser sichtbar: Ein entsprechender Hinweis erscheint jetzt bereits in eingeklappten Job-Karten, zusätzlich zum Ergebnis des letzten Laufs. Verbesserte Navigation: Die Standortauswahl in der Job-Ansicht überlappt beim Scrollen keine Überschriften oder Karten mehr. Geöffnete Job- und Wiederherstellungstest-Karten werden bei Bedarf automatisch in den sichtbaren Bereich gescrollt. Hintergrundaktualisierungen verschieben die Seite nicht. Benachrichtigungen aktualisiert: Apprise wurde auf 2.1.0 aktualisiert und unterstützt jetzt 158 Basisanbieter. Zeitlimits werden auch bei Hintergrundversand und Profiltests berücksichtigt. Sicherheitsupdates: Die mitgelieferten Bibliotheken certifi, OAuthlib und urllib3 wurden aktualisiert, um gemeldete Sicherheitsprobleme der Abhängigkeiten zu beheben. Hinweise zum Update: Bestehende Benachrichtigungsprofile und Zugangsdaten bleiben erhalten. Amazon Chime wird nicht mehr unterstützt; betroffene Profile zeigen einen Hinweis und müssen auf einen anderen Anbieter umgestellt werden. URL-Optionen werden strenger geprüft, und ältere PGP-E-Mail-Optionen haben sich geändert. Gespeicherte URLs und Zugangsdaten werden nicht automatisch umgeschrieben. Ein Benachrichtigungs-Timeout zählt als fehlgeschlagener Versuch. Bereits laufende Anfragen können trotzdem noch zugestellt werden; Wiederholungen können daher doppelte Nachrichten verursachen. Eine eigene Docker-Reihenfolge ersetzt für die aufgeführten Container die bisherigen backup.start.priority-Gruppen einschließlich ihrer Pausen. Auf die Anwendungsbereitschaft wird nicht gewartet. Ohne eigene Reihenfolge bleibt das bisherige Verhalten erhalten.

Borg Backup UI 2026.10.30.1734 – Main Features and Changes This release improves repository views, database backup setup, and feedback when saving profiles. Clearer repository views: Compact layouts maintain a consistent height when switching tabs. Management and maintenance use the available space more effectively, with clearly separated sections and aligned buttons. Long execution details scroll within their result area. Improved archive navigation: The number of visible archives adapts to the available space. Page information and navigation buttons appear above and below the list. Archive names stay on a single line. Clearer statistics: The overview now includes the file count of the latest archive. The “Refresh statistics” button and its timestamp are positioned alongside the figures. Easier database backup setup: Dump directories work with normal Unraid permissions. Missing subdirectories are created automatically when the first dump runs. Invalid input is explained directly beside the affected field. Live test-dump progress: The current database, phase, elapsed time, and exported/compressed data sizes show what is happening—even with large databases. More reliable save feedback: Database, Local, USB, SMB, and SSH profiles clearly indicate whether changes are pending, saved, or could not be saved. Navigation and repository-link fixes: “Open jobs” respects the selected location. After deleting a job, its repository link and the corresponding deletion restriction refresh automatically. A special thanks to @bastl for his detailed feedback and practical examples! His suggestions helped make the interface clearer, more consistent, and easier to use.

Borg Backup UI 2026.10.30.1734 – wichtigste Neuerungen und Änderungen Diese Version verbessert vor allem die Repository-Ansichten, die Einrichtung von Datenbank-Sicherungen und die Rückmeldungen beim Speichern. Übersichtlichere Repositories: Kompakte Ansichten mit stabiler Höhe beim Reiterwechsel. Verwaltung und Wartung nutzen den verfügbaren Platz besser, mit klar getrennten Bereichen und ausgerichteten Buttons. Lange Ausführungsdetails lassen sich innerhalb ihres Ergebnisbereichs scrollen. Verbesserte Archivliste: Die Anzahl sichtbarer Archive passt sich dem verfügbaren Platz an. Seitenanzeige und Blätterbuttons stehen oberhalb und unterhalb der Liste. Archivnamen bleiben einzeilig. Klarere Statistiken: Die Übersicht zeigt zusätzlich die Dateianzahl des neuesten Archivs. „Statistik aktualisieren“ und der zugehörige Zeitstempel sind eindeutiger angeordnet. Einfachere Datenbank-Sicherungen: Dump-Verzeichnisse funktionieren mit normalen Unraid-Berechtigungen. Fehlende Unterverzeichnisse werden beim ersten Dump automatisch angelegt. Ungültige Eingaben werden direkt am betroffenen Feld erklärt. Live-Fortschritt bei Test-Dumps: Aktuelle Datenbank, Phase, Laufzeit und exportierte beziehungsweise komprimierte Datenmenge zeigen auch bei großen Datenbanken, was gerade passiert. Zuverlässigere Speicherrückmeldungen: Datenbank-, Lokal-, USB-, SMB- und SSH-Profile zeigen klarer, ob Änderungen offen, gespeichert oder fehlgeschlagen sind. Korrigierte Navigation und Verknüpfungen: „Jobs öffnen“ berücksichtigt den gewählten Standort. Nach dem Löschen eines Jobs aktualisieren sich dessen Repository-Verknüpfung und die Löschsperre automatisch. Ein besonderer Dank geht an @bastl für sein ausführliches Feedback und die konkreten Beispiele aus der Praxis! Seine Hinweise haben geholfen, die Bedienung verständlicher und übersichtlicher zu machen.

Hallo Bastl, danke für das ausführliche Feedback. Ich schaue mir diese Punkte in Ruhe an. Leider ist es für mich teilweise schwierig wie Ihr es seht ich sitze vor einem 34 Zoll Monitor und da kann es schon machmal anders aussehen. Ich bin auch kein UI/UX Entwickler ich versuche mein bestes mit der GUI. Zum letzten Punkt kann ich schon sagen das das ein Fehler ist den ich korriegieren werden. VG Thorsten

Borg Backup UI 2026.10.30.0912 Changes since 2026.10.27.2031 This update focuses on a clearer interface, expanded live metrics, and more traceable backup logs. New Features and Improvements Redesigned job view: Compact cards clearly separate status, scheduling, and restore-test information. Expandable details show workflow results and settings. Current action, step duration, and total runtime are displayed separately. Expanded live metrics: Progress appears immediately when Borg starts. Processing speed, approximate source size, progress, and estimated remaining time appear below the progress bar. Source-size measurement runs automatically, including for locally mounted USB, SMB, and SSH sources. Percentage and remaining time refer to archive creation. Traceable Borg commands: Backup logs now record the actual commands and their exit codes, linked by a unique invocation ID. Credentials are masked. Manual repository maintenance and existing support exports also include this evidence. Redesigned repository view: Clear repository cards show linked jobs, archive management, and maintenance results. Deleted archives and space reclaimed by Compact are easier to review. Improved restore wizard: Four clearly defined steps, persistent navigation and action buttons, and a searchable job selector. Restore tests, history, and reports: More consistent layouts, directly expandable test reports, and better use of screen space. Selections and scroll positions remain intact during automatic refreshes. Important Bug Fixes Unmounted backup sources are reliably detected: If an Unassigned Devices source under /mnt/disks or /mnt/remotes is not mounted, the entire job is skipped—even when an empty mount directory remains. Validation runs after Pre scripts and before database exports, service shutdowns, and Borg operations. More accurate System Health reporting: Temporarily unmounted sources appear as availability warnings. Missing paths on mounted sources remain errors. Smaller interface fixes: Removed the duplicate running-job display from the dashboard and corrected spacing in the job-group view. VG Thorsten

Borg Backup UI 2026.10.30.0912 Änderungen gegenüber 2026.10.27.2031 Der Schwerpunkt dieses Updates liegt auf einer übersichtlicheren Oberfläche, erweiterten Live-Messwerten und besser nachvollziehbaren Backup-Logs. Neue Features und Verbesserungen Überarbeitete Job-Ansicht: Kompakte Karten mit klar getrennten Angaben zu Status, Zeitplanung und Restore-Tests. Aufklappbare Details zeigen Ablauf, Ergebnisse und Einstellungen. Aktuelle Aktion, Schrittzeit und Gesamtlaufzeit sind getrennt sichtbar. Erweiterte Live-Messwerte: Fortschrittsanzeige direkt beim Borg-Start. Verarbeitungsgeschwindigkeit, ungefähre Quellgröße, Fortschritt und geschätzte Restzeit erscheinen unter dem Balken. Die Größenmessung läuft automatisch, auch für lokal eingehängte USB-, SMB- und SSH-Quellen. Prozent und Restzeit beziehen sich auf die Archiverstellung. Nachvollziehbare Borg-Aufrufe: Backup-Logs enthalten die tatsächlich ausgeführten Befehle und zugehörigen Exit-Codes mit eindeutiger Aufruf-ID. Zugangsdaten werden maskiert. Auch manuelle Repository-Wartung und vorhandene Support-Exporte enthalten diese Nachweise. Neue Repository-Ansicht: Übersichtliche Karten mit verknüpften Jobs, Archivverwaltung und Wartungsergebnissen. Gelöschte Archive und der von Compact freigegebene Speicherplatz sind besser nachvollziehbar. Verbesserter Restore-Assistent: Vier klar erkennbare Schritte, durchgehend erreichbare Navigations- und Aktionsschaltflächen sowie eine durchsuchbare Job-Auswahl. Restore-Tests, Historie und Reports: Einheitlichere Darstellung, direkt aufklappbare Testberichte und weniger Platzverbrauch. Auswahl und Scrollposition bleiben bei automatischen Aktualisierungen erhalten. Wichtige Bugfixes Nicht eingehängte Backup-Quellen werden zuverlässig erkannt: Fehlt ein Unassigned-Devices-Mount unter /mnt/disks oder /mnt/remotes, wird der gesamte Job übersprungen. Das gilt auch bei zurückgebliebenen leeren Mount-Verzeichnissen. Die Prüfung erfolgt nach Pre-Skripten und vor Datenbankexporten, Dienststopps und Borg. Systemzustand bewertet Quellen genauer: Vorübergehend ausgehängte Quellen erscheinen als Verfügbarkeitswarnung. Fehlende Pfade auf eingehängten Quellen bleiben Fehler. Kleinere Oberflächenkorrekturen: Doppelte Anzeige laufender Jobs im Dashboard entfernt und Abstände in der Jobgruppen-Ansicht korrigiert. VG Thorsten

Hallo zusammen, aufgrund der Diskussion zum unterschiedlichen Speicherverbrauch von Borg Backup UI und Borg UI habe ich beide Anwendungen einem direkten Praxistest unterzogen. Dabei habe ich die tatsächlich ausgeführten Borg-Befehle (create, prune, compact), die Standardparameter und die Repository-Größen miteinander verglichen. Ergebnis: Nach jeweils zwei Archiven beträgt die Abweichung beim Speicherverbrauch lediglich 0,0095 %. Ein interessanter Unterschied ist der jobbezogene Archivpräfix von Borg Backup UI. Dieser schützt andere Sicherungsreihen bei der Bereinigung eines gemeinsam genutzten Repositories. Auch das mehrstufige Locking habe ich genauer untersucht. Da die vollständige technische Gegenüberstellung den Umfang eines Forumsbeitrags sprengen würde, habe ich meine Ergebnisse in einem PDF zusammengefasst und hier angehängt. Der ursprüngliche Größenunterschied nach einer Woche ist damit noch nicht abschließend geklärt. Die bisherigen Messergebnisse zeigen aber keinen grundsätzlichen Mehrverbrauch durch Borg Backup UI. Borg_Vergleich_2026.pdf Viele Grüße Thorsten

Neben jeden Job ist das > Zeichen wenn man darauf Klick erschein zwei Reiter mit weiteren Informationen

Sieht das so besser aus ?

Borg Backup UI – New Dashboard and Updated Status Views Hi everyone, this update focuses on making things easier to follow. Three key areas have received a refreshed design: New Dashboard Backup results, restore coverage, active runs, and server resources are now displayed side by side in a compact layout. Along with the charts and location overview, the standard view fits on large desktop screens without scrolling. Alerts and additional information can be expanded when needed. Clearer Job Status The current job run and the last saved result are now more clearly separated. Previous results remain accessible through the status details. New Design for Restore Tests Test planning and results now have a more compact, organized layout. Locations, test plans, and reports are easier to navigate. The distinction between the latest test attempt and still-valid restore verification is also clearer. The updated views continue to support German and English, as well as light and dark themes. Enjoy trying it out — feedback on clarity and usability is always welcome!

Borg Backup UI – Neues Dashboard und überarbeitete Statusansichten Hallo zusammen, bei diesem Update steht die Übersichtlichkeit im Mittelpunkt. Drei zentrale Bereiche haben ein überarbeitetes Design erhalten: Neues Dashboard Backup-Ergebnisse, Restore-Abdeckung, aktive Läufe und Server-Auslastung stehen jetzt kompakt nebeneinander. Zusammen mit den Diagrammen und der Standortübersicht passt die normale Ansicht auf großen Desktop-Bildschirmen ohne Scrollen. Hinweise und weiterführende Informationen lassen sich bei Bedarf aufklappen. Übersichtlicherer Jobstatus Der aktuelle Joblauf und das letzte gespeicherte Ergebnis sind klarer getrennt. Die bisherigen Ergebnisse bleiben über die Statusdetails erreichbar. Neues Design für Restore Tests Testplanung und Ergebnisse sind kompakter und übersichtlicher aufgebaut. Standorte, Testpläne und Berichte lassen sich leichter zuordnen. Außerdem wird deutlicher zwischen dem letzten Testversuch und einem weiterhin gültigen Wiederherstellungsnachweis unterschieden. Die überarbeiteten Ansichten unterstützen weiterhin Deutsch und Englisch, helles und dunkles Design Viel Spaß beim Ausprobieren – Rückmeldungen zur Übersichtlichkeit und Bedienung sind willkommen!

Nein das fehlt noch das kommt auch noch rein. Dann würde ich es so machen das beim roten Button statt "Läuft" -> "Abbrechen" steht und diese Funktion übernimmt das der Job läuft steht ja links... Okay?

So ist es bereits in der Test Version enthalten.

Ist im Issue #605 erfasst und wird umgesetzt

Aktuell noch ne Testversion aber vielleicht ist ja solch eine Ansicht noch nützlich. Hier mit Prozesseinformationen und Verlauf Hier in der der normalen mit ausgeblendeten Verlauf.

Hallo Dirk, den Unterschied würde ich mir gerne genauer anschauen. Mit „ähnlichen, vergleichbaren Einstellungen“ lässt sich die Ursache allerdings noch nicht eingrenzen. Dafür bräuchte ich die konkreten Einstellungen und möglichst die tatsächlich ausgeführten Borg-Befehle beider Anwendungen. Borg Backup UI übergibt die konfigurierten Optionen an Borg. Die eigentliche Sicherung einschließlich Deduplizierung und Kompression übernimmt Borg selbst. Deshalb sollten wir folgende Punkte gegenüberstellen: Versionen: Welche Versionen der beiden Anwendungen und welche Borg-Version werden jeweils eingesetzt? Werden beide Repositories mit Borg 1.x betrieben oder eines mit Borg 2? Create: Sind Quellen, Ausschlüsse, Kompression einschließlich Kompressionsstufe und gegebenenfalls zusätzliche Optionen identisch? Prune: Welche Aufbewahrungsregeln und Archivfilter sind eingestellt? Wie viele Archive sind tatsächlich noch vorhanden? Compact: Wann wird Compact ausgeführt, mit welchen Optionen und wurde es jeweils erfolgreich abgeschlossen? Ausgangslage: Waren beide Repositories zu Beginn leer und wurden im Vergleichszeitraum gleich viele Backups erstellt? Größenangabe: Sind die Werte die tatsächlich belegten USB-Platten, die Repository-Verzeichnisse oder Größenanzeigen innerhalb der jeweiligen Anwendung? Wichtig ist dabei: Prune allein gibt den Speicherplatz auf der Platte noch nicht frei. Dafür muss anschließend Compact laufen. Datenblöcke, die noch von aufbewahrten Archiven benötigt werden, bleiben selbstverständlich erhalten. Kannst du die Einstellungen sowie ein vollständiges Backup-Log inklusive Prune und Compact aus beiden Anwendungen bereitstellen? Zugangsdaten und andere sensible Angaben bitte vorher entfernen. Damit können wir nachvollziehen, woher der Unterschied kommt. Sollte Borg Backup UI Einstellungen nicht korrekt übernehmen oder die Wartung nicht wie vorgesehen ausführen, möchte ich das natürlich ebenfalls finden und beheben. Viele Grüße Thorsten

Servus! Mit Version 2026.10.26.1618 haben wir die Restore-Tests überarbeitet: Große Dateilisten werden jetzt zeilenweise verarbeitet, statt komplett im RAM gehalten. Der Prüfumfang bleibt gleich. Es gibt ein RAM-Limit für den Test einschließlich Borg und eine überwachte Speicherreserve für den Host. Frühere Prüfberichte bleiben nach einem erneuten Test erhalten. Ein Unraid-spezifisches Problem beim abschließenden Auslesen der Speicherzähler wurde behoben. Meine Appdata-Sicherung mit rund 500.000 Dateien aus 31 Containern läuft erfolgreich durch. Dein Archiv mit etwa 1,9 Millionen Dateien ist daher der nächste wichtige Praxistest. Bitte einmal so testen: Plugin aktualisieren und Version 2026.10.26.1618 kontrollieren. Unter Einstellungen → Restore → Restore-Tests zunächst 2048 MiB RAM-Limit und 1024 MiB Hostreserve verwenden. Dafür müssen vor dem Start mindestens 3 GiB RAM verfügbar sein. Zuerst einen kleinen L2-Test durchführen, anschließend den problematischen Appdata-Test mit den bisherigen L2-Einstellungen. Zunächst keine weiteren Restore-Tests parallel starten. RAM-Auslastung und Erreichbarkeit der VMs währenddessen beobachten. Bei Erfolg sollten am Ende diese Zeilen erscheinen: Final memory counters: oom=0, oom_kill=0 Summary: 1 OK | 0 failed | 0 unavailable | 0 skippedFalls RT_MEMORY_LIMIT erscheint, bitte zunächst das Limit unverändert lassen und das Log schicken. Das bedeutet, dass das Speicherbudget erreicht wurde, und weist allein nicht auf ein beschädigtes Backup hin. Bitte anschließend das vollständige Laufprotokoll, die höchste beobachtete RAM-Auslastung und eine kurze Rückmeldung zu den VMs und Diensten senden. VG Thorsten

Ja. Der Log bestätigt einen echten RAM-Engpass, und der Restore-Test-Code enthält eine dazu passende Schwachstelle. Eine einstellbare RAM-Begrenzung gibt es derzeit nicht. Am 26.10. um 00:29:46 hat der Linux-OOM-Killer die VM MintL beendet. Der Python-Prozess des Restore-Tests belegte dabei etwa 3,56 GiB RAM. Ein weiterer, anhand des Auszugs nicht zuordenbarer Python-Prozess belegte rund 5,28 GiB. Swap war nicht vorhanden. Besonders aufschlussreich ist der Zeitpunkt: Erst um 00:30:04, also nach dem VM-Abschuss, beginnt laut Protokoll der vollständige Extract-Dry-Run. Der Speicherengpass entstand somit bereits während der Vorbereitung der Dateiliste. Im [Restore-Test-Code (line 811)](/home/tsteinbe/git/borg-backup-ui/runtime/scripts/borg_restore_test.py:811) passiert Folgendes: Die komplette Ausgabe von borg list --json-lines wird im RAM gesammelt. splitlines() erzeugt zusätzliche Zeichenketten für sämtliche Einträge. Zusätzlich werden alle regulären Dateipfade in einer Liste gespeichert. Erst danach greifen Stichprobenauswahl und Dateilimits. Bei 1,9 Millionen Dateien ist das ein plausibler erheblicher Speicherverbrauch des Plugins selbst. Kleinere Stichproben oder ein niedrigerer Schwellwert für den vollständigen Dry-Run beheben diesen Vorbereitungsschritt nicht. Zu den verschwundenen Berichten: Du hast keine Verlaufsoption übersehen. Der strukturierte Prüfbericht wird pro Job überschrieben. Die separaten Textprotokolle sollten dagegen noch unter /mnt/user/borg-backup-ui/logs/ als Borg-Restore-Test--<Zeitstempel>-<PID>.log liegen. Allgemeine Ablaufmeldungen gehen in /var/log/borg_backup_ui.log, nicht in den Unraid-Syslog. Den vermuteten Timeout des vorherigen geplanten Laufs kann ich ohne dessen Protokoll nicht bestätigen. Bis zur Behebung würde ich den automatischen L2-Test für appdata vorübergehend deaktivieren. L1 vermeidet die hier problematische vollständige Dateiauflistung, bietet allerdings keine Prüfung der Nutzdaten und keine garantierte RAM-Obergrenze. Nur den Timeout zu verkürzen ist kein verlässlicher Speicherschutz. Ich habe die Befunde als Issue #599 erfasst. Die notwendigen Maßnahmen sind: Dateilisten streamen und nur eine begrenzte Stichprobe speichern. Ein durchgesetztes Speicherbudget für Testprozess und Borg-Unterprozesse vorsehen. Abbrüche eindeutig melden und Prüfberichte samt Logverweisen pro Lauf erhalten. VG Thorsten

Hi everyone, I’d like to share an overview of what’s planned for Borg Backup UI. In particular, the Python dependency and the announced changes in Unraid 8 are already part of the project’s planning. You can follow these topics on GitHub: Python dependency – Issue #548 Unraid 8 and future architecture – Issue #549 There is already a concrete plan for Python: Borg Backup UI should become independent of the existing Python plugin no later than its announced end of support on November 30, 2026. To achieve this, Borg Backup UI will provide its own isolated Python runtime when needed. This runtime will be used exclusively by Borg Backup UI and will not replace any system-wide Python installation. An existing compatible Python version should still be usable. This should allow continued use on Unraid 7.x without relying on the existing Python plugin. For Unraid 8, some questions remain open. According to the announcements so far, the new platform will be based on Fedora and include Python. A new plugin system with an SDK and permission management has also been announced. What this means for Borg Backup UI will become clearer once sufficient documentation and testable versions are available. I’ll follow these developments and assess how Borg Backup UI can adapt to the new system. I will continue to support and maintain Unraid 7.x. Alongside this, I’m considering a possible standalone container version. There are currently two approaches under consideration: A container with extensive host privileges: This would make many existing features relatively straightforward to implement. However, those broad permissions would be a significant security drawback. A restricted container with a host agent: The application would run inside the container, while a separate service on the host would handle tasks requiring access to Docker, virtual machines, disks, or other system functions. This could provide a clearer separation of permissions, but would be more complex to implement and maintain. No decision has been made yet. Continuing development as an Unraid plugin remains an option. Supporting other platforms, such as TrueNAS, Synology, or conventional Linux systems, is a long-term possibility, but not a commitment at this stage. Whatever the eventual technical approach, my goal is to make the transition as straightforward as possible for you. Existing configurations, backup jobs, and repositories should be preserved. If changes or migrations become necessary, they should be clearly documented and automated wherever practical. BorgBackup 2.x is also on the roadmap. Once a stable version is available, I intend to add support in Borg Backup UI. Any migration requirements and their effects on existing backups will need to be assessed beforehand. Development of Borg Backup UI will continue. Some plans are already concrete, while others are still being evaluated. I’ll keep you informed about important decisions and available test versions. I also welcome your ideas, feature requests, and constructive criticism. Which features are you missing? Where do you run into difficulties? What could be simpler or easier to understand? Feel free to share your thoughts here in the forum or directly on GitHub. Not every request can be implemented immediately, but your feedback helps me shape the next steps around your actual needs. Best regards, Thorsten

Hallo Bastl, ja, beide Themen – Python und Unraid 8 – habe ich bereits auf dem Schirm und sie sind auch in die Projektplanung von Borg Backup UI eingeflossen. Dazu gibt es bereits zwei GitHub-Issues: Python-Abhängigkeit: Issue #548 Unraid 8 und zukünftige Architektur: Issue #549 Zum Thema Python: Hier gibt es bereits einen konkreten Plan. Borg Backup UI soll spätestens mit dem Wegfall der Unterstützung für das bisherige Python-Plugin am 30.11.2026 unabhängig davon funktionieren. Dafür wird Borg Backup UI bei Bedarf eine eigene, isolierte Python-Laufzeitumgebung mitbringen. Diese dient ausschließlich der Ausführung von Borg Backup UI und wird nicht systemweit installiert. Ist bereits eine kompatible Python-Version vorhanden, kann diese weiterhin verwendet werden. Damit sollte die weitere Nutzung unter Unraid 7.x unabhängig vom bisherigen Python-Plugin möglich sein. Bei Unraid 8 sieht es diesbezüglich ohnehin etwas anders aus, da Python laut den bisherigen Ankündigungen bereits Bestandteil der neuen Fedora-basierten Plattform sein soll. Zum Thema Unraid 8: Hier sind leider noch einige Fragen offen. Nach den aktuellen Informationen wird die öffentliche Beta für Anfang 2027 angestrebt. Ein konkreter Termin für die finale Version steht noch nicht fest. Unraid arbeitet an einem neuen Plugin-System mit einem eigenen SDK und einer Rechteverwaltung. Bestehende Plugins müssen dafür angepasst werden. Gleichzeitig wurde angekündigt, dass man die Community-Entwickler bei dieser Umstellung unterstützen möchte. Welche Möglichkeiten sich daraus konkret für Borg Backup UI ergeben, muss sich allerdings erst noch zeigen. Parallel dazu beschäftige ich mich auch mit der Frage, ob langfristig eine eigenständige Container-Version sinnvoll wäre. Hier gibt es momentan zwei Überlegungen: 1. Ein Container mit erweiterten Host-Rechten (privileged) Damit ließen sich viele der bestehenden Funktionen vergleichsweise einfach umsetzen, da Borg Backup UI für verschiedene Aufgaben tiefen Zugriff auf das Host-System benötigt, beispielsweise für Docker, virtuelle Maschinen, Datenträger und Backup-/Restore-Prozesse. Allerdings hätte ein solcher Container sehr weitreichende Berechtigungen, was aus Sicherheitsgründen natürlich nicht unbedingt die schönste Lösung ist. 2. Ein normaler Container mit einem Host-Agenten Hier würde die eigentliche Anwendung in einem möglichst eingeschränkten Container laufen. Ein separater Agent auf dem Host würde die notwendigen systemnahen Aufgaben übernehmen. Das wäre hinsichtlich der Trennung von Anwendung und Host eine interessante Alternative, bringt aber ebenfalls Herausforderungen mit sich. Insbesondere dann, wenn Borg Backup UI irgendwann nicht mehr ausschließlich für Unraid, sondern möglicherweise auch für andere Plattformen wie TrueNAS, Synology oder klassische Linux-Systeme angeboten werden soll. Welche Variante am Ende die sinnvollste ist, habe ich noch nicht entschieden. Auch eine Anpassung des bestehenden Plugins an das neue Unraid-8-System bleibt selbstverständlich eine Option. Was ich aber schon sagen kann: Borg Backup UI wird auf jeden Fall weiterentwickelt. Mein Ziel ist es, den Übergang für euch als Anwender so einfach wie möglich zu gestalten – idealerweise ohne eine komplette Neueinrichtung und natürlich unter Beibehaltung eurer bestehenden Konfigurationen, Backup-Jobs und Repositories. Auch Unraid 7.x werde ich weiterhin unterstützen und pflegen, unabhängig davon, wann Unraid 8 erscheint. Eine weitere Sache steht ebenfalls auf der Roadmap: Sobald BorgBackup 2.x als stabile Version verfügbar ist, soll auch diese von Borg Backup UI unterstützt werden. Es stehen also noch einige interessante Entwicklungen bevor. 🙂 Und noch etwas ist mir wichtig: Borg Backup UI lebt natürlich auch von euch und eurem Feedback. Deshalb freue ich mich jederzeit über Wünsche, Ideen, Verbesserungsvorschläge und natürlich auch konstruktive Kritik. Nur durch eure Rückmeldungen kann ich erkennen, welche Funktionen euch vielleicht noch fehlen, wo es im Alltag Schwierigkeiten gibt oder was sich einfacher und besser gestalten lässt. Bringt euch also gerne ein, egal ob hier im Forum oder direkt über GitHub. Nicht jeder Wunsch lässt sich sofort umsetzen, aber jede Anregung hilft mir dabei, Borg Backup UI weiterzuentwickeln und noch besser an euren tatsächlichen Bedürfnissen auszurichten. Schließlich entwickle ich Borg Backup UI nicht nur für mich, sondern vor allem auch für euch. 🙂 Viele Grüße Thorsten

Borg Backup UI – Update 2026.10.24.1534 Bug Fixes Datenbankexporte werden während der Jobausführung mit Laufzeit und Ergebnis angezeigt. (#591) Prüfung der Dump-Verzeichnisrechte für übliche Unraid-Pools korrigiert. (#591) Verbliebene Browserdialoge durch Anwendungsdialoge ersetzt und Darstellung der Skriptbereiche vereinheitlicht. (#591, #593) Erweiterungen Online-Datenbanksicherungen für MariaDB/MySQL mit InnoDB und PostgreSQL in Docker – mit Profilen, Datenbankauswahl, geschützten Secrets und komprimierten Dumps. (#591, #593) Überarbeitete Skriptverwaltung mit klarer Trennung zwischen eigenen Skripten, Vorlagen und verwalteten Datenbankhelfern sowie Beschreibungen und Syntaxhervorhebung. (#591) Verbesserte Dashboard-Übersicht für Sicherungsergebnisse, Restore-Nachweise und Jobs mit Handlungsbedarf. (#589) Einzeilige Jobschritte, verständliche Sicherungsnamen und übersichtlichere Auswahl von Verzeichnissen und Datenbankprofilen. (#591) Automatische Bereinigung abgeschlossener interner Vorgangsdaten nach 30 Tagen. Sicherungen und ungeklärte Vorgänge bleiben erhalten. (#593)

Borg Backup UI – Update 2026.10.24.1534 Bug Fixes Database exports now show their duration and outcome during job execution. (#591) Fixed dump-directory permission checks for typical Unraid pools. (#591) Replaced remaining browser dialogs with application dialogs and unified the appearance of script sections. (#591, #593) Improvements Online database backups for MariaDB/MySQL with InnoDB and PostgreSQL in Docker, including profiles, database selection, protected Secrets and compressed dumps. (#591, #593) Redesigned script management with clear separation between custom scripts, templates and managed database helpers, including descriptions and syntax highlighting. (#591) Improved dashboard overview of backup results, restore evidence and jobs requiring attention. (#589) Single-row job steps, readable backup names and clearer directory and database-profile selection. (#591) Automatic cleanup of completed internal operation records after 30 days. Backups and unresolved operations are retained. (#593)