Så self-hostar du Duplicati 2026: Krypterade backuper, mounts och återställningstester

Om du redan har försökt self-hosta Duplicati känner du förmodligen igen det frustrerande läget: gränssnittet visas, men containern ser en tom sökväg eftersom källorna på hosten monterades någon annanstans. Att skapa om containern löser sällan en konflikt mellan URL:er, state och dependencies.

I den här genomgången använder vi ett konkret mål för att verifiera att allt fungerar: säkerhetskopiera en testkatalog till den valda destinationen, ta bort en källfil och återställa den till en ren alternativ sökväg. Varje konfigurationsval utvärderas mot detta mål, inte mot en grön containerstatus.

Portar, processer och privata tjänster

Ett användbart Duplicati-diagram visar den publika routen, den privata porten 8200, state-gränsen och alla stödjande krav. Markera vilka pilar som transporterar credentials och vilka som är vanlig användartrafik. Nätverkskontraktet för Duplicati består av read-only source mounts samt nåbar storage för backupdestinationen. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Duplicati en service credential med begränsad åtkomst.

Verifiera diagrammet med en verklig åtgärd: säkerhetskopiera en testkatalog till den valda destinationen, ta bort en källfil och återställa den till en ren alternativ sökväg. Den största belastningen kommer sannolikt från antalet källfiler, komprimering, kryptering, destinationens latency och överlappningen mellan schemalagda jobb. Övervaka därför den här sökvägen i stället för att behandla alla HTTP-anrop som likvärdiga.

Diagnostisera en Duplicati-installation som ser frisk ut

Bygg dashboards kring antalet källfiler, komprimering, kryptering, destinationens latency och överlappningen mellan schemalagda jobb. En CPU-graf utan det här workload-sammanhanget kan inte förklara varför Duplicati är långsamt. Lägg till en syntetisk eller schemalagd kontroll som försöker säkerhetskopiera en testkatalog till den valda destinationen, ta bort en källfil och återställa den till en ren alternativ sökväg med ofarliga testdata.

Inför en uppgradering måste du ta hänsyn till följande programspecifika risk: ändringar i Duplicatis konfigurationsdatabas och backupformat ska testas utan att skriva om den enda backupuppsättningen på fjärrdestinationen. Återställ en aktuell backup till en isolerad deployment, kör migreringarna där och jämför beteendet. Om containern ser en tom sökväg eftersom källorna på hosten monterades någon annanstans, ska du inspektera den berörda gränsen – publik origin, storage eller dependency – innan du ändrar orelaterade inställningar.

Detta måste fungera innan riktiga Duplicati-data används

Release-dokumentationen för Duplicati behöver fakta, inte ett “ser bra ut”. Spara vald image digest, konfigurationschecksumma, publikt hostname och ett tidsstämplat resultat för följande: säkerhetskopiera en testkatalog till den valda destinationen, ta bort en källfil och återställa den till en ren alternativ sökväg. Använd icke-produktionsdata så att kontrollen kan köras efter varje deployment.

Verifiera två lifecycle-händelser separat. Ett containerbyte måste bevara normal drift; en ren recovery måste visa att en ny Duplicati-instans kan importera konfigurationen och återställa valda filer med verifierade hashvärden. Medan kontrollerna körs mäter du antalet källfiler, komprimering, kryptering, destinationens latency och överlappningen mellan schemalagda jobb. Spara resultatet som det förväntade intervallet för den här versionen.

Testa även ett nekande eller ogiltigt tillstånd: neka tillfälligt testidentiteten åtkomst till read-only source mounts samt nåbar storage för backupdestinationen. Duplicati ska misslyckas på ett sätt som går att diagnostisera och får inte skriva över fungerande state. Återställ det giltiga tillståndet, kör testet igen och bifoga relevanta redigerade loggar. Dessa artefakter ger framtida beslut om rollback konkreta bevis.

Gör det lokala kommandot till en tjänst som går att inspektera

Följande kommando synliggör containergränsen utan att låtsas provisionera alla externa tjänster.

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

Innan du öppnar ingressen ska du inspektera den upplösta miljön, mounts och listenern. Lägg till de granskade anslutningsinställningarna för read-only source mounts samt nåbar storage för backupdestinationen. Använd privata namn för privata tjänster. En lyckad start är klar först när du kan säkerhetskopiera en testkatalog till den valda destinationen, ta bort en källfil och återställa den till en ren alternativ sökväg – inte när docker ps skriver ut Up.

Gör Duplicati-recovery mätbar

Dokumentera state innan den första riktiga posten skapas: Duplicatis konfigurationsdatabas och separat verifierade backupuppsättningar. Montera /config före bootstrap, skriv ofarliga testdata och byt ut containern för att bevisa att sökvägen faktiskt är persistent. Bekräfta mounten genom att skriva ofarliga data, byta ut Duplicati och läsa tillbaka dem.

Snapshots är värdefulla för snabb rollback, men en oberoende backup behövs om hosten eller volymen försvinner. Återställ till en tom miljö med den pinnade imagen och verifiera att en ny Duplicati-instans kan importera konfigurationen och återställa valda filer med verifierade hashvärden. Använd persistent volumes and snapshots för att hålla de två recovery-mekanismerna åtskilda.

TLS är enkelt – genererade URL:er är det inte

Exponera ett HTTPS-hostname för Duplicati och håll den råa porten 8200 privat. Håll administrationsgränssnittet privat eller skydda det med stark autentisering bakom HTTPS. På så sätt hindrar du webbläsare och API-klienter från att lära sig två konkurrerande adresser.

Kör den kända fungerande transaktionen från en ren klient och inspektera det första anropet som misslyckas. Använd custom-domain guide när DNS eller TLS är felkonfigurerat. Behandla “containern ser en tom sökväg eftersom källorna på hosten monterades någon annanstans” som en separat applikationsdiagnos när routen väl är verifierad.

Lås ner Duplicati efter bootstrap

Bootstrap-credentials är tillfälliga; trust-modellen är permanent. Var uppmärksam på att backupkällor kan monteras med skrivåtkomst eller att krypteringslösenfrasen kan försvinna. Montera källor read-only, håll administrationsgränssnittet privat och lagra backupens lösenfras utanför servern.

Generera SETTINGS_ENCRYPTION_KEY en gång, håll den utanför Git och bevara den tillsammans med recovery-manifestet eftersom ett byte kan ogiltigförklara krypterad eller signerad applikations-state. Kör imagen utan onödiga Linux capabilities och exponera endast den publika application-routen. Gör administratörsaktivitet synlig utan att logga hemliga värden.

Använd Dockup för plattformslagret

För Duplicati kan Dockup skapa routen och TLS-certifikatet, bevara mounts, leverera secrets och placera read-only source mounts samt nåbar storage för backupdestinationen på ett privat nätverk vid deployment till antingen Dockup eller anslutna servrar.

Release-gaten är fortfarande den konkreta Duplicati-transaktionen: säkerhetskopiera en testkatalog till den valda destinationen, ta bort en källfil och återställa den till en ren alternativ sökväg. Verifiera även restore-villkoret – att en ny Duplicati-instans kan importera konfigurationen och återställa valda filer med verifierade hashvärden. De två kontrollerna visar om deploymenten fungerar och om den går att återställa.

Vanliga frågor

Vad behöver Duplicati för en produktionsdeployment?

Routa Duplicati-containern via port 8200 genom en enda HTTPS-origin. Det stödjande nätverkskravet är read-only source mounts samt nåbar storage för backupdestinationen. Markera inte Duplicati som redo förrän du kan säkerhetskopiera en testkatalog till den valda destinationen, ta bort en källfil och återställa den till en ren alternativ sökväg.

Vilka Duplicati-data ska ingå i en backup?

Gör /config persistent och inkludera Duplicatis konfigurationsdatabas samt separat verifierade backupuppsättningar i samma recovery-manifest. En ren Duplicati-restore är godkänd först när en ny Duplicati-instans kan importera konfigurationen och återställa valda filer med verifierade hashvärden.

Kräver Duplicati HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Duplicati-originen och håll port 8200 på den interna routen. Tillämpa Duplicati-inställningen korrekt: håll administrationsgränssnittet privat eller skydda det med stark autentisering bakom HTTPS. För Duplicati skyddar HTTPS credentials eller användarinnehåll under transport och håller origin-känsligt klientbeteende konsekvent.

Hur ska en Duplicati-uppgradering testas?

Återställ aktuell Duplicati-state till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptance-transaktion. Var särskilt uppmärksam eftersom ändringar i Duplicatis konfigurationsdatabas och backupformat ska testas utan att skriva om den enda backupuppsättningen på fjärrdestinationen. Behåll den tidigare Duplicati-imagen tills datamigreringens och rollbackens gränser är klarlagda.