Duplicati 2026 selbst hosten: Verschlüsselte Backups, Mounts und Restore-Tests

Wenn du bereits versucht hast, Duplicati selbst zu hosten, kennst du diesen frustrierenden Zustand wahrscheinlich: Die UI ist erreichbar, aber der Container sieht einen leeren Pfad, weil die Quellen des Hosts an anderer Stelle gemountet wurden. Den Container neu zu erstellen, behebt nur selten eine Inkonsistenz zwischen URLs, State und Dependencies.

Dieser Leitfaden verwendet ein konkretes Abnahmekriterium: Ein Testverzeichnis wird am ausgewählten Ziel gesichert, eine Quelldatei gelöscht und in einen sauberen alternativen Pfad wiederhergestellt. Jede Konfigurationsentscheidung wird an diesem Kriterium gemessen und nicht an einem grünen Container-Badge.

Ports, Prozesse und private Services

Ein nützliches Duplicati-Diagramm zeigt die öffentliche Route, den privaten Port 8200, die State-Grenze und alle unterstützenden Anforderungen. Markiere, welche Pfeile Credentials übertragen und welche normalen Benutzertraffic darstellen. Der Network Contract für Duplicati besteht aus Read-only-Source-Mounts sowie erreichbarem Storage für das Backup-Ziel. Halte private Endpoints im internen DNS, erlaube nur erforderliche Outbound-Calls und gib Duplicati ein Service-Credential mit begrenztem Scope.

Beweise das Diagramm mit einer echten Aktion: Sichere ein Testverzeichnis am ausgewählten Ziel, lösche eine Quelldatei und stelle sie in einem sauberen alternativen Pfad wieder her. Die wahrscheinliche Belastung entsteht durch die Anzahl der Quelldateien, Kompression, Verschlüsselung, die Latenz des Ziels und Überschneidungen zwischen geplanten Jobs. Überwache daher diesen Pfad, statt alle HTTP-Requests als gleichwertig zu behandeln.

Einen gesund aussehenden Duplicati-Betrieb diagnostizieren

Baue Dashboards für die Anzahl der Quelldateien, Kompression, Verschlüsselung, die Latenz des Ziels und Überschneidungen zwischen geplanten Jobs. Ein CPU-Graph ohne diesen Workload-Kontext kann nicht erklären, warum Duplicati langsam ist. Ergänze einen synthetischen oder geplanten Check, der versucht, ein Testverzeichnis am ausgewählten Ziel zu sichern, eine Quelldatei zu löschen und sie mithilfe harmloser Testdaten in einem sauberen alternativen Pfad wiederherzustellen.

Berücksichtige vor einem Upgrade dieses anwendungsspezifische Risiko: Änderungen an Duplicatis Konfigurationsdatenbank und Backup-Format sollten getestet werden, ohne den einzigen Remote-Backup-Satz neu zu schreiben. Stelle ein aktuelles Backup in einer isolierten Umgebung wieder her, führe dort die Migrationen aus und vergleiche das Verhalten. Wenn der Container einen leeren Pfad sieht, weil die Quellen des Hosts an anderer Stelle gemountet wurden, überprüfe zuerst die betroffene Grenze — Public Origin, Storage oder Dependency — bevor du andere Einstellungen änderst.

Was vor dem Eintreffen echter Duplicati-Daten erfolgreich sein muss

Der Release-Nachweis für Duplicati braucht Fakten, kein „sieht gut aus“. Speichere den ausgewählten Image-Digest, den Configuration-Checksum, den öffentlichen Hostnamen und ein Ergebnis mit Zeitstempel für Folgendes: Ein Testverzeichnis wird am ausgewählten Ziel gesichert, eine Quelldatei gelöscht und in einem sauberen alternativen Pfad wiederhergestellt. Verwende nicht produktive Beispieldaten, damit der Check nach jedem Deployment ausgeführt werden kann.

Beweise zwei Lifecycle-Events separat. Das Ersetzen eines Containers muss den normalen Betrieb erhalten; eine saubere Recovery muss zeigen, dass eine frische Duplicati-Instanz die Konfiguration importieren und ausgewählte Dateien mit verifizierten Hashes wiederherstellen kann. Während die Checks laufen, misst du die Anzahl der Quelldateien, Kompression, Verschlüsselung, die Latenz des Ziels und Überschneidungen zwischen geplanten Jobs und speicherst das Ergebnis als erwarteten Rahmen für diese Version.

Teste außerdem eine verweigerte oder ungültige Bedingung: Entziehe der Test-Identity vorübergehend den Zugriff auf Read-only-Source-Mounts sowie den erreichbaren Storage für das Backup-Ziel. Duplicati sollte auf nachvollziehbare Weise fehlschlagen und keinen intakten State überschreiben. Stelle die gültige Bedingung wieder her, führe den Test erneut aus und hänge die relevanten bereinigten Logs an. Diese Artefakte liefern einer künftigen Rollback-Entscheidung konkrete Belege.

Den lokalen Befehl in einen inspizierbaren Service verwandeln

Der folgende Befehl macht die Container-Grenze sichtbar, ohne vorzugeben, jeden externen Service bereitzustellen.

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

Bevor du Ingress öffnest, prüfe die aufgelöste Umgebung, Mounts und den Listener. Ergänze die geprüften Connection-Settings für Read-only-Source-Mounts sowie erreichbaren Storage für das Backup-Ziel und verwende private Namen für private Services. Ein erfolgreicher Launch ist erreicht, wenn du ein Testverzeichnis am ausgewählten Ziel sichern, eine Quelldatei löschen und sie in einem sauberen alternativen Pfad wiederherstellen kannst — nicht wenn docker ps Up ausgibt.

Duplicati-Recovery messbar machen

Dokumentiere den State, bevor der erste echte Datensatz erstellt wird: die Duplicati-Konfigurationsdatenbank und separat verifizierte Backup-Sätze. Mounte /config vor dem Bootstrap, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Bestätige den Mount, indem du harmlose Daten schreibst, Duplicati ersetzt und die Daten wieder ausliest.

Snapshots sind für schnelles Rollback wertvoll, aber sobald der Host oder das Volume verschwindet, wird ein unabhängiges Backup benötigt. Stelle die Daten in einer leeren Umgebung mit dem gepinnten Image wieder her und verifiziere, dass eine frische Duplicati-Instanz die Konfiguration importieren und ausgewählte Dateien mit verifizierten Hashes wiederherstellen kann. Verwende persistente Volumes und Snapshots, um diese beiden Recovery-Mechanismen getrennt zu halten.

TLS ist einfach – generierte URLs sind es nicht

Stelle für Duplicati einen HTTPS-Hostnamen bereit und halte den direkten Port 8200 privat. Halte die Management-UI privat oder schütze sie hinter HTTPS durch starke Authentifizierung. So verhinderst du, dass Browser und API-Clients zwei konkurrierende Adressen kennenlernen.

Führe von einem sauberen Client aus die bekannte funktionierende Transaktion durch und prüfe den ersten fehlschlagenden Request. Verwende den Leitfaden für Custom Domains, wenn DNS oder TLS fehlerhaft sind. Behandle „der Container sieht einen leeren Pfad, weil die Quellen des Hosts an anderer Stelle gemountet wurden“ als separate Anwendungsdiagnose, sobald die Route bewiesen ist.

Duplicati nach dem Bootstrap absichern

Bootstrap-Credentials sind temporär, das Trust Model bleibt dauerhaft bestehen. Achte bei Duplicati darauf, Backup-Quellen nicht mit Schreibzugriff zu mounten und die Passphrase für die Verschlüsselung nicht zu verlieren. Mounte Quellen Read-only, halte die Management-UI privat und speichere die Backup-Passphrase außerhalb des Servers.

Generiere SETTINGS_ENCRYPTION_KEY einmalig, halte den Wert aus Git heraus und bewahre ihn zusammen mit dem Recovery-Manifest auf, da eine Änderung verschlüsselten oder signierten Application-State unbrauchbar machen kann. Starte das Image ohne unnötige Linux-Capabilities und exponiere nur die öffentliche Application-Route. Mache Administratoraktivitäten nachvollziehbar, ohne Secret-Werte zu protokollieren.

Dockup für die Platform Layer verwenden

Für Duplicati kann Dockup die Route und das TLS-Zertifikat erstellen, Mounts erhalten, Secrets bereitstellen und Read-only-Source-Mounts sowie erreichbaren Storage für das Backup-Ziel in einem privaten Netzwerk platzieren — unabhängig davon, ob das Deployment auf Dockup oder verbundenen Servern erfolgt.

Das Release-Gate bleibt die konkrete Duplicati-Transaktion: Ein Testverzeichnis wird am ausgewählten Ziel gesichert, eine Quelldatei gelöscht und in einem sauberen alternativen Pfad wiederhergestellt. Überprüfe außerdem die Restore-Bedingung: Eine frische Duplicati-Instanz kann die Konfiguration importieren und ausgewählte Dateien mit verifizierten Hashes wiederherstellen. Diese beiden Checks zeigen, ob das Deployment funktioniert und ob es wiederhergestellt werden kann.

Häufig gestellte Fragen

Was benötigt Duplicati für ein Production-Deployment?

Führe den Duplicati-Container über eine HTTPS-Origin auf Port 8200. Die unterstützende Network-Anforderung besteht aus Read-only-Source-Mounts sowie erreichbarem Storage für das Backup-Ziel. Erkläre Duplicati erst dann für bereit, wenn du ein Testverzeichnis am ausgewählten Ziel sichern, eine Quelldatei löschen und sie in einem sauberen alternativen Pfad wiederherstellen kannst.

Welche Duplicati-Daten gehören in ein Backup?

Mache /config persistent und nimm die Duplicati-Konfigurationsdatenbank sowie separat verifizierte Backup-Sätze in dasselbe Recovery-Manifest auf. Ein sauberes Duplicati-Restore ist erst dann erfolgreich, wenn eine frische Duplicati-Instanz die Konfiguration importieren und ausgewählte Dateien mit verifizierten Hashes wiederherstellen kann.

Benötigt Duplicati hinter einem Reverse Proxy HTTPS?

Verwende HTTPS für die öffentliche Duplicati-Origin und halte Port 8200 auf der internen Route. Setze die Duplicati-Einstellung korrekt: Halte die Management-UI privat oder schütze sie hinter HTTPS durch starke Authentifizierung. Bei Duplicati schützt HTTPS Credentials oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, von der Origin abhängiges Client-Verhalten.

Wie sollte ein Duplicati-Upgrade getestet werden?

Stelle den aktuellen Duplicati-State in einer isolierten Umgebung wieder her, wende die neue Version an und wiederhole die Acceptance-Transaktion. Gehe dabei besonders sorgfältig vor, da Änderungen an Duplicatis Konfigurationsdatenbank und Backup-Format getestet werden sollten, ohne den einzigen Remote-Backup-Satz neu zu schreiben. Behalte das vorherige Duplicati-Image, bis die Grenzen für Datenmigration und Rollback verstanden sind.