Sådan self-hoster du Duplicati i 2026: Krypterede backups, mounts og gendannelsestests

Hvis du allerede har prøvet at self-hoste Duplicati, kender du sikkert den frustrerende situation: Brugerfladen vises, men containeren ser en tom sti, fordi kildedata fra hosten blev mountet et andet sted. Det løser sjældent problemet at oprette containeren igen, hvis der er uoverensstemmelse mellem URLs, tilstand og afhængigheder.

Denne gennemgang bruger ét konkret kriterium for, hvornår opsætningen er færdig — tag backup af en testmappe til den valgte destination, slet en kildefil, og gendan den til en ren alternativ sti. Hvert konfigurationsvalg vurderes ud fra dette kriterium i stedet for ud fra et grønt container-badge.

Porte, processer og private services

Et nyttigt Duplicati-diagram viser den offentlige route, den private port 8200, grænsen for tilstand og alle understøttende krav. Markér, hvilke pile der indeholder credentials, og hvilke der er almindelig brugertrafik. Netværkskontrakten for Duplicati består af read-only source mounts samt tilgængelig storage til backupdestinationen. Hold private endpoints på intern DNS, tillad kun nødvendige udgående kald, og giv Duplicati en afgrænset service credential.

Bevis diagrammet med én reel handling: Tag backup af en testmappe til den valgte destination, slet en kildefil, og gendan den til en ren alternativ sti. Belastningen kommer sandsynligvis fra antallet af kildefiler, compression, encryption, destinationens latency og overlap mellem planlagte jobs; overvåg denne sti i stedet for at behandle alle HTTP-requests ens.

Sådan diagnosticerer du en Duplicati, der ser sund ud

Byg dashboards omkring antallet af kildefiler, compression, encryption, destinationens latency og overlap mellem planlagte jobs. En CPU-graf uden denne workload-kontekst kan ikke forklare, hvorfor Duplicati er langsom. Tilføj et syntetisk eller planlagt check, der forsøger at tage backup af en testmappe til den valgte destination, slette en kildefil og gendanne den til en ren alternativ sti ved hjælp af ufarlige testdata.

Før en opgradering skal du tage højde for denne applikationsspecifikke risiko: Ændringer i Duplicatis konfigurationsdatabase og backupformat skal testes uden at omskrive det eneste remote backup set. Gendan en nylig backup i en isoleret deployment, kør migrations dér, og sammenlign opførslen. Hvis containeren ser en tom sti, fordi kildefiler fra hosten blev mountet et andet sted, skal du undersøge den relevante grænse — public origin, storage eller dependency — før du ændrer uvedkommende indstillinger.

Dette skal være godkendt, før rigtige Duplicati-data ankommer

Release-registreringen for Duplicati skal indeholde fakta, ikke “ser fint ud”. Gem den valgte image digest, konfigurations-checksum, offentlige hostname og et tidsstemplet resultat for: Tag backup af en testmappe til den valgte destination, slet en kildefil, og gendan den til en ren alternativ sti. Brug ikke-produktionsdata, så kontrollen kan køres efter hver deployment.

Bevis to lifecycle-hændelser separat. En udskiftning af containeren skal bevare normal drift; en ren recovery skal vise, at en frisk Duplicati-instans kan importere konfigurationen og gendanne udvalgte filer med verificerede hashes. Mens kontrollen kører, skal du måle antallet af kildefiler, compression, encryption, destinationens latency og overlap mellem planlagte jobs og gemme resultatet som den forventede ramme for denne version.

Test også en afvist eller ugyldig situation: Fjern midlertidigt testidentitetens adgang til read-only source mounts samt tilgængelig storage til backupdestinationen. Duplicati skal fejle på en måde, der kan diagnosticeres, og må ikke overskrive en sund tilstand. Genskab den gyldige situation, kør testen igen, og vedhæft de relevante redigerede logs. Disse artefakter giver en fremtidig rollback-beslutning et konkret grundlag.

Gør den lokale kommando til en service, der kan inspiceres

Følgende kommando synliggør containergrænsen uden at foregive, at alle eksterne services bliver provisioneret.

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 åbner for ingress, skal du inspicere det resolvede miljø, mounts og listeneren. Tilføj de gennemgåede forbindelsesindstillinger for read-only source mounts samt tilgængelig storage til backupdestinationen, og brug private navne til private services. En vellykket opstart er først afsluttet, når du kan tage backup af en testmappe til den valgte destination, slette en kildefil og gendanne den til en ren alternativ sti — ikke når docker ps viser Up.

Gør Duplicati-recovery målbar

Oplist tilstanden, før den første rigtige record oprettes: Duplicatis konfigurationsdatabase og separat verificerede backup sets. Mount /config før bootstrap, skriv ufarlige eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Bekræft mountet ved at skrive ufarlige data, udskifte Duplicati og læse dataene tilbage.

Snapshots er værdifulde til hurtig rollback, men der er brug for en uafhængig backup, hvis hosten eller volumen forsvinder. Gendan i et tomt miljø med det pinnede image, og verificér, at en frisk Duplicati-instans kan importere konfigurationen og gendanne udvalgte filer med verificerede hashes. Brug persistent volumes and snapshots til at holde de to recovery-mekanismer adskilt.

TLS er nemt; genererede URLs er ikke

Eksponér ét HTTPS-hostname for Duplicati, og hold den rå port 8200 privat. Hold management-UI'et privat, eller beskyt det med stærk authentication bag HTTPS. Det forhindrer browsere og API-klienter i at opdage to konkurrerende adresser.

Kør den kendte gode transaktion fra en ren client, og inspicér den første request, der fejler. Brug guiden til custom domains, når DNS eller TLS er forkert. Behandl “containeren ser en tom sti, fordi kildefiler fra hosten blev mountet et andet sted” som en separat applikationsdiagnose, når routen er verificeret.

Lås Duplicati ned efter bootstrap

Bootstrap-credentials er midlertidige; trust-modellen er permanent. Med Duplicati skal du være opmærksom på mounts af backupkilder med read-write-adgang og på risikoen for at miste encryption passphrase. Mount kilder read-only, hold management-UI'et privat, og gem backup-passphrasen uden for serveren.

Generér SETTINGS_ENCRYPTION_KEY én gang, hold den ude af Git, og bevar den sammen med recovery-manifestet, fordi en ændring kan ugyldiggøre krypteret eller signeret applikationstilstand. Kør imaget uden unødvendige Linux capabilities, og eksponér kun den offentlige application route. Sørg for, at administratoraktivitet er synlig, uden at secret-værdier registreres.

Brug Dockup til platformlaget

For Duplicati kan Dockup oprette routen og TLS-certifikatet, bevare mounts, levere secrets og placere read-only source mounts samt tilgængelig storage til backupdestinationen på et privat netværk, mens deployment kan ske enten på Dockup eller på tilknyttede servere.

Release-gaten er stadig den konkrete Duplicati-transaktion: Tag backup af en testmappe til den valgte destination, slet en kildefil, og gendan den til en ren alternativ sti. Verificér også recovery-betingelsen — at en frisk Duplicati-instans kan importere konfigurationen og gendanne udvalgte filer med verificerede hashes. De to kontroller viser, om deployment fungerer, og om den kan gendannes.

Ofte stillede spørgsmål

Hvad skal Duplicati bruge til en produktionsdeployment?

Route Duplicati-containeren på port 8200 gennem én HTTPS-origin. Det understøttende netværkskrav er read-only source mounts samt tilgængelig storage til backupdestinationen. Erklær ikke Duplicati klar, før du kan tage backup af en testmappe til den valgte destination, slette en kildefil og gendanne den til en ren alternativ sti.

Hvilke Duplicati-data skal indgå i en backup?

Gør /config persistent, og inkludér Duplicatis konfigurationsdatabase samt separat verificerede backup sets i det samme recovery-manifest. En ren Duplicati-restore er kun godkendt, når en frisk Duplicati-instans kan importere konfigurationen og gendanne udvalgte filer med verificerede hashes.

Kræver Duplicati HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Duplicati-origin, og hold port 8200 på den interne route. Anvend Duplicati-indstillingen korrekt: Hold management-UI'et privat, eller beskyt det med stærk authentication bag HTTPS. For Duplicati beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet client-adfærd, der afhænger af origin.

Hvordan skal en Duplicati-opgradering testes?

Gendan den aktuelle Duplicati-tilstand i en isoleret deployment, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi ændringer i Duplicatis konfigurationsdatabase og backupformat skal testes uden at omskrive det eneste remote backup set. Behold det tidligere Duplicati-image, indtil dets data-migration og rollback-grænse er forstået.