Journal-indexDockup / praktijknotitie
Note / self-host-duplicati

Duplicati zelf hosten in 2026: versleutelde back-ups, mounts en hersteltests

Een praktische handleiding voor het zelf hosten van Duplicati, met aandacht voor Docker, poorten, persistente data, TLS, beveiliging, back-ups en fouten die productiegebruik in de weg staan. In 2026.

Als je al hebt geprobeerd Duplicati zelf te hosten, herken je waarschijnlijk deze frustrerende situatie: de UI verschijnt, maar de container ziet een leeg pad omdat bronnen op de host ergens anders zijn gemount. De container opnieuw aanmaken lost een verschil tussen URL's, state en dependencies zelden op.

In deze walkthrough gebruiken we één concreet criterium voor voltooiing: maak een back-up van een testdirectory naar de gekozen bestemming, verwijder een bronbestand en herstel het naar een schoon alternatief pad. Elke configuratiekeuze wordt aan dat criterium getoetst, niet aan een groen containerbadge.

Poorten, processen en private services

Een bruikbaar Duplicati-diagram toont de publieke route, private poort 8200, de state-grens en alle ondersteunende vereisten. Markeer welke pijlen credentials bevatten en welke gewoon user traffic zijn. Het network contract voor Duplicati bestaat uit read-only source mounts plus bereikbare backup destination storage. Houd private endpoints op interne DNS, sta alleen noodzakelijke outbound calls toe en geef Duplicati een service credential met beperkte scope.

Bewijs het diagram met één echte actie: maak een back-up van een testdirectory naar de gekozen bestemming, verwijder een bronbestand en herstel het naar een schoon alternatief pad. De waarschijnlijke belasting komt van het aantal bronbestanden, compressie, encryptie, latency van de bestemming en overlap tussen geplande jobs; monitor dat pad in plaats van alle HTTP requests als gelijkwaardig te behandelen.

Een gezond ogende Duplicati diagnosticeren

Bouw dashboards rond het aantal bronbestanden, compressie, encryptie, latency van de bestemming en overlap tussen geplande jobs. Een CPU-grafiek zonder die workloadcontext kan niet verklaren waarom Duplicati traag is. Voeg een synthetic of scheduled check toe die probeert een back-up van een testdirectory naar de gekozen bestemming te maken, een bronbestand te verwijderen en het naar een schoon alternatief pad te herstellen met onschadelijke testdata.

Houd vóór een upgrade rekening met dit applicatiespecifieke risico: wijzigingen in Duplicati's configuratiedatabase en back-upformat moeten worden getest zonder de enige remote backup set te herschrijven. Herstel een recente back-up in een geïsoleerde deployment, voer daar de migraties uit en vergelijk het gedrag. Als de container een leeg pad ziet omdat bronnen op de host ergens anders zijn gemount, inspecteer dan eerst de betrokken grens — publieke origin, storage of dependency — voordat je andere instellingen aanpast.

Wat moet slagen voordat echte Duplicati-data arriveert

Het release record voor Duplicati moet feiten bevatten, geen “ziet er goed uit”. Sla de geselecteerde image digest, configuratiechecksum, publieke hostname en een van een timestamp voorziene uitkomst op voor: maak een back-up van een testdirectory naar de gekozen bestemming, verwijder een bronbestand en herstel het naar een schoon alternatief pad. Gebruik niet-productiedata, zodat de controle na elke deployment kan worden uitgevoerd.

Bewijs twee lifecycle-events afzonderlijk. Een containervervanging moet normale werking behouden; een clean recovery moet aantonen dat een nieuwe Duplicati-instantie de configuratie kan importeren en geselecteerde bestanden kan herstellen met geverifieerde hashes. Meet tijdens de controles het aantal bronbestanden, compressie, encryptie, latency van de bestemming en overlap tussen geplande jobs, en bewaar het resultaat als de verwachte envelope voor deze versie.

Test ook een geweigerde of ongeldige toestand: ontzeg de testidentiteit tijdelijk de toegang tot read-only source mounts plus bereikbare backup destination storage. Duplicati moet op een diagnoseerbare manier falen en mag geen gezonde state overschrijven. Herstel de geldige toestand, voer de sample opnieuw uit en voeg de relevante geredigeerde logs toe. Deze artefacts leveren concreet bewijs voor een toekomstige rollbackbeslissing.

Maak van het lokale commando een inspecteerbare service

Met het volgende commando wordt de containergrens zichtbaar, zonder te doen alsof alle externe services worden ingericht.

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

Inspecteer vóór het openen van ingress de opgeloste environment, mounts en listener. Voeg de beoordeelde connection settings toe voor read-only source mounts plus bereikbare backup destination storage; gebruik private names voor private services. Een succesvolle launch eindigt wanneer je een back-up van een testdirectory naar de gekozen bestemming kunt maken, een bronbestand kunt verwijderen en het naar een schoon alternatief pad kunt herstellen, niet wanneer docker ps Up afdrukt.

Maak Duplicati-herstel meetbaar

Leg de state vast voordat het eerste echte record wordt aangemaakt: de configuratiedatabase van Duplicati en afzonderlijk geverifieerde backup sets. Mount /config vóór de bootstrap, schrijf onschadelijke sampledata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Bevestig de mount door onschadelijke data te schrijven, Duplicati te vervangen en de data weer uit te lezen.

Snapshots zijn waardevol voor een snelle rollback, maar een onafhankelijke back-up is nodig wanneer de host of het volume verdwijnt. Herstel in een lege environment met de vastgezette image en controleer of een nieuwe Duplicati-instantie de configuratie kan importeren en geselecteerde bestanden kan herstellen met geverifieerde hashes. Gebruik persistente volumes en snapshots om deze twee herstelmechanismen gescheiden te houden.

TLS is eenvoudig; gegenereerde URL's niet

Stel één HTTPS-hostname voor Duplicati beschikbaar en houd de onbewerkte poort 8200 private. Houd de management-UI private of zorg achter HTTPS voor sterke authenticatie. Zo voorkom je dat browsers en API-clients twee concurrerende adressen leren kennen.

Voer vanaf een clean client de bekende good transaction uit en inspecteer het eerste request dat faalt. Gebruik de handleiding voor custom domains wanneer DNS of TLS niet klopt. Behandel “de container ziet een leeg pad omdat bronnen op de host ergens anders zijn gemount” als een afzonderlijke applicatiediagnose zodra de route is bewezen.

Beveilig Duplicati na de bootstrap

Bootstrapcredentials zijn tijdelijk; het trustmodel is permanent. Let bij Duplicati op het read-write mounten van backup sources en op het kwijtraken van de encryptiepassphrase. Mount sources read-only, houd de management-UI private en bewaar de back-uppassphrase buiten de server.

Genereer SETTINGS_ENCRYPTION_KEY één keer, houd deze buiten Git en bewaar hem bij het recovery manifest, omdat een wijziging ervan encrypted of signed application state ongeldig kan maken. Voer de image uit zonder onnodige Linux capabilities en stel alleen de publieke application route beschikbaar. Houd administratoractiviteit zichtbaar zonder secret values vast te leggen.

Gebruik Dockup voor de platformlaag

Voor Duplicati kan Dockup de route en het TLS-certificaat aanmaken, mounts behouden, secrets leveren en read-only source mounts plus bereikbare backup destination storage op private networking plaatsen, terwijl je deployt naar Dockup of gekoppelde servers.

De release gate blijft de concrete Duplicati-transactie: maak een back-up van een testdirectory naar de gekozen bestemming, verwijder een bronbestand en herstel het naar een schoon alternatief pad. Controleer ook de herstelconditie — een nieuwe Duplicati-instantie kan de configuratie importeren en geselecteerde bestanden herstellen met geverifieerde hashes. Deze twee controles laten zien of de deployment werkt en of deze kan worden hersteld.

Veelgestelde vragen

Wat heeft Duplicati nodig voor een productie-deployment?

Routeer de Duplicati-container op poort 8200 via één HTTPS-origin. De ondersteunende network requirement bestaat uit read-only source mounts plus bereikbare backup destination storage. Markeer Duplicati pas als klaar wanneer je een back-up van een testdirectory naar de gekozen bestemming kunt maken, een bronbestand kunt verwijderen en het naar een schoon alternatief pad kunt herstellen.

Welke Duplicati-data hoort in een back-up?

Maak /config persistent en neem de configuratiedatabase van Duplicati en afzonderlijk geverifieerde backup sets op in hetzelfde recovery manifest. Een clean Duplicati-restore slaagt pas wanneer een nieuwe Duplicati-instantie de configuratie kan importeren en geselecteerde bestanden kan herstellen met geverifieerde hashes.

Heeft Duplicati HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Duplicati-origin en houd poort 8200 op de interne route. Pas de Duplicati-instelling correct toe: houd de management-UI private of zorg achter HTTPS voor sterke authenticatie. Voor Duplicati beschermt HTTPS credentials of user content tijdens transport en zorgt het voor consistent gedrag van origin-sensitive clients.

Hoe moet een Duplicati-upgrade worden getest?

Herstel de huidige Duplicati-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptance transaction. Let hier extra op, omdat wijzigingen in Duplicati's configuratiedatabase en back-upformat moeten worden getest zonder de enige remote backup set te herschrijven. Houd de vorige Duplicati-image aan totdat de grenzen van datamigratie en rollback duidelijk zijn.