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.