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 Monday at 03:04 PM4 days 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 12 hours ago12 hr by Thorsten