På sida 3 handlade den här långa supporttråden inte längre främst om fjärrinloggning. Det konkreta problemet hade blivit en Duplicati-container som kördes men öppnades som Service Unavailable. Loggen gav den avgörande ledtråden: inställningsdatabasen hade skapats utan en giltig SETTINGS_ENCRYPTION_KEY, och att ändra miljövariabler i efterhand hade inte reparerat det redan skapade konfigurationstillståndet.
Communityns lösning var medvetet begränsad: ta bort och återskapa Duplicati-containern, rensa endast dess konfigurationsdatabas, låt säkerhetskopieringsdestinationen och källmapparna vara orörda och skapa sedan Duplicati på nytt en gång med en riktig krypteringsnyckel för inställningarna. Den ursprungliga skribenten svarade senare: ”Jag kom in”, vilket bekräftade att återställningsvägen återställde åtkomsten.
Duplicati-loggen identifierade den saknade krypteringsnyckeln för inställningarna
Källoggen avslutades med:
Missing encryption key, unable to encrypt your settings database
Please set a value for SETTINGS_ENCRYPTION_KEY and recreate the container
Detta är betydligt starkare bevis än att gissa på portar eller ZimaOS-fjärråtkomst. Felet låg i Duplicatis applikations- och konfigurationslager.
Inställningsnyckeln är inte samma sak som lösenordet för säkerhetskopieringskryptering
-
SETTINGS_ENCRYPTION_KEYskyddar Duplicatis lokala inställningsdatabas; - lösenordet för säkerhetskopieringskryptering skyddar säkerhetskopierat innehåll;
- WebUI:s inloggningslösenord är en separat autentiseringsuppgift.
Dokumentera dessa hemligheter i en lösenordshanterare i stället för att återanvända ett svagt testvärde som 1234.
Ta inte bort säkerhetskopieringsdestinationen
Källan varnade uttryckligen för att röra säkerhetskopieringsdata eller källmappar. Återställningen riktades endast mot Duplicatis konfigurationsdatabas under AppData-konfigurationssökvägen. Att ta bort en container innebär inte automatiskt att säkerhetskopior tas bort när säkerhetskopieringsdata lagras i en separat mapp på värden som är mappad till containern.
Återskapa containern med en giltig nyckel
- stoppa och ta bort den trasiga Duplicati-containern;
- säkerhetskopiera och rensa sedan endast Duplicatis konfigurationsdatabas;
- ange en stark
SETTINGS_ENCRYPTION_KEY; - återskapa containern en gång;
- öppna WebUI och kontrollera att installationen startar normalt.
Eftersom detta är felsökning från communityn bör du granska de faktiska aktuella volymmappningarna innan du tar bort någon konfigurationskatalog.
Blanda inte appbutiksinstallationer med manuella Docker-installationer
Tidigare i samma tråd skapade användaren av misstag en andra Duplicati-container manuellt samtidigt som App Store användes. Det skapade oklarheter kring portar och konfiguration. Välj en distributionsmetod och använd en enda auktoritativ konfigurationssökväg.
Duplicati är en arkivbaserad säkerhetskopia, inte en bläddringsbar spegling
Den fortsatta diskussionen i källan klargjorde att Duplicati lagrar block tillsammans med metadata. Destinationen förväntas inte se ut som en vanlig kopia av alla källmappar; återställningar utförs via Duplicati.
Testa både återställning av en enskild fil och återställning av en mapp innan du litar på säkerhetskopian för produktionsdata.
Blanda inte ihop Duplicati med ZimaOS Backup
ZimaOS har också ett eget schemalagt och versionshanterat säkerhetskopieringssystem. Duplicati är användbart när du specifikt vill ha Duplicatis krypterade arkivformat och stöd för vissa destinationer; den inbyggda Backup-appen är enklare när dess stödda källor och destinationer motsvarar kravet.
Använd det aktuella säkerhetskopieringsarbetsflödet i ZimaOS.
Vanliga frågor om Duplicati Service Unavailable
Bekräftade användaren från källan att åtkomsten hade återställts?
Ja. Efter felsökningen av konfigurationen och nyckeln sade den ursprungliga skribenten att hen kom in i Duplicati.
Bör jag ta bort mina Duplicati-säkerhetskopior för att åtgärda WebUI?
Nej. Lösningen i källan riktade sig endast mot den trasiga konfigurationsdatabasen, inte mot säkerhetskopieringsdestinationen eller källdatan.
Är SETTINGS_ENCRYPTION_KEY lösenordet för säkerhetskopieringen?
Nej. Den skyddar Duplicatis lokala inställningsdatabas och är separat från krypteringen av säkerhetskopierat innehåll.
