Hallo Gemeinde.

Ich habe nun bitterlich erfahren wie wichtig Backups sind. Nichts ernstes aber es geht nun viel zeit drauf weil ich etwas neu machen muss.

Hintergrund ich habe bei mir im Unraid die Festplatten vergrössert. Hat 3 mal nen 17 Stündigen Paritätslauf gekostet aber nun gut. Dabei sind mir Files abhandengekommen von meinem Paperless und zwar die DB. Die war dummerweis nicht im APPDATA folder. Wurde nun korrigiert.

Nun zu meinem Anliegen:

Lokales Backup (3 Tage) via Appdata Backup Plugin.

Ich möchte minimum einen Tag im idealfall 3 Tage auf einem VPN Share incrementel sichern.

D.h. das erste Backup wird dauern aber danach werden nur noch Änderungen übertragen. Un da kommt das Problem was ich ncoh nicht gelöst habe.

AppData Backup erzeugt zum einen jeweils einen Unterordner für jedes Backup und selbst ohne Kompression tar files für die Container Daten.

RSYNC kann nach meinem Kenntnisstand (Google) TAR Files nicht incremenmtel sicher. Ers schiebt die komplette Datei rüber. Das hat ncihts mit inkrementel zu tun.

Ich hatte auch schon mal Kopia versucht aber der würde einen neuen Subfolder sicherlich auch als komplett neu einstufen und die follen ggf. mehrere 10 GB transferieren obwohl sich vielleciht nur 1 GB an daten ändert.

Ich habe eine Idee aber die ermöglicht ggf. nur ein Remote Backup und ist dioe idee ist recht heftig wie ich finde.

Nachdem AppData Backup fertig ist, würde ich das letzte Backup nehmen alle Files entpacken in einen festen Subfolder entpacken und der würde via RSYNC / KOPIA transferiert. Wenn sich dann in einem Container weil er z.B. nur Daten in eine externe Mysql schreibt lediglich das LOGFILE ändert, wird auch nur das übertragen.Soweit die Theorie.

Problem: Ja zwar VPN und der gegenpart und ich kennen uns aber wäre je dennoch nett wenn eben nicht offen auf die Files zugegrifen werden kann. Mit einem Remote SSH könnte man diese daten dann sicherlich wieder verschlüsseln.

Finde ich alles etwas aufwändig, für etwas was aus meiner sicht doch wahrscheinlich jeder von euch benötigen könnte.

Gibt es andere Wege? Denke ich zu kompliziert? Kenn ich nur die richtige APP nicht?

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

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

Danke schau ich mir mal an.

10 hours ago, Thorsten said:

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.

und Du meinst, das funktioniert auch, wenn ich jeden Tag eine neue tar-Datei schreibe?

Appdata Backup erzeugt bei mir z.B. jeden Tag einen Ordner

und in jedem Ordner ist u.a. eine paperless-ngx.tar.gz

Diese einzelnen tar.gz-files sind bei mir inhaltlich sehr identisch, da kaum Dokumente hinzukommen.

Kann Borg diese Gemeinsamkeiten auf Block-Ebene erkennen, so wie es Sven wünscht, und demnach nur die Unterschiede übertragen? Ich denke nicht.

Der springende Punkt: wir reden ja nicht von derselben Datei, die sich vergrößert, sondern von neuen Dateien, die nur zufällig einen z.T. gemeinsamen Inhalt haben....

Was Du hier machst, ist ja, das Plugin "Appdata Backup" zu umgehen und es quasi mit deinem Borg-Skript zu ersetzen

9 hours ago, Thorsten said:

Hier mal ein Log Beispiel für Appdata bei dem die Docker Container heruntergefahren werden im Anschluß wird die Sicherung durchgeführt.

Du machst also kein tar lokal, sondern direkt ein Borg-Backup der appdata-Ordner auf einen remote host.

Gute Idee, aber das würde dann auch genauso mit rsync funktionieren, auf Dateiebene synct das auch nur die diffs.

Rsync scheitert beim Threadersteller ja gerade genau an dem, was ich oben schrieb.

Borg mag seine Vorteile haben (z.B. Verschlüsselung), aber mittlerweile bin ich persönlich weg von Backuptools, bei denen man ohne das richtige Tool nicht mehr an die Daten kommt...

Der Ansatz, das Plugin zu ersetzen ist aber definitiv eine gute Idee für diesen UseCase.

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.

Ich habe BorgBackup nun laufen und bin erstmal begeistert.

Da es sogar die COntainer und die VMs stoppt für ein sauberes Backup ist das die beste option für mich glaube ich.

Nun eine Frage wenn ich die Jobs einrichte. Ich habe Freigaben die auf Cache und Array laufen also dann mit dem Mover verschoben werden. Gebe ich im Backup job nun eher /mnt/cache/ordner und /mnt/user/ordner an oder reicht /mnt/user/ordner und er weis das er daten vom Array und vom Cache sichern muss?

Ich bin noch verwirrt wie unraid es schaft daten von unterschiedlichen Physischen Laufwerken auf einen folder zu mappen.

5 hours ago, svenskalec said:

Gebe ich im Backup job nun eher /mnt/cache/ordner und /mnt/user/ordner an oder reicht /mnt/user/ordner und er weis das er daten vom Array und vom Cache sichern muss?

/mnt/user ist immer die Summe aus Cache + Array.

Für deinen zweck also der "way to Go"

21 hours ago, svenskalec said:

Ich habe BorgBackup nun laufen und bin erstmal begeistert.

Da es sogar die COntainer und die VMs stoppt für ein sauberes Backup ist das die beste option für mich glaube ich.

Nun eine Frage wenn ich die Jobs einrichte. Ich habe Freigaben die auf Cache und Array laufen also dann mit dem Mover verschoben werden. Gebe ich im Backup job nun eher /mnt/cache/ordner und /mnt/user/ordner an oder reicht /mnt/user/ordner und er weis das er daten vom Array und vom Cache sichern muss?

Ich bin noch verwirrt wie unraid es schaft daten von unterschiedlichen Physischen Laufwerken auf einen folder zu mappen.

Welches der vielen BorgBackup nutzt du ?

On 8/17/2026 at 12:56 PM, Thorsten said:

Welches der vielen BorgBackup nutzt du ?

Ich habe in UNraid unter APPS einfach nach BorgBackup gesucht und dann BorgBackup UI installiert. Das läuft dann unter Plugins.

Ich habe nun auch auf Homeassistant welches auf einer separaten Hardware läuft mittels dort installiertem Addon auf dem BorgBaup des Unraid Servers sichern können. Habe dafür eine eigenen Repository angelegt. Leider kann ichd ie Archiv daten in der BorgBackup UI nciht einsehen. Muss man da noch was einstellen damit man an die Daten kommt?

1 hour ago, svenskalec said:

Ich habe in UNraid unter APPS einfach nach BorgBackup gesucht und dann BorgBackup UI installiert. Das läuft dann unter Plugins.

Okay wenn du damit Probleme hast melde Dich das Plugin ist von mir.

1 hour ago, svenskalec said:

Ich habe nun auch auf Homeassistant welches auf einer separaten Hardware läuft mittels dort installiertem Addon auf dem BorgBaup des Unraid Servers sichern können. Habe dafür eine eigenen Repository angelegt. Leider kann ichd ie Archiv daten in der BorgBackup UI nciht einsehen. Muss man da noch was einstellen damit man an die Daten kommt?

Beschreibe mir das mal genauer. Wenn das Repository unter Repositories in Borg Backup UI bekannt ist kann er auch drauf zugreifen. Aktuell verstehe ich nicht genau was du meinst. Wenn es unter schiedlicher Server sind z.B. Server A legt das Repository an Server B ist Borg Backup UI und will reinschreiben gibt es von Borg eine Meldung das das Repository unter einer anderen IP angelegt wurde mit der Frage ob dieses geändert werden soll.

Wenn Feature wünsche oder was unklar ist oder Fehler Im Support Thread melden oder per Github als Issue oder Mail egal wie wo und was ich will das Plugin verbessern. Akutell kann ich nur Hotfixes machen da ich bis nächsten Woche Donnerstag noch im Urlaub bin

Keiner Tipp noch wie ich sehe sicherst du ja das Appdata Verzeichnis. Wenn du bei den Docker Container unter Extra Parameters (Advanced View) folgendes einträgst

--label backup.start.priority=1 (1-3) kannst du die start Reihenfolge noch bestimmen.

2026-08-18 09:04:42 INFO Starting 29 Docker containers by priority...

2026-08-18 09:04:42 INFO === Phase 1: Critical infrastructure (databases, cache) ===

2026-08-18 09:04:42 INFO Starting 6 containers (Priority 1 - infrastructure)...

2026-08-18 09:04:42 INFO - Starting postgresql17 (291a30a2257e)

2026-08-18 09:04:44 INFO - Starting Redis (f3f663f4613d)

2026-08-18 09:04:46 INFO - Starting MariaDB-Official (92eec0d6f9b5)

2026-08-18 09:04:47 INFO - Starting mysql (18c4342d15a0)

2026-08-18 09:04:49 INFO - Starting Nginx-Proxy-Manager-Official (664f38e0a8ef)

2026-08-18 09:04:52 INFO - Starting MongoDB (f28c4943ceed)

2026-08-18 09:05:14 INFO === Phase 2: Standard applications ===

2026-08-18 09:05:14 INFO Starting 16 containers (Priority 2 - standard)...

2026-08-18 09:05:14 INFO - Starting plex (53c81eba2a6f)

Edited August 18Aug 18 by Thorsten

On 8/18/2026 at 7:40 PM, Thorsten said:

Beschreibe mir das mal genauer. Wenn das Repository unter Repositories in Borg Backup UI bekannt ist kann er auch drauf zugreifen. Aktuell verstehe ich nicht genau was du meinst. Wenn es unter schiedlicher Server sind z.B. Server A legt das Repository an Server B ist Borg Backup UI und will reinschreiben gibt es von Borg eine Meldung das das Repository unter einer anderen IP angelegt wurde mit der Frage ob dieses geändert werden soll.

Wenn Feature wünsche oder was unklar ist oder Fehler Im Support Thread melden oder per Github als Issue oder Mail egal wie wo und was ich will das Plugin verbessern. Akutell kann ich nur Hotfixes machen da ich bis nächsten Woche Donnerstag noch im Urlaub bin

Ich habe unter Unraid ein Repository angelegt für den externen Homeassistant server. Nachdem ich dirt nun auch das SSH Auth problem gelöst hatte erstellt Homeassistant auf dem Unraid in seinem speziellen Repository ein Backup. Wenn ich links unter Browse and Restore nachschaue sehe ich dieses aber nciht. Ich hätte gedacht das ich auf dem Borg Backup SERVER (unraid) an die Daten rankome wenn ich das Verschlüsselungskennwort habe.

Sry das ich mcih länge rnciht gemeldet habe. Ich bekomm hier keine Mails bei ANtworten. Das werd ich gleich mal prüfen.

Gibt es eine Fehlermeldung ? oder kannst du mir mit Screenshots erklären war nicht stimmt?
Von wo willst du auf was zu greifen von Borg Backup UI auf ein Repository welches auf dem Homeassistant liegt oder von wo anders auf ein Repoitory welches auf den Borg Backup Server liegt?

Welches Addon nutzt du ggf. passt die Borg version nicht?

Edited August 29Aug 29 by Thorsten

Der wichtige Punkt ist aber: Browse & Restore in Borg Backup UI ist aktuell noch job-orientiert. Das heißt, die Ansicht geht normalerweise von einem Backup-Job aus, der in Borg Backup UI angelegt wurde und mit einem Repository verknüpft ist.

Wenn Home Assistant selbstständig in ein Repository auf Unraid schreibt, ist das aus Borg-Sicht zwar ein gültiges Repository, aber Borg Backup UI erkennt es nicht automatisch als Restore-Quelle, solange es nicht als Repository importiert bzw. einem Job/Kontext in Borg Backup UI zugeordnet ist.

Kannst du bitte kurz prüfen bzw. mitteilen:

- Ist das Home-Assistant-Repository im Repository Manager von Borg Backup UI importiert?

- Ist dort das richtige Passwort bzw. der Key hinterlegt?

- Gibt es in Borg Backup UI einen Job, der auf genau dieses Repository zeigt?

Das Repository ewrzeuge ich in deiner UI. In Homeassistant hinterlege ich dann Pfad, Connection Daten udn das Verschlüsselungskennwort.

Nein es gibt in der Ui kein Job dafür.

Kleiner Tip für deien Ui ich verzweifel immer wenn ich da in den Optionen was ändere. Kannst du das Modal so konfigurieren das es nur über einen Button zu geht und nciht wenn man ausserhalb klickt. Habe da schion mit Alt Tab weil ich woanders hinspringen muste das Fenster weider geschlossen und muste alles neu eingeben. Das nerft ein bissel.

Hallo,

danke, jetzt verstehe ich dein Setup.

Du hast das Repository mit Borg Backup UI auf Unraid angelegt. Anschließend greift Home Assistant als eigenständiger Borg-Client darauf zu und erstellt dort seine Archive. In Borg Backup UI existiert dafür jedoch kein Backup-Job.

„Browse & Restore“ arbeitet aktuell ausschließlich mit Jobs, die in Borg Backup UI angelegt wurden. Über den Job kennt die Anwendung unter anderem:

• das zugehörige Repository und Speicherprofil,

• den Archivfilter beziehungsweise das Namensmuster,

• die benötigten Zugangsdaten,

• sowie die Zuordnung für Restore, Retention, Berichte und Restore-Tests.

Ein Repository allein wird deshalb nicht als wiederherstellbare Quelle in „Browse & Restore“ angezeigt. Borg Backup UI durchsucht Repositories nicht automatisch nach Archiven externer Borg-Clients.

Technisch kannst du auf die von Home Assistant erstellten Archive zugreifen, sofern alle benötigten Zugangsdaten vorhanden sind. Abhängig von der verwendeten Borg-Verschlüsselung können neben der Passphrase auch der Repository-Schlüssel beziehungsweise eine Key-Datei benötigt werden. Die Wiederherstellung müsste derzeit aber über Home Assistant selbst oder direkt über Borg auf der Kommandozeile erfolgen.

Borg Backup UI ist in diesem Fall nur der Ort, an dem das Repository angelegt wurde. Es arbeitet nicht als allgemeiner Borg-Server mit automatischer Erkennung und Verwaltung beliebiger externer Clients. Eine Unterstützung externer Archive wäre ein eigenständiges Feature und keine kleine Erweiterung des bestehenden Restore-Assistenten.

Deinen Hinweis zu den Dialogfenstern kann ich dagegen gut nachvollziehen. Ein mehrstufiger Eingabedialog sollte sich nicht durch einen versehentlichen Klick außerhalb schließen und dabei alle Eingaben verwerfen. Ich werde das als separates UI-Thema aufnehmen. Sinnvoll wäre:

• kein Schließen durch einen Klick auf den Hintergrund,

• Schließen nur über "Abbrechen" , "X" oder "Speichern"

Danke für die ausführliche Erklärung und das Feedback. Solche konkreten Anwendungsfälle helfen mir sehr dabei, die Bedienung gezielt zu verbessern.

Was die UI allerdings zumindest bis gestern angezeitg hat ist das er die anzahl der archive und den Speicherverbrauch bzw. die kompression anzeigt. Ich hatte aber nun ein neues Repository für Homeassistant erstellt weil mit Ha sagt das Backup wurde erstellt aber deine UI die anzahl der Archive und das aktuelle Backup nicht mehr angezeigt bzw. aktualisiert hat. Da muss irgendwas klappen aber irgendwas auch wieder nicht ;-)

Ja weil es zwei verschiedene dinge sind.

Diese Ansicht von Respoitory arbeitet mit borg info und benötigt selber keinen Job: Diese Informationen werden wenn in Einstellungn aktiv mit einem Hintergrund Prozess aktualisiert dieses ist jedoch per default deaktiv.

Oder man kann diese Informationen aktualisieren wenn man auf "Info aktuallisieren" klickt dann wird ein borg info auf das Respository ausgeführt und die Daten sollen aktualisiert werden.

Hier die Einstellung für den Hintergrund Prozess "Weck aber Festplatten auf" deswegen per default deaktiv.

Alle andere funktionen die auf dieses Repository zugreifen sollen funktionieren nur mit einem Job in diesem Fall der Job "Flash"