Kopia mit Docker installieren: Schnelles Cross-Platform-Backup-Tool mit Web-UI

Wer seine Daten selbst sichern will, ohne auf Dropbox, iCloud oder teure Backup-Abonnements angewiesen zu sein, findet in Kopia ein ernstzunehmendes Werkzeug: Das in Go geschriebene Open-Source-Projekt (Apache 2.0, 13.400+ GitHub-Stars) bietet clientseitige Ende-zu-Ende-Verschlüsselung mit AES-256-GCM, automatische Deduplizierung, inkrementelle Snapshots und eine vollständige Web-Oberfläche – alles im knapp 75 MB großen Docker-Image. Kopia eignet sich für Heimanwender, KMU-Admins und ambitionierte Selfhoster gleichermaßen: Es läuft auf amd64, arm64 und arm, benötigt keine externe Datenbank und unterstützt S3, Azure Blob, Backblaze B2, WebDAV, SFTP, Rclone und lokale Verzeichnisse als Backup-Ziel.

Voraussetzungen

1. Docker Engine (v24+ empfohlen) mit Docker Compose Plugin v2 auf einem Linux-Host, einer VM oder einem NAS mit Docker-Unterstützung – falls noch nicht installiert, lies zuerst Docker und Docker Compose auf Linux installieren.
2. Ausreichend Speicherplatz: config-Verzeichnis (~10 MB), cache-Verzeichnis (mehrere GB empfohlen) und das eigentliche Backup-Repository (abhängig von deiner Datenmenge).
3. Netzwerkzugang zu Port 51515 – lokal oder hinter einem Reverse Proxy.
4. Für den Produktionsbetrieb mit HTTPS: nginx, Traefik oder Caddy als Reverse Proxy – eine gute Grundlage bietet Traefik als Docker-Reverse-Proxy mit automatischem HTTPS.
5. Ein Passwort-Manager oder ein anderer sicherer Speicherort für das Repository-Passwort (KOPIA_REPOSITORY_PASSWORD) – du brauchst es für jeden Restore und jeden neuen Container.

Eckdaten auf einen Blick

Schritt 1: Projektordner und Verzeichnisstruktur anlegen

Lege einen dedizierten Ordner für Kopia an. Alle Daten – Konfiguration, Cache, Logs und das lokale Repository – landen in Unterordnern, damit du den gesamten Stack mit einem einzigen Verzeichnis sichern oder migrieren kannst.

mkdir -p /opt/kopia/{config,cache,logs,repository,export}
cd /opt/kopia

Wer die Quelldaten (z. B. ein NAS-Freigabeverzeichnis oder ein gemountetes Laufwerk) einbinden will, stellt sicher, dass der Pfad auf dem Host existiert und lesbar ist. In der compose.yaml wird er als read-only eingehängt.

Verifizieren: Mit ls /opt/kopia solltest du die Unterverzeichnisse cache, config, export, logs und repository sehen. Sind sie vorhanden, passt die Basis.

Schritt 2: .env-Datei mit Secrets anlegen

Die .env-Datei enthält alle sensiblen Zugangsdaten. Sie liegt neben der compose.yaml und wird von Docker Compose automatisch eingelesen. Lege sie mit einem Texteditor an:

# /opt/kopia/.env
# Repository-Verschlüsselungspasswort – NICHT verlieren, NICHT ändern!
KOPIA_REPOSITORY_PASSWORD=sicheres-repo-passwort-hier

# Web-UI-Login (--server-username / --server-password)
KOPIA_UI_USER=admin
KOPIA_UI_PASSWORD=sicheres-ui-passwort-hier

# Port, Zeitzone, Backup-Quelle und Repository-Ziel
KOPIA_PORT=51515
TZ=Europe/Berlin
BACKUP_SOURCE=/mnt/data
BACKUP_REPO=./repository

Schränke die Dateiberechtigungen sofort ein, damit andere Systembenutzer das Passwort nicht lesen können:

chmod 600 /opt/kopia/.env

Wichtig: Das KOPIA_REPOSITORY_PASSWORD wird beim ersten Start zur Initialisierung des Repositories verwendet. Es kann danach nicht geändert werden, ohne Zugriff auf die Daten zu verlieren. Speichere es sofort in einem Passwort-Manager – eine gute selbst gehostete Option beschreibt Vaultwarden produktiv betreiben.

Verifizieren: ls -la /opt/kopia/.env zeigt Berechtigungen -rw-------. Mit grep KOPIA_REPOSITORY_PASSWORD /opt/kopia/.env prüfst du, ob der Wert gesetzt ist (Ausgabe darf kein leeres Gleichheitszeichen zeigen).

Schritt 3: compose.yaml erstellen

Erstelle die Datei /opt/kopia/compose.yaml mit folgendem Inhalt. Der command-Abschnitt ist zwingend erforderlich, um Kopia im Server-Modus mit Web-UI zu starten – ohne ihn würde der Container ohne Netzwerkzugang starten.

services:
  kopia:
    image: kopia/kopia:latest
    container_name: kopia
    hostname: kopia
    restart: unless-stopped
    ports:
      - "${KOPIA_PORT:-51515}:51515"
    environment:
      - KOPIA_PASSWORD=${KOPIA_REPOSITORY_PASSWORD}
      - TZ=${TZ:-Europe/Berlin}
    volumes:
      - ./config:/app/config
      - ./cache:/app/cache
      - ./logs:/app/logs
      - /tmp:/tmp:shared
      - ${BACKUP_SOURCE:-/mnt/data}:/data:ro
      - ${BACKUP_REPO:-./repository}:/repository
      - ./export:/export
    command:
      - server
      - start
      - --insecure
      - --address=0.0.0.0:51515
      - --server-username=${KOPIA_UI_USER:-admin}
      - --server-password=${KOPIA_UI_PASSWORD}
      - --disable-csrf-token-checks

Drei Punkte verdienen besondere Aufmerksamkeit:

1. hostname: kopia – ohne diesen Parameter generiert Docker bei jedem Neustart einen zufälligen Container-Hostnamen. Das beeinflusst die interne User-Identität (user@hostname) und kann zu Problemen bei der Snapshot-Ownership führen.
2. /tmp:/tmp:shared – das :shared-Flag ist zwingend notwendig, damit das Snapshot-Browsing in der Web-UI funktioniert. Fehlt es, schlagen Browse-Aktionen ohne offensichtliche Fehlermeldung fehl.
3. --disable-csrf-token-checks – notwendig, wenn du Kopia hinter einem Reverse Proxy betreibst. Ohne dieses Flag erscheint ein „CSRF token mismatch"-Fehler in der Web-UI.

Verifizieren: Prüfe die YAML-Syntax mit docker compose config aus dem Verzeichnis /opt/kopia. Die Ausgabe zeigt die aufgelöste Konfiguration mit eingesetzten Variablen aus der .env-Datei. Erscheinen keine Fehlermeldungen, ist die Datei syntaktisch korrekt.

Schritt 4: Container starten und Initialisierung prüfen

Starte Kopia im Hintergrund und beobachte die ersten Log-Zeilen:

cd /opt/kopia
docker compose up -d
docker compose logs -f kopia

Beim allerersten Start initialisiert Kopia noch kein Repository automatisch – das geschieht über die Web-UI im nächsten Schritt. Was du in den Logs sehen solltest, ist etwa:

kopia  | SERVER STARTING
kopia  | Kopia server starting on 0.0.0.0:51515
kopia  | Server started.

Status-Check:

docker compose ps

Erwartete Ausgabe:

NAME    IMAGE                COMMAND                  SERVICE   CREATED         STATUS         PORTS
kopia   kopia/kopia:latest   "/bin/kopia server s…"   kopia     X seconds ago   Up X seconds   0.0.0.0:51515->51515/tcp

HTTP-Erreichbarkeit:

curl -I http://localhost:51515

Erwartete Antwort: HTTP/1.1 200 OK oder HTTP/1.1 401 Unauthorized (Login-Seite erreichbar). Ein Connection refused deutet auf einen Port-Konflikt oder einen Container-Absturz hin – prüfe dann die Logs erneut.

Verifizieren: docker compose ps zeigt STATUS: Up für den Kopia-Container. curl -I http://localhost:51515 liefert HTTP 200 oder 401. Treten Fehler auf, helfen docker compose logs kopia und der Abschnitt „Troubleshooting" weiter unten.

Schritt 5: Erst-Einrichtung im Browser – Repository anlegen

Öffne deinen Browser und navigiere zu http://<server-ip>:51515. Melde dich mit den in der .env gesetzten Werten für KOPIA_UI_USER und KOPIA_UI_PASSWORD an.

Nach dem Login zeigt Kopia einen Einrichtungsassistenten. Wähle hier dein gewünschtes Storage-Backend:

1. Lokales Verzeichnis: Trage /repository ein – das ist der im Container eingehängte lokale Pfad.
2. S3-kompatibel (Hetzner, Backblaze B2, MinIO etc.): Endpoint, Bucket-Name, Access Key und Secret Key eingeben.
3. Andere Backends: Azure Blob, Google Cloud Storage, WebDAV und SFTP sind ebenfalls direkt in der UI konfigurierbar.

Kopia fragt beim Repository-Anlegen nach dem Passwort – das ist dasselbe wie KOPIA_REPOSITORY_PASSWORD in deiner .env. Nach der Bestätigung wird das Repository initialisiert und du landest im Kopia-Dashboard.

Lege anschließend unter Policies eine Backup-Policy für das eingehängte Quellverzeichnis /data an. Dort kannst du auch den Kompressionsalgorithmus einstellen – die Community empfiehlt pgzip oder zstd-fastest als gute Balance zwischen Geschwindigkeit und Platzeinsparung.

Verifizieren: Im Dashboard erscheint unter „Repository" der Status „Connected". Starte manuell einen ersten Snapshot über „New Snapshot" mit dem Pfad /data, um die Verbindung zu testen. Nach Abschluss zeigt die Snapshot-Liste einen Eintrag mit Zeitstempel und Dateianzahl.

Schritt 6: HTTPS und Reverse Proxy (empfohlen für Produktionsbetrieb)

Das --insecure-Flag ist ausschließlich für das lokale Heimnetz oder hinter einem Reverse Proxy geeignet. Sobald Kopia von außen erreichbar sein soll, brauchst du TLS.

Option A – Eigenes TLS-Zertifikat: Ersetze --insecure im command-Abschnitt durch --tls-generate-cert (selbstsigniertes Zertifikat) oder --tls-cert-file und --tls-key-file für eigene Zertifikate (z. B. von Let's Encrypt).

Option B – Reverse Proxy (empfohlen): Kopia nutzt gRPC für seine API. Bei nginx muss deshalb grpc_pass anstelle von normalem proxy_pass konfiguriert werden. Für Traefik oder Caddy reicht HTTP-Passthrough, wenn TLS am Proxy terminiert wird. Die Einrichtung eines vollständigen Reverse-Proxy-Stacks ist in Traefik als Docker-Reverse-Proxy mit automatischem HTTPS beschrieben.

Verifizieren: Nach dem Aktivieren von TLS oder dem Vorschalten eines Reverse Proxys rufe die Web-UI über die HTTPS-URL auf. Der Browser zeigt ein gültiges Zertifikat (kein Sicherheits-Warnhinweis bei einer CA-signierten Variante). Ein erneutes docker compose logs kopia zeigt keine TLS-Fehler.

Schritt 7: Container aktualisieren

Da Kopia aktiv weiterentwickelt wird (v0.23.0, Mai 2026), empfiehlt sich ein regelmäßiges Update. Das Vorgehen ist standardisiert – neue Versionen werden ausschließlich über das Image eingespielt, die persistente Konfiguration in den Volumes bleibt unangetastet. Wie du Updates über mehrere Container hinweg automatisieren oder überwachen kannst, erklärt Docker-Container automatisch aktualisieren nach dem Watchtower-Aus.

cd /opt/kopia
docker compose pull
docker compose up -d

Soll ein Container dauerhaft auf einer bestimmten Version fixiert werden (z. B. kopia/kopia:0.23), ändere das Image-Tag in der compose.yaml entsprechend. Das verhindert ungewollte Breaking Changes durch automatische Updates.

Verifizieren: Nach dem Update zeigt docker compose ps den Container wieder als Up. Ein Aufruf der Web-UI und ein Blick unter „About" bestätigen die neue Versionsnummer.

Troubleshooting / Typische Fehler

1. „invalid repository password" beim Start: Das KOPIA_REPOSITORY_PASSWORD in der .env stimmt nicht mit dem Passwort überein, das beim Anlegen des Repositories verwendet wurde. Das Passwort kann nicht zurückgesetzt werden – prüfe deinen Passwort-Manager und stelle sicher, dass die .env-Datei nicht versehentlich geändert wurde.
2. Snapshot-Browsing in der Web-UI schlägt fehl: Das /tmp:/tmp:shared-Volume fehlt oder wurde ohne das :shared-Flag eingehängt. Stoppe den Container (docker compose down), ergänze das Flag in der compose.yaml und starte neu.
3. „CSRF token mismatch" hinter Reverse Proxy: Das Flag --disable-csrf-token-checks fehlt im command-Abschnitt der compose.yaml. Ergänze es und führe docker compose up -d aus.
4. Port 51515 belegt – Container startet nicht: Kopia wählt keinen Alternativport. Prüfe mit ss -tlnp | grep 51515, welcher Prozess den Port belegt. Passe KOPIA_PORT in der .env auf einen freien Port an.
5. Wechselnder Hostname nach Neustart: Fehlt hostname: kopia in der compose.yaml, vergibt Docker bei jedem Start eine neue Container-ID als Hostnamen. Das verändert die interne User-Identität und kann Snapshot-Ownership-Probleme verursachen.
6. Web-UI lädt, aber Login schlägt fehl: Die Werte --server-username und --server-password werden als CLI-Flags im command-Abschnitt gesetzt, nicht als Umgebungsvariablen. Prüfe, ob KOPIA_UI_USER und KOPIA_UI_PASSWORD in der .env korrekt befüllt sind.
7. Repository-Verzeichnis enthält fremde Konfiguration: Wenn ./config bereits eine repository.config aus einem anderen Kopia-System enthält, schlägt der Start mit einem Passwort-Fehler fehl. Verwende ein leeres config-Verzeichnis und richte das Repository neu ein.
8. „connection refused" bei gRPC-Verbindung hinter nginx: Normales proxy_pass genügt nicht. Nginx muss mit grpc_pass grpcs://kopia:51515 konfiguriert werden, da Kopia gRPC für die API nutzt.

Häufige Fragen

Braucht Kopia eine externe Datenbank wie PostgreSQL oder Redis?

Nein. Kopia speichert alle Metadaten – Snapshots, Policies, Index-Blöcke – direkt im Repository-Verzeichnis oder im Cloud-Bucket. Es gibt keine separate Datenbankabhängigkeit. Das macht den Restore einfacher: Du brauchst nur den Repository-Pfad und das Passwort.

Wie greife ich nach dem Start auf die Web-UI zu?

Öffne im Browser http://<server-ip>:51515. Melde dich mit den Werten aus KOPIA_UI_USER und KOPIA_UI_PASSWORD an. Beim ersten Start zeigt Kopia den Repository-Einrichtungsassistenten. Erst nach dem Anlegen oder Verbinden eines Repositories ist das Dashboard vollständig nutzbar.

Kann ich mehrere Backup-Quellen in einem Container verwalten?

Pro Container unterstützt Kopia genau ein Repository. Mehrere Backup-Quellen (z. B. /data/dokumente und /data/fotos) können alle in dasselbe Repository gesichert werden – dafür legst du in der Web-UI unter „Policies" separate Einträge an. Für verschiedene Repositories (z. B. lokales Repository und S3-Bucket) brauchst du hingegen separate Container-Instanzen.

Wie führe ich eine Wiederherstellung durch?

Im Web-UI navigierst du zu „Snapshots", wählst den gewünschten Snapshot und den Dateipfad aus und klickst auf „Restore". Das Zielverzeichnis muss als Volume im Container eingehängt sein – in der obigen Konfiguration ist ./export:/export dafür vorgesehen. Alternativ geht es über die CLI: docker exec kopia kopia snapshot restore <snapshot-id> /export. Bei einem Disaster-Recovery-Szenario startest du einen neuen Kopia-Container mit exakt demselben KOPIA_REPOSITORY_PASSWORD und verbindest das bestehende Repository über „Repository verbinden" in der Web-UI.

Welche Kompressionsalgorithmen werden empfohlen?

Kopia unterstützt zstd, gzip, pgzip, lz4 und s2. Die Community empfiehlt pgzip für eine gute Balance aus Geschwindigkeit und Kompressionsrate sowie zstd-fastest für maximale Backup-Geschwindigkeit bei etwas geringerer Kompression. Die Einstellung erfolgt unter „Policies" in der Web-UI oder per CLI beim Anlegen einer Policy.

Was passiert, wenn ich das Repository-Passwort verliere?

Das Repository-Passwort kann nicht zurückgesetzt oder wiederhergestellt werden – das ist der Preis der clientseitigen Ende-zu-Ende-Verschlüsselung. Ohne das korrekte Passwort sind die Backup-Daten unwiederbringlich verloren. Speichere es deshalb sofort und redundant – mindestens im Passwort-Manager und an einem physisch getrennten sicheren Ort.

Fazit

Kopia ist eines der wenigen Backup-Tools, das clientseitige Verschlüsselung, Deduplizierung, Kompression und eine vollständige Web-UI in einem einzigen, schlanken Docker-Image vereint. Die 15-minütige Einrichtung steht in einem guten Verhältnis zum gebotenen Funktionsumfang – besonders für KMU-Admins und Selfhoster, die ihre Backup-Infrastruktur vollständig unter eigener Kontrolle behalten wollen. Die größte Schwachstelle ist gleichzeitig das stärkste Feature: Das Repository-Passwort ist der einzige Zugangspunkt zu den verschlüsselten Daten. Wer das sicher verwahrt und regelmäßig einen Restore-Test durchführt, hat mit Kopia eine solide, wartungsarme Backup-Lösung.

Für eine vollständige Backup-Strategie lohnt sich der Blick auf die 3-2-1-Backup-Strategie umsetzen-Anleitung, die zeigt, wie du lokale Backups mit einem Off-Site-Ziel kombinierst.

Weiterführende Anleitungen und Quellen

1. Docker und Docker Compose auf Linux installieren – die Self-Hosting-Grundlage
2. 3-2-1-Backup-Strategie umsetzen: Anleitung mit Restic, USB-Disk und S3-Cloud
3. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten
4. Docker-Container automatisch aktualisieren nach dem Watchtower-Aus: Diun, WUD und Renovate
5. Immutable Backups gegen Ransomware: 3-2-1-1-0 mit restic und Hetzner Storage Box

Offizielle Quellen: Kopia Dokumentation – Installation (Docker Images) · Kopia Dokumentation – Repository Server · Kopia GitHub-Repository · Kopia Docker Hub

Passende Anleitungen auf S-EDV

1. GPT-5.5-Cyber: OpenAI startet Sicherheitsmodell als Konkurrenz zu Anthropic Myth
2. Prometheus node_exporter nativ installieren und als systemd-Dienst betreiben
3. Linux-Kernel CVE-2026-23111: Ein-Zeichen-Fehler in nf_tables ermöglicht lokale R