8 minutes ago, dibux said:

Was mir ausfällt.

Identische Backups (ähnliche, vergleichbare Einstellungen und identische Laufzeit (vergleichbar, kaum veränderte Daten im Backup): jedes Programm backupt auf einer eigenen 1TB usb Festplatte

Borg Backup UI: 1TB voll nach einer Woche (bis Anschlag) - wurde nie kleiner

Borg-UI: 496GB nach einer Woche - bleibt ziemlich stabil

Frage mich warum ;-)

BG Dirk

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

7 hours ago, bastl said:

Servus.

Ich denke ein normaler Container mit einem zusätzlichen Agenten für den Host macht am meisten Sinn. Wer quasi nur Verzeichnisse sichern möchte ist mit dem "normalen" Container gut bedient, egal auf welchem System der dann läuft. Wenn man dann noch Zugriff zum Host benötigt ist die Idee mit nem Host-Agent eigentlich ganz clever. Je nach Host System einfach den passenden Agent installiert. Problem ist nur, dass man dann auch mehrere Agents pflegen muß. Einer für Unraid, einer für TrueNAS, Proxmox etc.

Bisher lief es bei mir eigentlich ohne Probleme, bis vor 2 Wochen einer der Restore Tests nicht abgeschlossen wurde. Ich hatte mir das angeschaut und gemerkt, dass wenn der Test läuft, mein System dann den RAM komplett zu haut, was dazu geführt hat, dass eine von 2 VMs die immer läuft gekillt wurde und der Test abbrach. Ich hab der VM dann vorsorglich 2GB RAM entzogen, von 8 auf 6 und der Test lief dann manuell gestartet durch. Letzte Woche lief der Test ebenso ohne Probleme automatisch, nur gestern leider wieder nicht. Gleiche Symptome, Borg vermeldet, dass der Test abgebrochen wurde.

Schau ich mir dann den Prüfbericht an, scheint es bei Metadaten-Check nen Timeout gegeben zu haben. Repo erreichbar und Archiv lesbar beides grün, danach Feierabend. Ich hab leider keinen Screenshot gemacht und finde nachdem ich den Lauf nochmal von Hand gestartet hab, keine Infos/Logs zu dem abgebrochenen Durchlauf mehr. Entweder bin ich blind oder es gibt keine Option dazu. Ich hab hier aber noch nen Auszug aus dem Unraid Log (siehe Anhang) selbst falls das weiter helfen könnte. Eine Anmerkung hierzu, der eigentliche Durchlauf der geplant war, bzw. keiner der geplanten Durchläufe hat etwas in den Unraid Logs hinterlassen, weder den Start, noch Warnungen oder Meldungen auch das killen der VM ist nicht aufgeführt.

19:30 läuft nen Trim Durchlauf vom Cache etwa 5 Min. Danach passiert nix weiter auf dem Server. 20Uhr sind die Tests geplant und auch diese sieht man in den Unraid Logs nicht. Ursprünglich hab ich alle 5 auf die gleiche Zeit gelegt, vor 3 Wochen nach dem ersten Absturz der VM dann den betreffenden Test vom "appdata" Repo auf um 22Uhr nach hinten geschoben. Die anderen 4 Tests liefen immer ohne Probleme, nur der appdata Test verursacht Probleme. Kurz vor halb 1 hab ich den Test dann von Hand angestoßen mit laufender VM und kurz darauf schießt es mir wieder die VM ab. Der Testlauf läuft aber erfolgreich durch.

Hier noch ein paar Anmerkungen zum Setup:

Im Idle läuft der Server mit 70-80% RAM usage, wobei an dem Punkt 5-6GB von 32 gesamt noch frei sind. Während des Tests und auch während der anderen Repo Tests läuft der RAM hoch bis auf 92-93% zumindest sieht man das in der Unraid UI so.

Nur bei dem "appdata" Repo gibt es aber das Problem. Während der Laufzeit des Tests sowohl geplant als auch danach manuel gestartet läuft auf dem Server nichts weiter aktiv. Docker wie Nextcloud und Jellyfin sind zwar aktiv, haben zu der Zeit aber keine Nutzer und auch keine Management Jobs laufen. Die betroffene VM ist auch im Idle.

Info zum Repo:

gesichert wird ein Verzeichnis in dem sich mehrere rsync Sicherungen vom Appdata Verzeichnis befinden. Etwa 180K Dateien befinden sich in einer Rsync Sicherung ca. 32GB. Suma sumarum sollen etwa 1,8mio Dateien gesichert werden. Ich weis, nicht gerade wenig und dauert auch über ne Stunde, aber im Prinzip egal. Sicherung läuft ja auch problemlos. Die Backups laufen auch eigentlich mit Standard Settings bis auf die Komprimierung. Diese steht bei allen auf zstd 6 statt 4. Die Restore Test settings stehen ebenfalls auf den Default Werten. L2 bei allen Tests.

Folgendes hat mir der Manuelle Lauf gestern noch im Verlauf angezeigt:

[2026-10-26 00:24:34] ============================================================
[2026-10-26 00:24:34] Borg Restore Test v1.0.0
[2026-10-26 00:24:34] Level: 2 | Location: all | Force: True
[2026-10-26 00:24:34] Log: /mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-26_00-24-34-1027308.log
[2026-10-26 00:24:34] ============================================================
[2026-10-26 00:24:34] Repositories: 1

[2026-10-26 00:24:34] Restore-test policy: job=b6c9c136-255d-4887-a4b0-f3757b6c39ba; level=L2; schedule=0 22 * * 0; source=manual
[2026-10-26 00:24:34] ────────────────────────────────────────────────────────────
[2026-10-26 00:24:34] TEST: appdata (local)
[2026-10-26 00:24:34]   Repository: /mnt/remotes/DISKSTATION_UNRAID/BACKUPS_MINI/borg-backup-ui/borg-backup-appdata
[2026-10-26 00:24:34] Level 1: Repository integrity
[2026-10-26 00:24:35]   OK Level 1 - latest archive: appdata-backup-2026-10-25_09-15-04
[2026-10-26 00:24:45]   Size: 89.3 GB, files: 630030
[2026-10-26 00:24:45] Level 2: Extract Dry-Run
[2026-10-26 00:30:04]   Testing the complete archive (1921601 files)
[2026-10-26 01:21:10]   → Ergebnis: /mnt/user/borg-backup-ui/restore-status/b6c9c136-255d-4887-a4b0-f3757b6c39ba.test
[2026-10-26 01:21:11]   Unraid dashboard widget cache updated (restore test result written)
[2026-10-26 01:21:11] OK Restore test succeeded (3396s)

[2026-10-26 01:21:11] ============================================================
[2026-10-26 01:21:11] Summary: 1 OK | 0 failed | 0 unavailable | 0 skipped

Wie man sieht 1,9mio Files deckt sich also mit meiner groben Schätzung. Metadatencheck is in 10s durch und Restore-Probe dauerte etwa 56min. Docker und VMs werden durch Borg Backup UI nicht angetastet, nur das reine Dateiverzeichnisse wird gesichert auf ein gemounteten NFS Share zu einem Synology NAS.

Frage ist nun, wie kann ich verhindern, dass mir das Plugin irgendwelche VMs und Dienste abschießt? Kann ich irgendwo die Arbeitsspeichernutzung begrenzen? Sollte falls nicht vorhanden unbedingt auf die ToDo List, dass das Plugin sich nicht einfach gnadenlos nimmt bis nix mehr da is. 🤣

Danke schonmal

unraid-log-snippet.log

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.

3 hours ago, Thorsten said:

Bitte einmal so testen:

1. Plugin aktualisieren und Version 2026.10.26.1618 kontrollieren.

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

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

4. RAM-Auslastung und Erreichbarkeit der VMs währenddessen beobachten.

Bei Erfolg sollten am Ende diese Zeilen erscheinen:

Ich bin es komplett so durchgegangen. Plugin aktualisiert, Settings wie gewünscht (waren bereits voreingestellt), RAM des Servers vor Beginn bei ca. 65% Auslastung (9,59GiB free), VMs laufen, Test Job mit nur ca 10K Dateien manuel angestoßen, lief ohne Probleme. Speicherverbrauch steigt augenscheinlich kaum an nur um ein paar 100 MB auf 66%. Test erfolgreich in 13:53min im Vergleich zum letzten geplanten Lauf des Jobs vom Sonntag mit 10:38min für 11K Files.

Den kritischen "appdata" task dann wieder mit L2 Settings als geplant starten lassen. RAM wieder bei ca. 9,5GiB free vor Beginn, VMs laufend. Auch hier wie bei dem "kleinen" Test steigt der Speicherverbrauch nun kaum an. max 67% belegt und 9GiB free. VMs laufen ohne Probleme durch und auch der Test endet erfolgreich nach 1:42h bei diesmal "nur" knapp über 1,5mio Dateien. Letzter manuel gestarteter Lauf mit den 1,9mio lief in 56min durch.

Warum die 400K Files weniger kurz erklärt. Das Verzeichn was gesichert wird, beinhaltet mehrere Speicherstände die vorher mit Rsync dorthin geschrieben wurden. Das Rsync Script räumt auch alte Sicherungen auf. Task lief heut schon, daher der Unterschied zu den gestrigen 1,9mio.

hier noch das Log:

[2026-10-26 18:06:01] ============================================================
[2026-10-26 18:06:01] Borg Restore Test v1.0.0
[2026-10-26 18:06:01] Level: 2 | Location: all | Force: False
[2026-10-26 18:06:01] Log: /mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-26_18-06-01-3377862.log
[2026-10-26 18:06:01] ============================================================
[2026-10-26 18:06:01] Repositories: 1

[2026-10-26 18:06:01] Restore-test policy: job=b6c9c136-255d-4887-a4b0-f3757b6c39ba; level=L2; schedule=6 18 * * 1; source=schedule
[2026-10-26 18:06:02] Memory protection active: 2048 MiB for worker and Borg children; host reserve 1024 MiB; group retained until final counter check
[2026-10-26 18:06:02] ────────────────────────────────────────────────────────────
[2026-10-26 18:06:02] TEST: appdata (local)
[2026-10-26 18:06:02]   Repository: /mnt/remotes/DISKSTATION_UNRAID/BACKUPS_MINI/borg-backup-ui/borg-backup-appdata
[2026-10-26 18:06:02] Level 1: Repository integrity
[2026-10-26 18:06:28]   OK Level 1 - latest archive: appdata-backup-2026-10-26_09-15-04
[2026-10-26 18:07:09]   Size: 69.7 GB, files: 423813
[2026-10-26 18:07:09] Level 2: Extract Dry-Run
[2026-10-26 18:10:14]   Testing the complete archive (1569038 files)
[2026-10-26 19:48:20] OK Restore test succeeded (6137s)
[2026-10-26 19:48:20] Final memory counters: oom=0, oom_kill=0
[2026-10-26 19:48:20]   → Ergebnis: /mnt/user/borg-backup-ui/restore-status/b6c9c136-255d-4887-a4b0-f3757b6c39ba.test
[2026-10-26 19:48:20]   Unraid dashboard widget cache updated (restore test result written)

[2026-10-26 19:48:21] ============================================================
[2026-10-26 19:48:21] Summary: 1 OK | 0 failed | 0 unavailable | 0 skipped

Aktuell hab ich auf 6GB Limit hoch gestellt und teste nochmal.

Edited Monday at 07:55 PM2 days by bastl

Kleiner Verbesserungsvorschlag noch an dieser Stelle. Läuft ein Job wird dies auch unter Jobs angezeigt indem anstelle des "Jetzt starten" (in blau) Button rot dargestellt wird. Das könnte man auch bei den Restore Tests einführen. Man sieht nicht direkt gleich welcher Job läuft, wenn man die Sektion öffnet, sondern man bekommt nur in der Ecke eine Popup Warnung, dass en Job läuft. Welcher genau sieht man nicht, sondern man muß runter scrollen in das aktuelle Protokoll und findet dann erst in der 10 Zeile oder so den Namen des aktuellen Jobs

Edit:

Nachtrag zu dem zweiten Test mit 6GB Host Limit in den Settings. Der Job lief auch problemlos durch mit der neueren Plugin Version. Dateianzahl die gleiche, Test dauerte allerdings 2:08h. Auslastung vom RAM is auch nicht wirklich zu erkennen. Vor Beginn 66% belegt 9,4 frei, während des laufs um die 68% mit 8,6 frei. Server selbst scheint nicht wirklich nebenbei was zu tun gehabt zu haben. Nextcloud lief kurz nen Datenbank Job, was allerdings kaum Last erzeugt.

Edited Monday at 09:53 PM2 days by bastl

8 minutes ago, bastl said:

Kleiner Verbesserungsvorschlag noch an dieser Stelle. Läuft ein Job wird dies auch unter Jobs angezeigt indem anstelle des "Jetzt starten" (in blau) Button rot dargestellt wird. Das könnte man auch bei den Restore Tests einführen. Man sieht nicht direkt gleich welcher Job läuft, wenn man die Sektion öffnet, sondern man bekommt nur in der Ecke eine Popup Warnung, dass en Job läuft. Welcher genau sieht man nicht, sondern man muß runter scrollen in das aktuelle Protokoll und findet dann erst in der 10 Zeile oder so den Namen des aktuellen Jobs

Ist im Issue #605 erfasst und wird umgesetzt

@Thorsten Danke für den Vermerk. Hab gerade zeitgleich meinen letzten Post noch editiert wegens Ablauf des Tests. Nur als Info das es nicht untergeht.

9 minutes ago, bastl said:

@Thorsten Danke für den Vermerk. Hab gerade zeitgleich meinen letzten Post noch editiert wegens Ablauf des Tests. Nur als Info das es nicht untergeht.

So ist es bereits in der Test Version enthalten.

3 minutes ago, Thorsten said:

So ist es bereits in der Test Version enthalten.

Das geht ja rucki zucki hier 🤣

Jetzt fehlt noch nen Button zum Abbrechen des laufenden Jobs, oder geht das schon? Habs noch nicht darauf geachtet wenn ein Job läuft ob da irgendwo nen Button is.

Just now, bastl said:

Das geht ja rucki zucki hier 🤣

Jetzt fehlt noch nen Button zum Abbrechen des laufenden Jobs, oder geht das schon? Habs noch nicht darauf geachtet wenn ein Job läuft ob da irgendwo nen Button is.

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?

Edited Monday at 10:14 PM2 days by Thorsten

3 minutes ago, Thorsten said:

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?

Der Button farblich hervorgehoben als Indikator für nen laufenden Job und dann Abbrechen passt denke ich.

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!

Nabend,

Ich hatte gestern noch nen Uptime Kuma Screen vor mir und hab gedacht, so ein bisl in die Richtung könnte man die UI ja auch vorschlagen und so ein wenig geht es auch in die Richtung. Die Backupläufe über Zeit erinnern zumindest schonmal daran. Nettes Gimick auch, dass die Auslastung des Servers direkt mit im Dashboard zu sehen is.

An der Übersichtlichkeit der Job Seite müßte man aber unbedingt noch was machen. Wenn ich auf Details anzeigen klicke bei nem Job klappt etwas auf, was so schon zu sehen ist, nur als Liste und nicht nebeneinander. Irgendwie doppelt gemoppelt. Direkt die Standardansicht verschwendet auch jede Menge Platz. Da sind mehr Leerräume als Infos. Mir wird da, wenn alles eingeklappt is gerade mal knapp 2 von 5 Jobs angezeigt, Rest muß ich scrollen. "letzter Test", "gültig bis" und "nächster Lauf" würde ich in eine extra Spalte packen und die zeile mit create prune compact check was wie gesagt doppelt is, nur über Details anzeigen lassen und schon hast du die Höhe die ein Job belegt mehr als halbiert

Grüße

9 hours ago, bastl said:

Nabend,

Ich hatte gestern noch nen Uptime Kuma Screen vor mir und hab gedacht, so ein bisl in die Richtung könnte man die UI ja auch vorschlagen und so ein wenig geht es auch in die Richtung. Die Backupläufe über Zeit erinnern zumindest schonmal daran. Nettes Gimick auch, dass die Auslastung des Servers direkt mit im Dashboard zu sehen is.

An der Übersichtlichkeit der Job Seite müßte man aber unbedingt noch was machen. Wenn ich auf Details anzeigen klicke bei nem Job klappt etwas auf, was so schon zu sehen ist, nur als Liste und nicht nebeneinander. Irgendwie doppelt gemoppelt. Direkt die Standardansicht verschwendet auch jede Menge Platz. Da sind mehr Leerräume als Infos. Mir wird da, wenn alles eingeklappt is gerade mal knapp 2 von 5 Jobs angezeigt, Rest muß ich scrollen. "letzter Test", "gültig bis" und "nächster Lauf" würde ich in eine extra Spalte packen und die zeile mit create prune compact check was wie gesagt doppelt is, nur über Details anzeigen lassen und schon hast du die Höhe die ein Job belegt mehr als halbiert

Grüße

Sieht das so besser aus ?

Edited 23 hours ago23 hr by Thorsten

7 hours ago, Thorsten said:

Sieht das so besser aus ?

Ist auf jedenfall übersichtlicher. Man könnte sogar den ausgegrauten ABBRECHEN Button noch weg lassen. Da würde man in der Höhe noch etwas Platz sparen und könnte es noch ein wenig zusammen rücken. Details anzeigen hast du ganz raus geworfen oder klickt man einfach den Job irgendwo an und es zeigt sich dann die Infos über Prune Create etc. oder unter dem ... Button ?

1 minute ago, bastl said:

Ist auf jedenfall übersichtlicher. Man könnte sogar den ausgegrauten ABBRECHEN Button noch weg lassen. Da würde man in der Höhe noch etwas Platz sparen und könnte es noch ein wenig zusammen rücken. Details anzeigen hast du ganz raus geworfen oder klickt man einfach den Job irgendwo an und es zeigt sich dann die Infos über Prune Create etc. oder unter dem ... Button ?

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