Thorsten

Thanks for the detailed report. This definitely sounds like something I need to take a closer look at. Could you please create a Support Package in Borg Backup UI under Settings → Import / Export and send it to me via PM? Personal and sensitive information in the support package is automatically masked. The package is created as a ZIP file, so you can also open it and review the contents yourself before sending it to me. I think it's important that you can see exactly what information is being shared. That should give me the information I need to investigate why the storage target selection keeps jumping back to the first entry. Thanks for also testing it in multiple browsers — that already helps narrow things down. And I'm glad to hear that this is the only issue you've run into so far. Thanks a lot for the feedback and testing!

I have decided to keep the Unraid dashboard widget in English for now. The reason is that the widget is closer to a technical Unraid integration, similar to log output and plugin status information. To keep this area consistent and easier to maintain, the widget currently uses English labels only. The main Borg Backup UI application itself remains bilingual and supports both German and English. This may change in the future if there is enough demand or if a good approach for localized Unraid dashboard widgets becomes clear. New Version: 2026.08.14.1905

Good point — i actually missed that. I’m already working on it and it should be available tomorrow. Thanks for pointing it out!

Da hast du einen wichtigen Punkt angesprochen – und meine Formulierung mit den „geänderten Sektoren“ war tatsächlich technisch nicht ganz sauber. Borg arbeitet mit Content-Defined Chunking. Die Daten werden in Chunks zerlegt und anhand ihres Inhalts dedupliziert. Dabei ist es grundsätzlich egal, ob ein identischer Chunk aus derselben Datei, einer anderen Datei oder einem früheren Backup stammt. Identische Chunks müssen nicht erneut im Repository gespeichert werden. Bei deinem Beispiel mit den täglich neu erzeugten .tar.gz-Dateien gibt es allerdings einen entscheidenden Haken: die Kompression. Bereits kleine Änderungen an den ursprünglichen Daten können größere Bereiche des komprimierten Datenstroms verändern. Dadurch kann Borg deutlich weniger identische Chunks erkennen, obwohl die entpackten Daten vielleicht größtenteils identisch sind. Deshalb würde ich für diesen Anwendungsfall nicht erst mit Appdata Backup ein komprimiertes Archiv erzeugen und dieses anschließend mit Borg sichern. Sinnvoller ist es, Borg direkt auf die Appdata-Verzeichnisse loszulassen. Dann sieht Borg die eigentlichen Dateien und die Deduplizierung kann entsprechend greifen. Bei rsync gebe ich dir ebenfalls recht, wobei Borg und rsync für mich etwas unterschiedliche Aufgaben erfüllen. Borg bietet mir versionierte Backups, Deduplizierung, Integritätsprüfungen, Kompression und optional Verschlüsselung. rsync wiederum eignet sich sehr gut für eine zusätzliche 1:1-Kopie, auf deren Dateien ich ohne spezielles Restore-Tool direkt zugreifen kann. Und damit bin ich auch bei deinem Einwand, dass man für ein Borg-Repository Borg benötigt: Den finde ich absolut berechtigt. Ich würde weder Borg noch rsync allein automatisch als sichere Backup-Strategie betrachten. Eine Kombination kann meiner Meinung nach sogar sehr sinnvoll sein: beispielsweise Borg für die versionierten Backups und zusätzlich rsync für eine direkt lesbare Kopie wichtiger Daten – möglichst auf unterschiedlichen Systemen/Medien und idealerweise mit einer weiteren externen bzw. offline geschützten Kopie. Am Ende ist für mich also weniger die Frage „Borg oder rsync?“, sondern wie die gesamte Backup-Strategie aufgebaut ist. Ein einzelnes Tool ersetzt keine vernünftige 3-2-1-Strategie und vor allem keine regelmäßigen Restore-Tests.

Help us improve Borg Backup UI – Short Feedback SurveyHi everyone, Borg Backup UI has now been available in Community Apps for a few days, and I would like to collect some feedback from those of you who have already installed or tested it. The goal is to continuously improve the plugin, especially regarding: Installation and initial setup Creating your first repository and backup job UI clarity and usability Problems or errors Missing features Preferred communication channels for future feedback The survey is very short and should only take about 2 minutes. Feedback is also very welcome if everything worked without any problems. Knowing what already works well is just as valuable as knowing what needs improvement. 👉 Survey: https://forms.gle/EqVNi4jNRjDbdV259 Thank you very much for your support, feedback and for helping to improve Borg Backup UI! 🙂 Die Freitext Felder können auch gerne in Deutsch ausgefüllt werden :-)

Help us improve Borg Backup UI – Short Feedback SurveyHi everyone, Borg Backup UI has now been available in Community Apps for a few days, and I would like to collect some feedback from those of you who have already installed or tested it. The goal is to continuously improve the plugin, especially regarding: Installation and initial setup Creating your first repository and backup job UI clarity and usability Problems or errors Missing features Preferred communication channels for future feedback The survey is very short and should only take about 2 minutes. Feedback is also very welcome if everything worked without any problems. Knowing what already works well is just as valuable as knowing what needs improvement. 👉 Survey: https://forms.gle/EqVNi4jNRjDbdV259 Thank you very much for your support, feedback and for helping to improve Borg Backup UI! 🙂

Hier mal ein Log Beispiel für Appdata bei dem die Docker Container heruntergefahren werden im Anschluß wird die Sicherung durchgeführt. Unter Deduplicated size versteht Borg das was sich seit der lezten Sicherung geändert hat und das wandert ins Archiv. Mit Rentention ist gemeint welche Sicherung alle aufbewart werden sollen zB. 3 am Tag , 7 die Woche , 4 im Monat und 3 im Jahr. Nach der Sicherung werden die Docker Container wieder gestartet. Borg-Backup_appdata_storagebox--2026-08-09_23-15-34_anonymisiert.log

Ich kann dann nur Borg als Backup Tool empfehlen. Ersten werden die Daten auf dem Host vor der Übertragung verschlüsselt und remote per SSH übertragen wenn man es möchte somit sehr sicher. Das Repository ist am Ziel Ort auch verschlüsselt. Borg unterstützt depulizierung es werden nur Sektoren übertragen die sich geändert haben also nicht das ganze File sondern nur die Änderungen zur letzten Sicherung spart speicherplatz. Borg ist ein Standard unter Linux. Aber auch hier wird immer die 3-2-1 Sicherungsstrategie oder besser die 3-2-1-0-0. Bedeutet : 3 Kopien der Daten 2 unterschiedliche Speichermedien 1 Backup Offside 0 Air Gap vom Netzwerk isoliert 0 Backup Fehler regelmäßige Tests von Wiederherstellbarkeit

Danke dir für das Feedback! Gerade solche Hinweise zur Handhabung sind für mich sehr hilfreich. Das mit dem Appdata-Verzeichnis ist tatsächlich ein guter Punkt. Ich hatte /mnt/user/appdata bisher hauptsächlich als Verzeichnis für Docker-Container im Kopf und deshalb bewusst nicht als Standard gewählt. Aber eigentlich spricht nichts dagegen, für Borg Backup UI dort standardmäßig ein eigenes Verzeichnis vorzuschlagen. Das werde ich mir auf jeden Fall noch einmal anschauen. Auch der Hinweis mit den Pfaden ist gut. Für mich sind manche Dinge inzwischen wahrscheinlich einfach selbstverständlich oder logisch, weil ich die Anwendung von Anfang an entwickle. Für jemanden, der sie zum ersten Mal benutzt, muss das aber überhaupt nicht nachvollziehbar sein. Genau deshalb ist solches Feedback zur Bedienbarkeit für mich besonders wertvoll. Da werden sicherlich noch ein paar Punkte auftauchen, bei denen ich mir denke „ist doch logisch“ und ein anderer erst einmal überlegen oder auf die Konsole schauen muss. WebDAV habe ich tatsächlich schon auf der Agenda. 🙂 Ich möchte das voraussichtlich über rclone umsetzen. Bevor ich es aber als Ziel anbiete, möchte ich noch ausführlicher testen, wie zuverlässig Borg-Repositories auf einem über rclone/WebDAV eingebundenen Storage funktionieren. Solche eingebundenen Remote-Dateisysteme sind für Borg nicht unbedingt der ideale bzw. empfohlene Weg und gerade bei Backups möchte ich nichts anbieten, bei dem ich mir hinsichtlich der Zuverlässigkeit nicht sicher bin. Der Wunsch ist also definitiv angekommen – ich möchte es nur lieber sauber und zuverlässig umsetzen, statt einfach nur WebDAV als Option einzubauen. Hinweis: BorgBackup arbeitet am zuverlässigsten mit lokalen Dateisystemen oder über SSH zu einem Borg-Repository auf einem entfernten System. Ein per rclone/WebDAV eingebundenes Remote sieht für Borg zwar zunächst wie ein Dateisystem aus, darunter steckt aber kein „normales“ POSIX-Dateisystem. Das kann insbesondere bei Dingen wie Locking, atomaren Dateioperationen, Latenzen, Verbindungsabbrüchen und Konsistenz problematisch werden. Deshalb würde ich WebDAV über rclone nicht einfach freischalten, bevor es nicht richtig getestet wurde, wie Borg sich bei create, prune, compact, check und vor allem bei Abbrüchen verhält.

🎉 It’s official! A huge thank you to everyone for your support and especially for helping with the testing! 🙏 My plugin has now been approved by Unraid and is available through Community Applications (CA) as a Beta. 🚀 Development will of course continue, so feedback, suggestions, improvements, and feature requests are always very welcome. Thanks again to everyone who has supported the project so far! ❤️

🎉 Es ist soweit! Vielen Dank an Euch für den großartigen Support und vor allem fürs Testen! 🙏 Mein Plugin wurde von Unraid freigegeben und ist ab sofort über Community Applications (CA) als Beta verfügbar. 🚀 Natürlich geht die Entwicklung weiter. Feedback, Anregungen, Verbesserungsvorschläge und Feature-Wünsche sind jederzeit herzlich willkommen. Vielen Dank an alle, die mich bisher unterstützt haben! ❤️

Kurzes Update zu Borg Backup UI: Am Freitag habe ich das Plugin offiziell zur Freigabe bei Unraid / Community Applications eingereicht. 🎉 Jetzt heißt es erst einmal abwarten, bis die Prüfung abgeschlossen ist. Sobald das Plugin freigegeben wurde und über Community Applications verfügbar ist, gebe ich hier natürlich Bescheid. Vielen Dank nochmal an alle Tester für das bisherige Feedback und die Unterstützung! Auch nach dem Release sind Bugreports, Verbesserungsvorschläge und Ideen für neue Features jederzeit willkommen.

Falls jemand schon vorab testen möchte: Einfach eine PN an mich. 🙂 Wenn alles nach Plan läuft, reiche ich das Plugin Ende August offiziell bei Unraid ein.

Hallo zusammen, die bisherigen Tests mit Borg Backup UI liefen bereits sehr hilfreich. Insgesamt haben bisher 6 Tester das Plugin ausprobiert und mir wertvolles Feedback gegeben. Vielen Dank dafür! Bevor es in die öffentliche Beta geht, möchte ich die Testphase noch etwas ausweiten und suche daher weitere Tester mit unterschiedlichen Unraid-Systemen und Backup-Szenarien. Besonders interessant wären Rückmeldungen zu Installation und Erstkonfiguration, Verständlichkeit des Setup-Wizards, Backup-Jobs auf lokalen, USB-, SMB- oder SSH/Storagebox-Zielen, Repository-Erstellung und Repository-Import, Restore-Tests und Wiederherstellung einzelner Dateien, Fehlermeldungen, Hinweisen in der Oberfläche sowie zur allgemeinen Bedienbarkeit und Übersichtlichkeit. Wichtig: Das Plugin ist noch nicht offiziell über Community Apps veröffentlicht. Bitte testet es daher nur auf einem Testsystem oder mit bewusst dafür vorgesehenen Backup-Zielen. Wer Interesse hat, kann sich gerne per PN bei mir melden. Ich schicke dann den Link und kurze Hinweise zur Einrichtung. Feedback, Fehlermeldungen, Screenshots und Verbesserungsvorschläge sind sehr willkommen. Danke euch!

Borg Backup UI for Unraid - kurzes Entwicklungsupdate Hallo zusammen, es ist mal wieder Zeit für ein kleines Update. Aus dem ursprünglichen “ich baue mir ein paar Shell-Skripte” ist inzwischen ein ausgewachsenes Unraid-Plugin geworden. Und ehrlich gesagt: Es macht gerade richtig Spaß zu sehen, wie nah Borg Backup UI inzwischen an eine erste öffentliche Beta rückt. In den letzten Wochen ist unter der Haube und in der Oberfläche einiges passiert. Benachrichtigungen sind jetzt deutlich flexibler Die bisherige ntfy-Unterstützung wurde auf Apprise-Benachrichtigungsprofile erweitert. Damit sind nicht mehr nur einzelne Push-Meldungen möglich, sondern viele verschiedene Anbieter, z. B. ntfy, Rocket.Chat, Discord, Mail, Webhooks und weitere Apprise-Provider. Profile können gezielt für bestimmte Ereignisse aktiviert werden, z. B. erfolgreiche Backups, Warnungen, Fehler oder Restore-Test-Ergebnisse. Testnachrichten und URL-Prüfung sind direkt in der Oberfläche möglich. Tokens und Passwörter bleiben write-only und werden nicht wieder in den Browser gerendert. SMB ist jetzt viel angenehmer nutzbar SMB-Profile bekommen eigene verwaltete Mountpfade unter /mnt/borg-backup-ui/smb/. Profile können direkt in den Einstellungen gemountet und unmountet werden. Der Mountstatus wird beim Öffnen eines Profils automatisch aktualisiert. Wer ein SMB-Ziel dauerhaft eingehängt lassen möchte, kann das über entsprechende Optionen steuern. Logs und Diagnose sind deutlich brauchbarer geworden Die Logs sind ruhiger und enthalten weniger wiederkehrende Routine-Abfragen. Wichtige Aktionen schreiben jetzt mehr Kontext: welcher Job, welches Repository, welche Aktion, welcher Auslöser. Backup- und Restore-Test-Läufe schreiben kompakte Zusammenfassungen ins Support-Log. Im Fehlerfall sollte dadurch viel schneller erkennbar sein, was passiert ist und wo man suchen muss. Warum das Ganze? Mein Ziel ist weiterhin nicht einfach nur “Borg per Weboberfläche starten”. Borg Backup UI soll den kompletten Backup-Alltag auf Unraid abbilden: Jobs sauber anlegen Speicherziele und Repositorys verwalten Docker-Container und VMs berücksichtigen Backups ausführen und nachvollziehen Restore-Tests planen Wiederherstellungen prüfen Benachrichtigungen sauber auswerten und im Fehlerfall genug Informationen liefern, ohne direkt in Log-Chaos zu versinken Gerade der Punkt Restore bleibt für mich zentral: Ein Backup ist erst dann wirklich beruhigend, wenn man auch regelmäßig sieht, dass eine Wiederherstellung technisch funktioniert. Aktuell läuft die private Testphase weiter. Die Rückmeldungen daraus haben schon viele Ecken geglättet und einige größere Verbesserungen angestoßen. Wenn die letzten offenen Punkte erledigt sind, geht es Richtung erste öffentliche Beta.