Backups mit Duplicati und Docker: Datensicherung
Anleitung: Sichere deine Docker-Daten & Datenbanken zuverlässig mit Duplicati. Richte automatische Backups ein (auch in die Cloud). Open Source.

Inhaltsverzeichnis
- Warum Backups unverzichtbar sind
- RAID vs. Backup: Redundanz ist nicht gleich Sicherheit
- Die 3-2-1 Regel: Ein solides Fundament
- Duplicati im Docker-Container: Installation und Konfiguration
- Dein erstes Duplicati-Backup: Ordner sichern leicht gemacht
- Datenbanken korrekt sichern: Die Herausforderung mit Dumps (PostgreSQL & MySQL)
- Automatisierte Datenbank-Dumps: Skripte und Docker-Services
- Datenwiederherstellung: Der Praxistest für das Backup
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
odermysqldump
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
undPGID
: Ganz wichtig! Das sind die Benutzer- und Gruppen-IDs auf deinem Host-System. Gib im Terminalid -u
undid -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 Ordnerconfig
wird in den Container gemappt. Da speichert Duplicati alles Wichtige. Muss existieren!./backups:/backups
: Ein lokaler Ordnerbackups
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 überhttp://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.
- Lokaler Ordner: Einfach den Pfad angeben, den du in der
- 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.
- Es startet eine Endlosschleife (
- 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. mitgunzip 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.
- Temporär ein Volume mounten: Stoppe den Container, füge in der
- 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:
(Pfad und Dateinamen anpassen!)# Im PostgreSQL-Container ausführen: pg_restore -U dein_db_user -d deine_db_name < /tmp/backup.sql
- 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
- PostgreSQL: Das Tool heißt
- 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!