Auf Seite 3 ging es in diesem langen Support-Thread nicht mehr hauptsächlich um die Remote-Anmeldung. Das konkrete Problem war nun ein Duplicati-Container, der zwar lief, aber mit Service Unavailable geöffnet wurde. Sein Protokoll lieferte den entscheidenden Hinweis: Die Einstellungsdatenbank war ohne einen gültigen SETTINGS_ENCRYPTION_KEY erstellt worden, und eine nachträgliche Änderung der Umgebungsvariablen hatte den bereits erstellten Konfigurationszustand nicht repariert.
Die Lösung der Community war bewusst eng gefasst: Den Duplicati-Container entfernen und neu erstellen, nur seine Konfigurationsdatenbank löschen, das Backup-Ziel und die Quellordner unangetastet lassen und Duplicati anschließend einmalig mit einem echten Schlüssel zur Verschlüsselung der Einstellungen neu erstellen. Der ursprüngliche Verfasser antwortete später: „Ich bin reingekommen.“ Damit bestätigte er, dass der Wiederherstellungsweg den Zugriff wiederhergestellt hatte.
Das Duplicati-Protokoll identifizierte den fehlenden Schlüssel zur Verschlüsselung der Einstellungen
Das Quellprotokoll endete mit:
Missing encryption key, unable to encrypt your settings database
Please set a value for SETTINGS_ENCRYPTION_KEY and recreate the containerDas ist ein deutlich stärkerer Hinweis, als über Ports oder den Fernzugriff auf ZimaOS zu spekulieren. Der Fehler lag in der Duplicati-Anwendungs- beziehungsweise Konfigurationsebene.
Der Schlüssel für die Einstellungen ist nicht dasselbe wie das Backup-Verschlüsselungspasswort
-
SETTINGS_ENCRYPTION_KEYschützt die lokale Einstellungsdatenbank von Duplicati; - das Backup-Verschlüsselungspasswort schützt die Backup-Inhalte;
- das WebUI-Anmeldepasswort ist ein weiteres, separates Zugangsdatenpaar.
Bewahre diese Geheimnisse in einem Passwortmanager auf, anstatt einen schwachen Testwert wie 1234 wiederzuverwenden.
Lösche nicht das Backup-Ziel
In der Quelle wurde ausdrücklich davor gewarnt, Backup-Daten oder Quellordner anzutasten. Zurückgesetzt wurde ausschließlich die Duplicati-Konfigurationsdatenbank im AppData-Konfigurationspfad. Das Entfernen eines Containers bedeutet nicht automatisch das Löschen von Backups, wenn die Backup-Daten in einem separat eingebundenen Host-Ordner gespeichert sind.
Erstelle den Container mit einem gültigen Schlüssel neu
- den defekten Duplicati-Container stoppen und entfernen;
- zuerst eine Sicherung erstellen und anschließend nur die Duplicati-Konfigurationsdatenbank löschen;
- einen starken
SETTINGS_ENCRYPTION_KEYfestlegen; - den Container einmalig neu erstellen;
- die WebUI öffnen und prüfen, ob die Einrichtung normal startet.
Da es sich um eine Fehlerbehebung aus der Community handelt, solltest du vor dem Löschen eines Konfigurationsverzeichnisses die tatsächlich aktuellen Volume-Zuordnungen überprüfen.
Kombiniere keine Installationen aus App Store und manuellem Docker-Setup
Im selben Thread erstellte der Benutzer versehentlich einen zweiten Duplicati-Container manuell, während er gleichzeitig den App Store verwendete. Dadurch entstanden Unklarheiten bei Ports und Konfiguration. Entscheide dich für eine Bereitstellungsmethode und verwende einen einzigen maßgeblichen Konfigurationspfad.
Duplicati ist ein Archiv-Backup, kein durchsuchbarer Spiegel
Im weiteren Verlauf der Quelldiskussion wurde klargestellt, dass Duplicati Blöcke und Metadaten speichert. Das Ziel muss daher nicht wie eine normale Kopie jedes Quellordners aussehen; Wiederherstellungen werden über Duplicati durchgeführt.
Teste sowohl die Wiederherstellung einer einzelnen Datei als auch die eines Ordners, bevor du dem Backup Produktionsdaten anvertraust.
Verwechsle Duplicati nicht mit dem ZimaOS-Backup
ZimaOS verfügt auch über ein eigenes geplantes, versioniertes Backup-System. Duplicati ist sinnvoll, wenn du ausdrücklich Duplicatis verschlüsseltes Archivformat und dessen Unterstützung für verschiedene Ziele benötigst. Die integrierte Backup-App ist einfacher, wenn ihre unterstützten Quellen und Ziele deinen Anforderungen entsprechen.
Nutze den aktuellen ZimaOS-Backup-Ablauf.
FAQ zu „Duplicati Service Unavailable“
Hat der Benutzer aus der Quelle bestätigt, dass der Zugriff wiederhergestellt wurde?
Ja. Nach der Fehlerbehebung an Konfiguration und Schlüssel sagte der ursprüngliche Verfasser, dass er in Duplicati hineingekommen sei.
Sollte ich meine Duplicati-Backup-Dateien löschen, um die WebUI zu reparieren?
Nein. Die Lösung aus der Quelle zielte ausschließlich auf die defekte Konfigurationsdatenbank, nicht auf das Backup-Ziel oder die Quelldaten.
Ist SETTINGS_ENCRYPTION_KEY das Backup-Passwort?
Nein. Es schützt die lokale Einstellungsdatenbank von Duplicati und ist von der Verschlüsselung der Backup-Inhalte getrennt.
