Eine Duplicati-Meldung, dass eine .dblock.zip.aes Datei fehlt, klingt nach einer beschädigten Sicherung, aber der Quellthread zeigt, warum eine destruktive Reparatur nicht die erste Reaktion sein sollte. Das Sicherungsziel war auf dem ZimaOS-Host vorhanden und über Samba sichtbar, doch Duplicatis Container konnte diese HDD über seine Docker-Volume-Zuordnungen tatsächlich nicht sehen.
Nachdem der Benutzer die tatsächliche Host-HDD in den Container eingebunden und das neue containerseitige Ziel ausgewählt hatte, antwortete er, dass es offenbar funktioniere. Die Quelle endete somit mit einer bestätigten Lösung durch die Docker-Pfadzuordnung und nicht mit einer bestätigten Löschung der beschädigten Sicherung.
Der anfängliche Fehler sah nach einem beschädigten Duplicati-Repository aus
Duplicati meldete, dass die Reparatur fehlgeschlagen war, weil am Sicherungsspeicherziel eine bestimmte verschlüsselte dblock Datei. Die Meldung bot zwei Möglichkeiten zur Wiederherstellung: fehlende Blockdateien aus den lokalen Quelldaten neu zu erstellen oder Sicherungseinträge zu löschen, die nicht mehr wiederhergestellt werden konnten.
Diese Optionen sind echte Duplicati-Funktionen, ergeben aber erst Sinn, nachdem überprüft wurde, dass das inspizierte Sicherungsziel das richtige und vollständige Ziel ist.
Der Benutzer sicherte eine lokale Festplatte auf einer anderen
Das vorgesehene Layout war:
- Quelldaten auf einer lokalen SSD;
- Sicherungsziel auf einer separaten HDD;
- Duplicati wurde aus dem ZimaOS App Store installiert und lief daher in Docker.
Der Benutzer wählte die Pfade über den Ordnerauswahldialog der Anwendung aus und nahm an, dass der Container denselben Hostspeicher sehen könne.
Ein ZimaOS-Hostpfad und ein Duplicati-Containerpfad sind nicht dasselbe
Eine Docker-App kann nur auf Hostordner zugreifen, die in den Container eingebunden wurden. ZimaOS kann über Dateien oder Samba auf einen Datenträger zugreifen, während Duplicati nichts sieht, wenn dieser Datenträger in der Volume-Konfiguration der App fehlt.
Deshalb kann ein Verbindungstest allein irreführend sein: Der Zieltyp kann gültig sein, während der Inhalt des vorgesehenen Ordners im Container-Namespace tatsächlich nicht sichtbar ist.
Der Test mit der temporären Datei brachte das eigentliche Problem ans Licht
Der Benutzer erstellte eine temp.txt Datei im Zielordner. Sie war über Samba sichtbar, jedoch nicht im Dateibrowser von Duplicati. Das war ein deutlicher Hinweis darauf, dass Duplicati nicht den tatsächlichen Inhalt der Host-HDD sah.
Zu diesem Zeitpunkt änderte der Antwortende ausdrücklich seine Empfehlung und riet, vorerst weder purge noch rebuild auszuführen.
Die funktionierende Lösung bestand darin, die HDD in den Container einzubinden
Der Antwortende wies den Benutzer an, die App-Einstellungen von ZimaOS zu öffnen, die HDD als Host-Volume hinzuzufügen und sie einem einfachen Containerpfad zuzuordnen, etwa /backup, starten Sie den Container neu und wählen Sie anschließend ein Ziel unterhalb dieses Containerpfads aus.
Der ursprüngliche Verfasser antwortete: „Jetzt scheint es zu funktionieren.“
Das bestätigte die Zuordnung des Volumes als praktikable Lösung.
Zusätzliche Quelllaufwerke benötigen eigene Zuordnungen
Der Benutzer fragte anschließend, ob ein Duplicati-Auftrag mehrere Quellordner enthalten könne. Die Antwort der Community lautete: ja, sofern jeder Quellpfad auch innerhalb des Containers sichtbar ist.
Wenn ein zweites Laufwerk nicht über die Docker-Volumes der App verfügbar gemacht wird, erscheint es in Duplicati nicht korrekt, unabhängig davon, wie gültig der Hostpfad ist.
Verwende die aktuelle Volume-Zuordnung für ZimaOS-Apps, anstatt rohe Pfade zu erraten
Das aktuelle ZimaOS zeigt Host- und Containerpfade in den Anwendungseinstellungen an und dokumentiert, wie persistenter Speicher in Docker-Apps eingebunden wird.
Verwende das aktuelle ZimaOS-Docker-Pfadmodell, wenn du Backup-Quellen oder -Ziele hinzufügst.
Wann eine Duplicati-Reparatur sinnvoll ist
In der aktuellen Befehlszeilendokumentation von Duplicati heißt es, dass Repair die lokale Datenbank aus dem Remotespeicher neu erstellen oder versuchen kann, fehlende Remotedaten zu rekonstruieren, sofern die erforderlichen lokalen Quelldaten noch verfügbar sind.
Die erweiterte --rebuild-missing-dblock-files Die Option versucht gezielt, fehlende Blockdateien aus lokal verfügbaren Quelldaten neu zu erstellen. Duplicati weist jedoch darauf hin, dass sich die Daten geändert haben können und die Wiederherstellung unvollständig oder langsam sein kann.
purge-broken-files ist destruktiv für den Wiederherstellungsverlauf
In der aktuellen Duplicati-Dokumentation heißt es: purge-broken-files entfernt Dateien aus Backup-Versionen, die nicht mehr wiederhergestellt werden können, damit der Backup-Satz fortgesetzt werden kann. Es sollte nur verwendet werden, wenn fehlende Remotedaten nicht wiederhergestellt werden können.
Bevor du Daten löschst, überprüfe die aktuellen Duplicati-Wiederherstellungsbefehle und ihre Folgen. Ein Probelauf oder eine Liste beschädigter Dateien ist sicherer, als die Backup-Historie blind zu löschen.
Die Fehlermeldung war korrekt, aber das zugrunde liegende Ziel war falsch
Duplicati meldete korrekt, dass in der sichtbaren Repository-Ansicht erwartete Dateien fehlten. Irreführend war die Annahme, diese Repository-Ansicht repräsentiere die tatsächliche Festplatte. Die Docker-Pfadzuordnung hatte die Anwendung auf eine unvollständige oder andere Dateisystemansicht verwiesen.
Duplicati-dblock-FAQ
Wurde nachgewiesen, dass das Quell-Backup-Repository beschädigt war?
Nein. Das ursprüngliche Problem wurde nach der Korrektur der Docker-Volume-Zuordnung gelöst.
Sollte purge-broken-files der erste Schritt sein?
Nein. Überprüfe vor jeder destruktiven Reparatur, ob das richtige vollständige Ziel eingebunden und sichtbar ist.
Kann ein Duplicati-Auftrag mehrere ZimaOS-Laufwerke sichern?
Ja, aber jedes Quelllaufwerk muss in den Duplicati-Container eingebunden werden.
