Slik selvhoster du Duplicati i 2026: Krypterte sikkerhetskopier, monteringer og gjenopprettingstester

Hvis du allerede har prøvd å selvhoste Duplicati, kjenner du sannsynligvis den frustrerende situasjonen: Brukergrensesnittet vises, men containeren ser en tom sti fordi kildene på verten ble montert et annet sted. Å opprette containeren på nytt løser sjelden en uoverensstemmelse mellom URL-er, state og avhengigheter.

Denne gjennomgangen bruker ett konkret fullføringskriterium — sikkerhetskopier en testkatalog til det valgte målet, slett en kildefil og gjenopprett den til en ren alternativ sti. Hvert konfigurasjonsvalg vurderes opp mot dette kriteriet, ikke ut fra et grønt containermerke.

Porter, prosesser og private tjenester

Et nyttig Duplicati-diagram viser den offentlige ruten, den private porten 8200, state-grensen og alle støttende krav. Marker hvilke piler som transporterer credentials, og hvilke som er vanlig brukertrafikk. Nettverkskontrakten for Duplicati er skrivebeskyttede kildemonteringer samt tilgjengelig lagring for sikkerhetskopimålet. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Duplicati en avgrenset service credential.

Bevis diagrammet med én reell handling: sikkerhetskopier en testkatalog til det valgte målet, slett en kildefil og gjenopprett den til en ren alternativ sti. Belastningen kommer sannsynligvis fra antall kildefiler, komprimering, kryptering, forsinkelse til målet og overlapp mellom planlagte jobber. Overvåk denne stien i stedet for å behandle alle HTTP-forespørsler som like.

Diagnostiser en Duplicati-instans som ser frisk ut

Bygg dashboards rundt antall kildefiler, komprimering, kryptering, forsinkelse til målet og overlapp mellom planlagte jobber. En CPU-graf uten denne arbeidsbelastningskonteksten kan ikke forklare hvorfor Duplicati er treg. Legg til en syntetisk eller planlagt kontroll som prøver å sikkerhetskopiere en testkatalog til det valgte målet, slette en kildefil og gjenopprette den til en ren alternativ sti ved hjelp av ufarlige testdata.

Før en oppgradering må du ta høyde for denne applikasjonsspesifikke risikoen: Endringer i Duplicatis konfigurasjonsdatabase og backupformat bør testes uten å skrive om det eneste eksterne backupsettet. Gjenopprett en nylig sikkerhetskopi til en isolert deployment, kjør migreringer der og sammenlign oppførselen. Hvis containeren ser en tom sti fordi kildene på verten ble montert et annet sted, må du undersøke den aktuelle grensen — offentlig origin, lagring eller avhengighet — før du endrer irrelevante innstillinger.

Dette må være godkjent før ekte Duplicati-data tas i bruk

Release-dokumentasjonen for Duplicati trenger fakta, ikke «ser bra ut». Lagre den valgte image-digesten, konfigurasjonens checksum, det offentlige vertsnavnet og et tidsstemplet resultat for følgende: sikkerhetskopier en testkatalog til det valgte målet, slett en kildefil og gjenopprett den til en ren alternativ sti. Bruk eksempeldata uten produksjonsinnhold, slik at kontrollen kan kjøres etter hver deployment.

Bevis to livssyklushendelser separat. En containerutskifting må bevare normal drift. En ren recovery må vise at en ny Duplicati-instans kan importere konfigurasjonen og gjenopprette utvalgte filer med verifiserte hasher. Mens kontrollene kjører, måler du antall kildefiler, komprimering, kryptering, forsinkelse til målet og overlapp mellom planlagte jobber, og tar vare på resultatet som forventet rammeverk for denne versjonen.

Test også en avvist eller ugyldig tilstand: Fjern midlertidig testidentitetens tilgang til skrivebeskyttede kildemonteringer samt tilgjengelig lagring for sikkerhetskopimålet. Duplicati skal feile på en måte som kan diagnostiseres, og skal ikke overskrive en fungerende state. Gjenopprett den gyldige tilstanden, kjør eksempelet på nytt og legg ved relevante, redigerte logger. Disse artefaktene gir et fremtidig rollback-valg konkret dokumentasjon.

Gjør den lokale kommandoen til en tjeneste som kan inspiseres

Følgende kommando synliggjør containergrensen uten å late som om den setter opp alle eksterne tjenester.

docker run -d \
  --name duplicati \
  --restart unless-stopped \
  -p 127.0.0.1:8200:8200 \
  -v duplicati-data:/config \
  -v /srv/data:/source:ro \
  -e SETTINGS_ENCRYPTION_KEY=replace-with-a-long-random-value \
  lscr.io/linuxserver/duplicati:latest

Før du åpner ingress, må du inspisere det løste miljøet, monteringer og listeneren. Legg til de gjennomgåtte tilkoblingsinnstillingene for skrivebeskyttede kildemonteringer samt tilgjengelig lagring for sikkerhetskopimålet, og bruk private navn for private tjenester. En vellykket oppstart er fullført når du kan sikkerhetskopiere en testkatalog til det valgte målet, slette en kildefil og gjenopprette den til en ren alternativ sti — ikke når docker ps skriver ut Up.

Gjør Duplicati-recovery målbar

Dokumenter state før den første reelle posten opprettes: Duplicatis konfigurasjonsdatabase og separat verifiserte backupsett. Monter /config før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at stien faktisk er persistent. Bekreft monteringen ved å skrive ufarlige data, erstatte Duplicati og lese dataene tilbake.

Snapshots er nyttige for rask rollback, men du trenger en uavhengig sikkerhetskopi hvis verten eller volumet forsvinner. Gjenopprett til et tomt miljø med det pinnede imaget, og bekreft at en ny Duplicati-instans kan importere konfigurasjonen og gjenopprette utvalgte filer med verifiserte hasher. Bruk persistent volumes og snapshots for å holde disse to recovery-mekanismene adskilt.

TLS er enkelt; genererte URL-er er ikke det

Eksponer ett HTTPS-vertsnavn for Duplicati, og hold råport 8200 privat. Hold administrasjonsgrensesnittet privat eller sterkt autentisert bak HTTPS. Dette hindrer nettlesere og API-klienter i å lære to konkurrerende adresser.

Kjør den kjente, fungerende transaksjonen fra en ren klient, og inspiser den første forespørselen som feiler. Bruk veiledningen for egendefinert domene når DNS eller TLS er feil. Behandle «containeren ser en tom sti fordi kildene på verten ble montert et annet sted» som en separat applikasjonsdiagnose når ruten er bekreftet.

Sikre Duplicati etter bootstrap

Bootstrap-credentials er midlertidige; tillitsmodellen er permanent. Med Duplicati må du passe på å ikke montere backupkilder med skriveadgang eller miste krypteringspassfrasen. Monter kildene skrivebeskyttet, hold administrasjonsgrensesnittet privat og lagre backup-passfrasen utenfor serveren.

Generer SETTINGS_ENCRYPTION_KEY én gang, hold den utenfor Git og bevar den sammen med recovery-manifestet, fordi en endring kan gjøre kryptert eller signert applikasjonsstate ugyldig. Kjør imaget uten unødvendige Linux capabilities, og eksponer bare den offentlige applikasjonsruten. Sørg for at administratoraktivitet er synlig uten å logge hemmelige verdier.

Bruk Dockup for plattformlaget

For Duplicati kan Dockup opprette ruten og TLS-sertifikatet, bevare monteringer, levere secrets og plassere skrivebeskyttede kildemonteringer samt tilgjengelig lagring for sikkerhetskopimålet på privat nettverk, samtidig som deployment kan gjøres til enten Dockup eller tilkoblede servere.

Release-gaten er fortsatt den konkrete Duplicati-transaksjonen: sikkerhetskopier en testkatalog til det valgte målet, slett en kildefil og gjenopprett den til en ren alternativ sti. Bekreft også recovery-tilstanden — at en ny Duplicati-instans kan importere konfigurasjonen og gjenopprette utvalgte filer med verifiserte hasher. Disse to kontrollene viser om deploymenten fungerer, og om den kan gjenopprettes.

Ofte stilte spørsmål

Hva trenger Duplicati for en deployment i produksjon?

Rout Duplicati-containeren på port 8200 gjennom én HTTPS-origin. Det støttende nettverkskravet er skrivebeskyttede kildemonteringer samt tilgjengelig lagring for sikkerhetskopimålet. Ikke erklær Duplicati klar før du kan sikkerhetskopiere en testkatalog til det valgte målet, slette en kildefil og gjenopprette den til en ren alternativ sti.

Hvilke Duplicati-data hører hjemme i en sikkerhetskopi?

Gjør /config persistent, og ta med Duplicatis konfigurasjonsdatabase og separat verifiserte backupsett i det samme recovery-manifestet. En ren Duplicati-gjenoppretting er bare godkjent når en ny Duplicati-instans kan importere konfigurasjonen og gjenopprette utvalgte filer med verifiserte hasher.

Krever Duplicati HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Duplicati-origin, og hold port 8200 på den interne ruten. Bruk Duplicati-innstillingen riktig: Hold administrasjonsgrensesnittet privat eller sterkt autentisert bak HTTPS. For Duplicati beskytter HTTPS credentials eller brukerinnhold under transport og sørger for konsekvent klientoppførsel som er avhengig av origin.

Hvordan bør en Duplicati-oppgradering testes?

Gjenopprett gjeldende Duplicati-state til en isolert deployment, installer kandidatversjonen og gjenta godkjenningstransaksjonen. Vær spesielt oppmerksom på at endringer i Duplicatis konfigurasjonsdatabase og backupformat bør testes uten å skrive om det eneste eksterne backupsettet. Behold det forrige Duplicati-imaget til grensen for datamigrering og rollback er forstått.