Backups mit Duplicati und Docker: Datensicherung

Du sitzt gemütlich am Rechner, trinkst deinen Kaffee und plötzlich puff - Festplatte kaputt oder noch schlimmer: Ransomware! Was nun? Ich habe selber schon Daten verloren, weil ich dachte “Wird schon nix passieren”.

Key Takeaways

Festplattenausfälle sind Realität: Die jährliche Ausfallrate (AFR) zeigt, dass Festplatten eine begrenzte Lebensdauer haben.
RAID ist kein Backup: Es erhöht die Ausfallsicherheit bei Hardwaredefekten, schützt aber nicht vor Datenverlust durch Löschen, Ransomware oder Katastrophen.
Die 3-2-1-Regel ist fundamental: Drei Kopien, zwei Medienarten, eine Kopie woanders. Das ist der Standard.
Duplicati + Docker Open Source Tool, super flexibel, läuft prima im Container.
Datenbanken erfordern spezielle Behandlung: Tools wie pg_dump oder mysqldump sind notwendig für konsistente Sicherungen.
Automatisieren! Keiner macht Backups gerne von Hand. Automatisierte Skripte oder Backup-Container sind zuverlässiger.
Restore-Tests sind unerlässlich: Ein Backup, das du nie wiederhergestellt hast, ist vielleicht gar keins.

Video auf YouTube anschauen: Duplicati Backup-System für Docker und Datenbanken einrichten

Warum Backups unverzichtbar sind

Die Zuverlässigkeit von Datenspeichern ist ein zentrales Thema, auch wenn man nicht gerne darüber nachdenkt. Eine wichtige Kennzahl ist die “Annual Failure Rate” (AFR), die jährliche Ausfallrate von Festplatten. Sie gibt an, mit welcher Wahrscheinlichkeit eine Festplatte innerhalb eines Jahres ausfällt. Aktuelle Statistiken, beispielsweise von Backblaze, zeigen eine durchschnittliche AFR von etwa 1,41 %. Bei bestimmten Modellen liegt diese Rate sogar deutlich höher.

RAID vs. Backup: Redundanz ist nicht gleich Sicherheit

Der Einsatz einer zweiten Festplatte zur Spiegelung der Daten, bekannt als RAID 1, ist eine verbreitete Methode zur Erhöhung der Datenverfügbarkeit. Eine Platte verreckt? Kein Problem, die zweite hat ja alles noch.

Trotz dieser Verbesserung ist es wichtig zu verstehen: Ein RAID-System ersetzt kein Backup. Der Grund liegt darin, dass RAID nur vor einem spezifischen Problem schützt – dem physischen Ausfall einer Festplatte. Es bietet keinen Schutz gegen:

Versehentliches Löschen oder Ändern: Du löschst eine Datei auf Platte A? Zack, ist diese auf Platte B auch weg. RAID spiegelt ja nur.
Ransomware / Viren: Wird das System infiziert und Daten verschlüsselt, betrifft dies beide gespiegelten Platten.
Katastrophen am Standort: Blitzeinschlag, Wasserschaden, Feuer? Wenn beide Platten am selben Ort sind, sind wahrscheinlich beide hin.
Software-Fehler oder Dateisystemkorruption: Manchmal macht auch das Betriebssystem oder eine Anwendung Mist und zerschießt Daten. Auch da hilft RAID null (nicht zu verwechseln mit RAID 0).

RAID schafft Redundanz gegen Hardwarefehler, nicht aber Sicherheit gegen die vielen anderen möglichen Ursachen für Datenverlust. Untersuchungen deuten darauf hin, dass Datenverlust durch menschliche Fehler, Softwareprobleme oder Cyberangriffe sogar häufiger vorkommt als durch reine Hardwaredefekte. Ein RAID-System allein bietet daher keinen umfassenden Schutz. Ohne ein echtes, separates Backup bleibt ein erhebliches Restrisiko bestehen.

Die 3-2-1 Regel: Ein solides Fundament

Wenn RAID nicht die Lösung für alles ist, was dann? Hier kommt die 3-2-1 Backup-Regel ins Spiel. Und der Name sagt eigentlich schon alles:

3 Kopien deiner Daten: Das heißt: Deine Originaldaten plus zwei separate Backups. Warum drei? Fällt eine Kopie aus, haste immer noch zwei. Fällt die zweite auch aus (unwahrscheinlich, aber möglich), haste immer noch eine.
2 verschiedene Medientypen: Speicher nich alle Kopien auf der gleichen Art von Medium. Also nicht nur auf internen Festplatten: - Eine interne Festplatte UND eine externe USB-Festplatte. - Eine lokale Festplatte UND Cloud-Speicher. - Ein NAS (Network Attached Storage) UND ein Bandlaufwerk (okay, das ist eher was für Firmen). Die Idee dahinter ist, das Risiko zu streuen. Sollte eine bestimmte Technologie oder Charge fehleranfällig sein, sind die Daten auf dem anderen Medientyp davon nicht betroffen.
1 Kopie an einem anderen Ort (Offsite): Mindestens eine der Backup-Kopien sollte geografisch getrennt von den Originaldaten aufbewahrt werden. Dies schützt vor lokalen Ereignissen wie Feuer, Einbruch oder Naturkatastrophen. Möglichkeiten dafür:
- Cloud-Speicher (Google Drive, OneDrive, Dropbox, spezielle Backup-Anbieter).
- Ein Server bei Freunden oder Familie.
- Ein gemieteter Server (VPS oder Dedicated Server) in einem Rechenzentrum.
- Eine externe Festplatte, die regelmäßig an einen anderen Ort gebracht wird (z.B. Arbeitsplatz, Bankschließfach, Verwandte).

Die Umsetzung der 3-2-1-Regel erfordert natürlich zusätzlichen Aufwand: Mehr Speicherplatz wird benötigt, eventuell fallen Kosten für Cloud-Speicher oder zusätzliche Hardware an, Strom wird auch verbraucht und du musst das Ganze einrichten und pflegen. Dem gegenüber steht der Wert der Daten. Weiterführende Konzepte wie die 3-2-1-1-0 Regel: die zusätzliche 1 steht für eine Offline-Kopie (also eine, die nicht ständig verbunden ist, z.B. ne externe Platte im Schrank, Schutz vor Ransomware) und die 0 für null Fehler bei regelmäßigen Restore-Tests erhöhen noch weiter die Datensicherheit.

Duplicati im Docker-Container: Installation und Konfiguration

Für die praktische Umsetzung eines Backups, insbesondere in einer Docker-Umgebung, eignet sich das Open-Source-Tool Duplicati. Es ist flexibel, unterstützt viele Ziele und Verschlüsselung und lässt sich gut als Docker-Container betreiben. Vorgefertigte Images, beispielsweise von linuxserver.io, vereinfachen die Bereitstellung.

Die Installation erfolgt am besten über Docker Compose. Erstelle einen Ordner für Duplicati (z.B. ~/docker/duplicati) und darin eine Datei docker-compose.yml mit folgendem Inhalt (Pfade und IDs anpassen):

mkdir ~/docker/duplicati/{backups,config} -p
nano ~/docker/duplicati/docker-compose.yml

services:
    duplicati:
        image: lscr.io/linuxserver/duplicati:latest
        container_name: duplicati
        environment:
            - PUID=1000 # Deine User ID hier rein! Mit 'id -u' rausfinden
            - PGID=1000 # Deine Gruppen ID hier rein! Mit 'id -g' rausfinden
            - TZ=Europe/Berlin # Deine Zeitzone
            - SETTINGS_ENCRYPTION_KEY=abcd1234 # Ändern!
            # - CLI_ARGS= # Optional: Extra Kommandozeilen-Argumente
        volumes:
            - ./config:/config # Hier speichert Duplicati seine Einstellungen
            - ./backups:/backups # Hier landen die Backups (lokal, änderbar!)
            - /pfad/zu/deinen/daten:/source/daten:ro # WICHTIG: Deine Daten hier reinmappen!
            - /pfad/zum/host/daten2:/source/data2:ro # Weitere zu sichernde Daten
        ports:
            - 8200:8200 # Port für den Zugriff auf die Weboberfläche
        restart: unless-stopped

Wichtige Anpassungen:

PUID und PGID: Ganz wichtig! Das sind die Benutzer- und Gruppen-IDs auf deinem Host-System. Gib im Terminal id -u und id -g ein, um deine rauszufinden. Sonst kann Duplicati vielleicht nicht auf deine Ordner zugreifen.
TZ: Stell deine Zeitzone ein, damit die Zeitpläne stimmen. Europe/Berlin passt für Deutschland.
Volumes:
- ./config:/config: Ein lokaler Ordner config wird in den Container gemappt. Da speichert Duplicati alles Wichtige. Muss existieren!
- ./backups:/backups: Ein lokaler Ordner backups wird gemappt. Hier können deine Backups landen, wenn du lokal sicherst. Muss auch existieren!
- /pfad/zu/deinen/daten:/source/daten: Super wichtig! Hier musst du den Pfad auf deinem Host-System angeben, wo die Daten liegen, die du sichern willst (z.B. der Ordner mit den Docker-Volumes deiner anderen Container). /source/daten ist dann der Pfad im Duplicati-Container, den du später beim Einrichten des Backups auswählst. Du kannst hier auch mehrere Volumes mappen. Der Zusatz :ro (read-only) ist empfehlenswert, damit Duplicati die Originaldaten nicht versehentlich ändern kann.
Ports: 8200:8200 heißt, du erreichst die Weboberfläche von Duplicati über http://DEINE_SERVER_IP:8200.

Wenn die docker-compose.yml fertig ist, einfach im Terminal in dem Ordner sudo docker compose up -d eingeben. Docker lädt das Image runter und startet den Container. Dann kannst du im Browser die Weboberfläche aufrufen. Beim ersten Mal ist das Passwort oft changeme oder duplicati. Das solltest du sofort in den Einstellungen ändern! Sicher ist sicher.

Dein erstes Duplicati-Backup: Ordner sichern leicht gemacht

Duplicati läuft? Super! Jetzt richten wir das erste Backup ein. Geh auf die Weboberfläche ( http://DEINE_SERVER_IP:8200 ) und klick auf “Sicherung hinzufügen” oder “Add backup” > “Neue Sicherung konfigurieren”.

Allgemein: Gib dem Backup einen sinnvollen Namen, z.B. “Docker Volumes App XY” oder “Paperless App”. Du kannst auch eine Beschreibung hinzufügen. Wichtig ist hier die Verschlüsselung.
- Keine Verschlüsselung: Nur wenn du absolut sicher bist, dass niemand Unbefugtes an das Backup-Ziel kommt (z.B. rein lokale Sicherung auf verschlüsselter Platte).
- AES-256 Verschlüsselung (empfohlen): Wenn du in die Cloud, auf einen fremden Server oder auch nur auf eine externe Platte sicherst, die rumliegen könnte, am besten immer verschlüsseln! Denk dir ein starkes Passwort (Passphrase) aus und schreib es dir sicher auf! Ohne diese Passphrase ist eine Wiederherstellung der Daten unmöglich. Verlust ist Totalverlust.
Ziel: Wohin soll das Backup? Duplicati bietet zahlreiche Optionen:
- Lokaler Ordner: Einfach den Pfad angeben, den du in der docker-compose.yml unter /backups gemappt hast (also z.B. /backups).
- SFTP (SSH): Sicherung auf einen anderen Server über SSH. Benötigt Serveradresse, Port (Standard 22), Benutzername und Passwort oder SSH-Key.
- WebDAV: Viele NAS-Systeme oder Cloud-Anbieter bieten das an.
- Cloud-Anbieter: Google Drive, OneDrive, Dropbox, Amazon S3, Backblaze B2 und viele mehr sind direkt eingebaut. Meistens musst du dich über einen “AuthID”-Button authentifizieren.
- Rclone: Wenn dein Ziel nicht direkt unterstützt wird, aber von Rclone (einem anderen coolen Tool), kannst du das hier konfigurieren. Für die 3-2-1 Regel brauchst du mindestens ein Ziel, das nicht auf demselben Server/derselben Platte liegt! Also SFTP oder Cloud ist ‘ne gute Wahl für die Offsite-Kopie. Nutzen den “Verbindung testen”-Button um die Erreichbarkeit des Ziels zu prüfen.
Quelldaten: Was soll gesichert werden? Hier klickst du dich durch die Ordnerstruktur im Duplicati-Container. Finde den Ordner, den du vorhin in der docker-compose.yml als Source gemappt hast (z.B. /source/daten). Wähl die Ordner und Dateien aus, die ins Backup sollen. Du kannst auch Filter definieren, um bestimmte Dateitypen oder Ordner auszuschließen (z.B. Log-Dateien, Cache-Ordner).
Zeitplan: Wann soll das Backup laufen? Täglich? Wöchentlich? Zu ‘ner bestimmten Uhrzeit (nachts ist beliebt)? Stell das hier ein. Regelmäßige, automatische Backups sind Gold wert.
Optionen: Hier wird’s nochmal wichtig:
- Sicherungsaufbewahrung (Retention): Wie viele alte Backups willst du behalten? “Alle Sicherungen behalten” frisst ewig Speicher. Optionen wie “Intelligente Sicherungsaufbewahrung” (behält z.B. tägliche Backups der letzten 7 Tage, wöchentliche der letzten 4 Wochen etc.) oder benutzerdefinierte Regeln sind oft sinnvoll.
- Remote Volume Size: Legt fest, in wie große Blöcke die Daten vor dem Hochladen aufgeteilt werden. Der Standardwert (z.B. 50 MB) ist meist eine gute Wahl.

Wenn alles passt, klick auf “Speichern”. Duplicati fragt vielleicht nochmal wegen dem Passwort (wenn du eins vergeben hast). Und dann kannste auf “Jetzt sichern” klicken, um das erste Backup manuell anzustoßen. Das dauert beim ersten Mal am längsten, weil ja alles übertragen wird. Spätere Backups sind inkrementell, d.h. Duplicati speichert nur die Änderungen seit dem letzten Mal. Das geht viel schneller und spart Speicherplatz.

Datenbanken korrekt sichern: Die Herausforderung mit Dumps (PostgreSQL & MySQL)

Die Sicherung einfacher Dateien und Ordner mit Duplicati ist unkompliziert. Aber was ist mit Datenbanken, die in deinen Docker-Containern laufen, wie PostgreSQL oder MySQL? Hier wird’s ein bisschen kniffliger. Warum? Eine Datenbank schreibt ja ständig Daten in ihre Dateien auf der Festplatte (also im Docker Volume). Wenn Duplicati diese Dateien einfach kopiert, während die Datenbank aktiv ist, besteht ein hohes Risiko, einen inkonsistenten Zustand zu sichern. Das heißt, das Backup ist vielleicht total unbrauchbar, weil gerade mittendrin geschrieben wurde und die Dateien nicht zusammenpassen.

Was ist die Lösung? Fast jede Datenbank bringt eigene Werkzeuge mit, um einen konsistenten Snapshot, einen sogenannten Dump, zu erstellen. Diese Tools kommunizieren mit der Datenbank, um sicherzustellen, dass alle Daten in einem zusammenhängenden Zustand erfasst und in eine einzelne Datei geschrieben werden. Diese Dump-Datei kann dann sicher mit Duplicati gesichert werden.

Die wichtigsten Werkzeuge für gängige Datenbanken sind:

PostgreSQL: Das Kommandozeilenprogramm pg_dump. Es benötigt Informationen wie den Datenbankbenutzer (-U), den Datenbanknamen (-d oder als letztes Argument) und optional den Host (-h). Die Ausgabe wird üblicherweise in eine Datei umgeleitet (Endung .psql oder .dump).
```
# Beispiel: Dump der Datenbank 'meine_app_db' als User 'app_user'
pg_dump -h db_host -U app_user meine_app_db > /pfad/zum/backup/backup.sql
```

MySQL/MariaDB: Das entsprechende Tool ist mysqldump. Es benötigt ähnliche Parameter: Benutzer (-u), Passwort (-p), Datenbankname und optional Host (-h).

# Beispiel: Dump der Datenbank 'meine_webseite_db' als User 'web_user'
mysqldump -u web_user -pDEIN_PASSWORT meine_webseite_db > /pfad/zum/backup/backup.sql

Die Herausforderung besteht darin, diese Dump-Befehle regelmäßig und automatisch auszuführen und die erzeugten Dump-Dateien für Duplicati zugänglich zu machen. Eine saubere Lösung ist die Automatisierung mittels Skripten oder dedizierten Backup-Containern.

Automatisierte Datenbank-Dumps: Skripte und Docker-Services

Wer hat schon Lust, jeden Tag manuell pg_dump oder mysqldump auszuführen? Keiner! Das muss automatisch gehen. In einer Docker-Umgebung geht das oft direkt in deiner docker-compose.yml. Die Idee: Wir erstellen für jede Datenbank, die wir sichern wollen, einen zusätzlichen Service (Container), dessen einzige Aufgabe es ist, regelmäßig einen Dump zu erstellen und an einem gemeinsamen Ort abzulegen.

Beispiel für PostgreSQL und MySQL:

mkdir ~/docker/app/backup/{postgres,mysql} -p

Dann fügst du sowas in deine docker-compose.yml hinzu:

services:
  # ... andere Services hier ...
  [...]

  # MySQL Datenbank
  mysql:
    image: mysql:8.4
    container_name: demo-mysql
    environment:
      MYSQL_ROOT_PASSWORD: example
      MYSQL_DATABASE: demo
      MYSQL_USER: demouser
      MYSQL_PASSWORD: demopass
    volumes:
      - mysql-data:/var/lib/mysql
    networks:
      - demo-network
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD"]
      interval: 5s
      timeout: 5s
      retries: 5

  mysql-backup:
    networks:
      - demo-network # Muss im selben Netzwerk wie die DB sein
    image: mysql:8.4 # Dieselbe Hauptversion wie die Datenbank!
    container_name: mysql-backup
    environment:
      MYSQL_HOST: mysql
      MYSQL_DATABASE: demo
      MYSQL_USER: demouser
      MYSQL_PASSWORD: demopass
      BACKUP_NUM_KEEP: 7
      BACKUP_FREQUENCY: 1d
    entrypoint: |
      bash -c 'bash -s <<EOF
      trap "break;exit" SIGHUP SIGINT SIGTERM
      sleep 2m
      while /bin/true; do
        mysqldump -h $$MYSQL_HOST -u $$MYSQL_USER -p$$MYSQL_PASSWORD \
          --no-tablespaces \
          --single-transaction --quick --lock-tables=false $$MYSQL_DATABASE | gzip > /dump/mysql_backup_\`date +%d-%m-%Y"_"%H_%M_%S\`.sql.gz
        (ls -t /dump/mysql_backup_*.sql.gz|head -n $$BACKUP_NUM_KEEP;ls /dump/mysql_backup_*.sql.gz)|sort|uniq -u|xargs rm -f -- 2>/dev/null || true
      sleep $$BACKUP_FREQUENCY
      done
      EOF'
    depends_on:
      mysql:
        condition: service_healthy
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./backup/mysql:/dump # Host-Verzeichnis für die Dumps

  # PostgreSQL Datenbank
  postgres:
    image: postgres:17-alpine
    container_name: demo-postgres
    environment:
      POSTGRES_PASSWORD: example
      POSTGRES_USER: demouser
      POSTGRES_DB: demo
    volumes:
      - postgres-data:/var/lib/postgresql/data
    networks:
      - demo-network
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U demouser -d demo"]
      interval: 5s
      timeout: 5s
      retries: 5

  postgres-backup:
    container_name: postgres-backup
    networks:
      - demo-network
    image: postgres:17-alpine
    environment:
      PGHOST: postgres
      PGDATABASE: demo
      PGUSER: demouser
      PGPASSWORD: example
      BACKUP_NUM_KEEP: 7
      BACKUP_FREQUENCY: 1d
    entrypoint: |
      bash -c 'bash -s <<EOF
      trap "break;exit" SIGHUP SIGINT SIGTERM
      sleep 2m
      while /bin/true; do
        pg_dump -h $$PGHOST -U $$PGUSER -d $$PGDATABASE -Fc > /dump/pg_backup_\`date +%d-%m-%Y"_"%H_%M_%S\`.dump
        (ls -t /dump/pg_backup_*.dump|head -n $$BACKUP_NUM_KEEP;ls /dump/pg_backup_*.dump)|sort|uniq -u|xargs rm -f -- 2>/dev/null || true
        sleep $$BACKUP_FREQUENCY
      done
      EOF'
    depends_on:
      postgres:
        condition: service_healthy
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./backup/postgres:/dump

  # Optional Adminer für Datenbankmanagement
  adminer:
    image: adminer:latest
    container_name: demo-adminer
    ports:
      - "8080:8080"
    environment:
      ADMINER_DEFAULT_SERVER: mysql
    networks:
      - demo-network
    depends_on:
      - mysql
      - postgres

  # Optional pgAdmin für PostgreSQL-Management
  pgadmin:
    image: dpage/pgadmin4:latest
    container_name: demo-pgadmin
    environment:
      PGADMIN_DEFAULT_EMAIL: admin@example.com
      PGADMIN_DEFAULT_PASSWORD: admin
    ports:
      - "8081:80"
    networks:
      - demo-network
    depends_on:
      - postgres

volumes:
  mysql-data:
  postgres-data:

networks:
  demo-network:
    driver: bridge

Was passiert hier?

Wir nutzen dasselbe Image wie für die Datenbank-Container.
Wir mappen einen Host-Ordner nach /dump im Container. Hier landen die Backups. Dieser Host-Ordner muss dann auch in den Duplicati-Container gemappt werden!
Wir setzen Umgebungsvariablen für die Verbindung zur Datenbank.
Der entrypoint ist ein kleines Shell-Skript:
- Es startet eine Endlosschleife (while :; do ... done).
- In der Schleife wird pg_dump ausgeführt. Die Ausgabe wird mit Zeitstempel in den /dump-Ordner geschrieben.
- Dann wartet das Skript und fängt von vorne an.
Wichtig: Der Backup-Container muss im selben Docker-Netzwerk sein wie die Datenbank und braucht depends_on, damit er nicht zu früh startet.

Der Clou: Du hast jetzt einen Host-Ordner, in dem immer die aktuellsten (und vielleicht ein paar alte) Datenbank-Dumps liegen. Diesen Ordner nimmst du einfach als Quelle in deinem Duplicati-Backup-Job mit auf! Problem gelöst. Einmal eingerichtet, läuft das vollautomatisch.

Datenwiederherstellung: Der Praxistest für das Backup

Ein Backup zu haben ist gut. Zu wissen, wie man es wiederherstellt, ist besser. Ein Backup ist nämlich nur so gut wie seine erfolgreiche Wiederherstellung. Daher ist es unerlässlich, den Restore-Prozess regelmäßig zu testen. Nur so kann man sicher sein, dass im Ernstfall – sei es durch Hardwareausfall, Ransomware oder menschliches Versagen – die Daten tatsächlich wiederherstellbar sind.

1. Dateien/Ordner wiederherstellen mit Duplicati:

Das ist meistens der einfache Teil. Geh in die Duplicati Weboberfläche, klick auf “Wiederherstellen” oder “Restore”.

Wähl den Backup-Job aus, aus dem du wiederherstellen willst.
Du siehst eine Liste der verfügbaren Backup-Versionen (Zeitpunkte). Wähl die Version aus, die du brauchst.
Du kannst dann durch die Ordnerstruktur des Backups browsen und die Dateien oder Ordner auswählen, die du zurückhaben willst.
Zielort: Du kannst entweder “Ursprünglichen Speicherort” wählen (geht nur, wenn der Pfad existiert und Duplicati Schreibrechte hat – Vorsicht, überschreibt eventuell vorhandene neuere Dateien!) oder “Anderen Speicherort wählen” und einen leeren Ordner angeben, wohin Duplicati die Sachen kopieren soll. Letzteres ist oft sicherer, dann kann man die Daten in Ruhe prüfen und anschließend manuell dahin schieben, wo sie hingehören.
Klick auf “Wiederherstellen”. Wenn du Verschlüsselung genutzt hast, wirst du jetzt nach der Passphrase gefragt, wenn sie nicht in den Einstellungen gespeichert ist.
Duplicati rödelt kurz und stellt die Dateien wieder her. Fertig.

2. Datenbank wiederherstellen (aus dem Dump):

Dies erfordert einige zusätzliche Schritte, da die Dump-Datei wieder in die Datenbank eingespielt werden muss.

Dump-Datei holen: Stell erstmal die benötigte .sql oder .dump Dump-Datei aus deinem Duplicati-Backup wieder her (siehe Schritt 1), am besten in einen temporären Ordner auf deinem Host. Wenn die Datei komprimiert ist (.gz), musst du sie eventuell erst entpacken (z.B. mit gunzip backup.sql.gz).
Datenbank-Container bereit machen: Stelle sicher, dass dein Datenbank-Container läuft. Oft ist es am besten, wenn die Datenbank leer ist, bevor du den Dump einspielst. Du könntest also den Container stoppen, das zugehörige Docker Volume löschen (docker volume rm ...), und den Container neu starten (er legt dann eine leere Datenbank an). Achtung: Dieser Schritt löscht alle aktuellen Daten unwiderruflich! Nur machen, wenn du sicher bist, dass du den alten Stand aus dem Dump willst.
Dump in den Container kopieren oder mounten: Du musst die Dump-Datei irgendwie in den laufenden Datenbank-Container bekommen.
- Temporär ein Volume mounten: Stoppe den Container, füge in der docker-compose.yml ein temporäres Volume hinzu, das deinen Host-Ordner mit dem Dump in den Container mappt, starte den Container.
Restore-Befehl ausführen: Jetzt brauchst du das Gegenstück zum Dump-Befehl.
- PostgreSQL: Das Tool heißt pg_restore. Du führst es im Container aus (sudo docker compose exec container_name sh) und leitest die Dump-Datei hinein:
```
# Im PostgreSQL-Container ausführen:
pg_restore -U dein_db_user -d deine_db_name < /tmp/backup.sql
```
  (Pfad und Dateinamen anpassen!)
- MySQL/MariaDB: Das Tool heißt mysql.
```
# Im MySQL/MariaDB-Container ausführen:
mysql -u dein_db_user -pDEIN_PASSWORT deine_db_name < /tmp/backup.sql
```
Prüfen: Nachdem der Befehl durchgelaufen ist (kann dauern!), prüfe in deiner Anwendung oder mit Datenbank-Tools, ob die Daten wieder da sind.

Der Restore-Prozess, insbesondere für Datenbanken, erfordert Sorgfalt. Regelmäßige Tests sind daher unerlässlich. Simulier den Datenverlust auf einer Testumgebung. Wenn du den Restore einmal erfolgreich gemacht hast, weißt du, dass dein Backup-Konzept funktioniert und du bist im Ernstfall viel entspannter. Backups sind keine Option, sie sind absolut essentiell, wenn dir deine Daten lieb sind.

Häufig gestellte Fragen (FAQ)

Wie oft sollte ich Backups machen? Kommt drauf an, wie oft sich deine Daten ändern und wie viel Verlust du verkraften kannst. Für wichtige Sachen: Täglich ist oft gut. Für weniger kritische reicht vielleicht wöchentlich. Datenbanken vielleicht sogar öfter als normale Dateien?
Welche Backup-Ziele sind empfehlenswert? Gemäß der 3-2-1-Regel ist eine Kombination sinnvoll: Mindestens eine Kopie lokal (schneller Restore) und eine extern (Schutz vor lokalen Katastrophen). Also z.B. auf eine externe USB-Platte UND in die Cloud oder auf einen zweiten Server per SFTP.
Ist Duplicati kostenlos? Ja, Duplicati ist Open-Source-Software unter der LGPL-Lizenz und kann frei verwendet werden.
Muss ich wirklich verschlüsseln? Wenn das Backup dein Haus/deinen Server verlässt (Cloud, SFTP, externe Platte die du mitnimmst),ist eine starke Verschlüsselung dringend empfohlen. Denk an das Passwort!
Wie teste ich meinen Restore am besten? Richte eine Testumgebung ein (z.B. auf deinem Laptop oder einem Testserver). Spiel dort das Backup ein und schau, ob alles funktioniert wie erwartet. Mach das regelmäßig, z.B. alle paar Monate.
Was ist mit anderen Datenbanken (z.B. MongoDB, Redis)? Auch die haben meist eigene Backup-Tools (mongodump, Redis hat Snapshots oder AOF). Das Prinzip ist ähnlich: Finde das richtige Tool, erstelle einen konsistenten Dump/Snapshot, automatisiere das und nimm die Dump-Datei ins Duplicati-Backup auf. Dokumentation der Datenbank lesen!
Reicht es nicht, das Docker Volume zu sichern? Für normale Anwendungsdaten (z.B. Uploads, Konfig-Dateien) ja. Für laufende Datenbanken: Nein, wegen der Inkonsistenz-Gefahr. Immer die Datenbank-eigenen Dump-Tools verwenden!