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

Kopia ist ein Open-Source-Backup-Werkzeug in Go (Apache 2.0) mit clientseitiger Ende-zu-Ende-Verschlüsselung (AES-256-GCM), Deduplizierung, inkrementellen Snapshots und Web-Oberfläche im knapp 75 MB großen Docker-Image. Es läuft auf amd64, arm64 und arm, braucht keine externe Datenbank und sichert nach S3, Azure Blob, Backblaze B2, WebDAV, SFTP, Rclone oder in lokale Verzeichnisse.

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, lesen Sie 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 Ihrer Datenmenge).
3. Hardware: Linux-Server, VM oder NAS mit x86-64 oder ARM64, 2 CPU-Kernen und 4 GB RAM für typische KMU-Datenmengen. Große Repositories profitieren von mehr RAM und einer SSD für den Cache.
4. Netzwerkzugang zu Port 51515 – lokal oder hinter einem Reverse Proxy.
5. 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.
6. Ein Passwort-Manager oder ein anderer sicherer Speicherort für das Repository-Passwort (KOPIA_REPOSITORY_PASSWORD) – Sie brauchen es für jeden Restore und jeden neuen Container.

Eckdaten auf einen Blick

Schritt 1: Projektordner und Verzeichnisstruktur anlegen

Legen Sie einen dedizierten Ordner an. Konfiguration, Cache, Logs und lokales Repository liegen in Unterordnern, sodass Sie den Stack als ein Verzeichnis sichern oder migrieren können.

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

Quelldaten (z. B. NAS-Freigabe oder gemountetes Laufwerk) müssen auf dem Host existieren und lesbar sein; die compose.yaml hängt sie read-only ein.

Verifizieren: Mit ls /opt/kopia sollten Sie 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 neben der compose.yaml enthält die Zugangsdaten und wird von Docker Compose automatisch eingelesen:

# /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änken Sie 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. Speichern Sie 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üfen Sie, ob der Wert gesetzt ist (Ausgabe darf kein leeres Gleichheitszeichen zeigen).

Schritt 3: compose.yaml erstellen

Erstellen Sie /opt/kopia/compose.yaml. Ohne den command-Abschnitt startet der Container keinen Server mit Web-UI.

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 feste Angabe vergibt Docker bei jedem Neustart einen zufälligen Hostnamen; das ändert die interne User-Identität (user@hostname) und kann Snapshot-Ownership-Probleme verursachen.
2. /tmp:/tmp:shared – ohne :shared schlägt das Snapshot-Browsing in der Web-UI ohne klare Fehlermeldung fehl.
3. --disable-csrf-token-checks – nötig hinter einem Reverse Proxy, sonst erscheint „CSRF token mismatch“ in der Web-UI.

Verifizieren: Prüfen Sie 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

Starten Sie Kopia im Hintergrund und beobachten Sie die ersten Log-Zeilen:

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

Das Repository legen Sie erst im nächsten Schritt in der Web-UI an. Die Logs melden ohne Fehler den Serverstart auf Port 51515, sinngemäß (Wortlaut je nach Version):

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

Erwartet: HTTP/1.1 200 OK oder HTTP/1.1 401 Unauthorized (Login-Seite erreichbar). Connection refused deutet auf Port-Konflikt oder Absturz; prüfen Sie die Logs.

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

Rufen Sie http://<server-ip>:51515 auf und melden Sie sich mit KOPIA_UI_USER und KOPIA_UI_PASSWORD aus der .env an.

Nach dem Login zeigt Kopia einen Einrichtungsassistenten. Wählen Sie hier das gewünschte Storage-Backend:

1. Lokales Verzeichnis: /repository (der im Container eingehängte 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.

Das beim Anlegen abgefragte Passwort ist KOPIA_REPOSITORY_PASSWORD aus der .env. Danach landen Sie im Kopia-Dashboard.

Legen Sie unter Policies eine Backup-Policy für /data an. Dort stellen Sie auch die Kompression ein; empfohlen sind pgzip oder zstd-fastest.

Verifizieren: Im Dashboard erscheint unter „Repository“ der Status „Connected“. Starten Sie 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)

--insecure ist nur im lokalen Heimnetz oder hinter einem Reverse Proxy geeignet. Von außen erreichbar braucht Kopia TLS.

Option A – Eigenes TLS-Zertifikat: Ersetzen Sie --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 rufen Sie 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.1, Juni 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 Sie Updates über mehrere Container hinweg automatisieren oder überwachen können, erklärt Docker-Container automatisch aktualisieren nach dem Watchtower-Aus.

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

Für eine feste Version (z. B. kopia/kopia:0.23) ändern Sie das Image-Tag in der compose.yaml; das verhindert ungewollte Breaking Changes.

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: KOPIA_REPOSITORY_PASSWORD passt nicht zum Passwort beim Anlegen des Repositories; zurücksetzen lässt es sich nicht. Passwort-Manager prüfen und sicherstellen, dass die .env nicht versehentlich geändert wurde.
2. Snapshot-Browsing in der Web-UI schlägt fehl: /tmp:/tmp:shared fehlt oder ohne :shared. Container stoppen (docker compose down), Flag ergänzen, neu starten.
3. „CSRF token mismatch“ hinter Reverse Proxy: --disable-csrf-token-checks im command-Abschnitt ergänzen, dann docker compose up -d.
4. Port 51515 belegt – Container startet nicht: Mit ss -tlnp | grep 51515 den Prozess ermitteln und KOPIA_PORT in der .env auf einen freien Port setzen.
5. Wechselnder Hostname nach Neustart: hostname: kopia fehlt in der compose.yaml (siehe Schritt 3).
6. Web-UI lädt, aber Login schlägt fehl: --server-username und --server-password sind CLI-Flags im command-Abschnitt, keine Umgebungsvariablen. Prüfen, ob KOPIA_UI_USER und KOPIA_UI_PASSWORD in der .env befüllt sind.
7. Repository-Verzeichnis enthält fremde Konfiguration: Eine repository.config aus einem anderen Kopia-System in ./config führt zu einem Passwort-Fehler. Leeres config-Verzeichnis verwenden und das Repository neu einrichten.
8. „connection refused“ bei gRPC-Verbindung hinter nginx: Normales proxy_pass genügt nicht; Kopia nutzt gRPC, nötig ist grpc_pass grpcs://kopia:51515.

Häufige Fragen

Braucht Kopia eine externe Datenbank wie PostgreSQL oder Redis?

Nein. Snapshots, Policies und Index-Blöcke liegen im Repository-Verzeichnis oder Cloud-Bucket. Für einen Restore brauchen Sie nur Repository-Pfad und Passwort.

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

Unter http://<server-ip>:51515 mit KOPIA_UI_USER und KOPIA_UI_PASSWORD. Beim ersten Start erscheint der Repository-Einrichtungsassistent; das Dashboard ist erst danach voll nutzbar.

Kann ich mehrere Backup-Quellen in einem Container verwalten?

Ein Container unterstützt genau ein Repository. Mehrere Quellen (z. B. /data/dokumente und /data/fotos) sichern Sie mit separaten Policies in dasselbe Repository. Für verschiedene Repositories (z. B. lokal und S3) brauchen Sie separate Container.

Wie führe ich eine Wiederherstellung durch?

In der Web-UI unter „Snapshots“ Snapshot und Dateipfad wählen, dann „Restore“. Das Ziel muss im Container eingehängt sein, hier ./export:/export. Per CLI: docker exec kopia kopia snapshot restore <snapshot-id> /export. Im Disaster-Recovery-Fall starten Sie einen neuen Container mit demselben KOPIA_REPOSITORY_PASSWORD und verbinden das Repository über „Repository verbinden“.

Welche Kompressionsalgorithmen werden empfohlen?

Kopia unterstützt zstd, gzip, pgzip, lz4 und s2. pgzip bietet eine gute Balance aus Geschwindigkeit und Kompression, zstd-fastest maximale Geschwindigkeit bei etwas geringerer Kompression. Einstellbar unter „Policies“ oder per CLI.

Was passiert, wenn ich das Repository-Passwort verliere?

Das Repository-Passwort lässt sich nicht zurücksetzen oder wiederherstellen; ohne es sind die Backup-Daten unwiederbringlich verloren. Speichern Sie es sofort redundant, mindestens im Passwort-Manager und an einem physisch getrennten sicheren Ort.

Fazit

Kopia vereint Verschlüsselung, Deduplizierung, Kompression und Web-UI in einem schlanken Image; die Einrichtung dauert etwa 15 Minuten. Das Repository-Passwort ist der einzige Zugang zu den Daten: Verwahren Sie es sicher und testen Sie regelmäßig einen Restore.

Für eine vollständige Backup-Strategie lohnt sich der Blick auf die 3-2-1-Backup-Strategie umsetzen-Anleitung, die zeigt, wie Sie 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. Backrest mit Docker Compose: restic-Backups per Weboberfläche planen und wiederherstellen
2. borgmatic im Docker-Container: automatisierte Server-Backups mit BorgBackup
3. Backup-Restore-Test als feste Routine etablieren