Docker Container richtig sichern und wiederherstellen — Backup-Guide

Docker Volumes, Container und Images sichern und wiederherstellen. Backup-Strategien mit tar, docker commit, docker-compose und automatisierten Scripts für dein Homelab.

Wer sein Homelab mit Docker betreibt, kennt das Problem: Nach Stunden der Konfiguration läuft endlich alles perfekt – doch was passiert bei einem Hardware-Defekt, versehentlichem docker-compose down -v oder beim Umzug auf einen neuen Host? Ohne vernünftiges Backup-Konzept beginnt die Arbeit von vorn.

In diesem Guide zeige ich dir, wie du deine Docker-Container, Volumes und Compose-Stacks professionell sicherst und im Ernstfall schnell wiederherstellst. Von manuellen Backups über automatisierte Scripts bis hin zu Offsite-Strategien mit rsync und borg.

Was muss eigentlich gesichert werden?#

Docker-Umgebungen bestehen aus mehreren Komponenten, die unterschiedliche Backup-Strategien erfordern:

Docker Images vs. Container vs. Volumes#

Docker Images sind die Vorlagen, aus denen Container entstehen. In den meisten Fällen musst du Images nicht sichern – sie lassen sich jederzeit aus Docker Hub oder deiner Registry neu laden. Anders sieht es bei selbst gebauten Images aus, hier ist ein Backup der Dockerfiles (idealerweise in Git) wichtiger als das Image selbst.

Container sind laufende Instanzen von Images. Ihren Status zu sichern macht nur in Ausnahmefällen Sinn (z.B. bei langwierigen Konfigurationen im Container selbst). Die bessere Strategie: Container als ephemer betrachten und stattdessen Konfiguration und Daten extern halten.

Volumes sind dein wichtigstes Backup-Ziel. Hier liegen die persistenten Daten deiner Anwendungen: Datenbanken, Uploads, Konfigurationsdateien. Volumes müssen regelmäßig gesichert werden.

Was gehört ins Backup?#

Für ein vollständiges Docker-Backup brauchst du:

  1. Docker Volumes – die persistenten Daten
  2. docker-compose.yml und zugehörige .env-Dateien
  3. Bind Mounts – Verzeichnisse auf dem Host, die in Container gemountet werden
  4. Netzwerk-Konfigurationen (bei komplexen Setups)
  5. Custom Images und Dockerfiles (bei selbst gebauten Images)

Für einen typischen Homelab-Stack reicht in 90% der Fälle: Volumes sichern + Compose-Dateien versionieren.

Docker Volumes mit tar sichern#

Die einfachste und zuverlässigste Methode für Volume-Backups ist die Verwendung eines temporären Containers mit tar. So gehst du vor:

Volume-Backup erstellen#

# Volume mit tar in ein Backup-Archiv packen
docker run --rm \
  -v mein-volume:/data \
  -v /backup:/backup \
  alpine tar czf /backup/mein-volume-$(date +%Y%m%d).tar.gz -C /data .

Was passiert hier?

  • Ein Alpine-Container wird gestartet (klein und schnell)
  • Das Volume mein-volume wird nach /data gemountet
  • Ein Backup-Verzeichnis auf dem Host wird nach /backup gemountet
  • tar czf erstellt ein komprimiertes Archiv
  • --rm räumt den Container nach dem Backup auf

Volume-Backup wiederherstellen#

# Neues Volume erstellen
docker volume create mein-volume-restored

# Backup ins Volume entpacken
docker run --rm \
  -v mein-volume-restored:/data \
  -v /backup:/backup \
  alpine tar xzf /backup/mein-volume-20260208.tar.gz -C /data

Praxis-Tipp: Container vorher stoppen#

Bei Datenbanken und anderen Anwendungen mit aktivem Schreibzugriff solltest du den Container vorher stoppen:

docker-compose stop mariadb
docker run --rm -v projektname_db_data:/data -v /backup:/backup \
  alpine tar czf /backup/mariadb-backup-$(date +%Y%m%d).tar.gz -C /data .
docker-compose start mariadb

Alternativ: Verwende die Backup-Mechanismen der Anwendung selbst (siehe Abschnitt Datenbank-Backups).

docker commit vs. docker save – Container-State sichern#

Manchmal möchtest du nicht nur Daten, sondern den kompletten Container-Zustand sichern. Docker bietet dafür zwei Befehle:

docker commit – Container als Image sichern#

docker commit erstellt aus einem laufenden oder gestoppten Container ein neues Image:

# Container pausieren und als Image committen
docker commit -p mysql-nextcloud mysql-nextcloud_backup_08.02.2026

# Image als tar-Datei exportieren
docker save -o ~/mysql_nextcloud_backup.tar mysql-nextcloud_backup_08.02.2026

Wann nützlich?

  • Nach manueller Konfiguration im Container
  • Vor größeren Updates als Fallback
  • Beim Umzug auf einen anderen Host

Wichtig: -p pausiert den Container während des Commits, um Daten-Konsistenz zu gewährleisten.

docker save vs. docker export#

  • docker save sichert ein Image mit History und Layers
  • docker export exportiert nur das Dateisystem eines Containers (keine Metadaten, keine Layers)

Für Backups ist docker save die bessere Wahl, da du das Image inkl. aller Informationen später mit docker load wiederherstellen kannst:

# Image wiederherstellen
docker load -i ~/mysql_nextcloud_backup.tar

Warum commit nicht die beste Lösung ist#

Container-Commits verstoßen gegen das Infrastructure-as-Code-Prinzip. Besser: Konfiguration in Dockerfiles und docker-compose.yml pflegen, nur Daten (Volumes) sichern. Commits sind ein Notfall-Werkzeug, keine langfristige Strategie.

Docker Compose Stacks richtig sichern#

Wenn du mit docker-compose arbeitest (und das solltest du!), wird das Backup deutlich einfacher. Ein Compose-Stack besteht aus:

  1. docker-compose.yml – die Stack-Definition
  2. .env – Umgebungsvariablen (Passwörter, Ports, etc.)
  3. Volumes – die persistenten Daten
  4. Optional: Custom Dockerfiles, Konfigurationsdateien

Compose-Stack komplett sichern#

#!/bin/bash
STACK_NAME="nextcloud"
BACKUP_DIR="/backup/docker-stacks"
DATE=$(date +%Y%m%d-%H%M)

mkdir -p "$BACKUP_DIR/$STACK_NAME/$DATE"

# 1. Compose-Dateien sichern
cd /opt/docker/$STACK_NAME
cp docker-compose.yml .env "$BACKUP_DIR/$STACK_NAME/$DATE/"

# 2. Alle Volumes des Stacks sichern
docker-compose config --volumes | while read volume; do
  docker run --rm \
    -v "$_$:/data" \
    -v "$BACKUP_DIR/$STACK_NAME/$DATE:/backup" \
    alpine tar czf "/backup/$.tar.gz" -C /data .
done

# 3. Bind-Mounts sichern (falls vorhanden)
if [ -d "./config" ]; then
  tar czf "$BACKUP_DIR/$STACK_NAME/$DATE/bind-mounts.tar.gz" ./config ./data
fi

echo "Backup abgeschlossen: $BACKUP_DIR/$STACK_NAME/$DATE"

Compose-Stack wiederherstellen#

#!/bin/bash
STACK_NAME="nextcloud"
BACKUP_DIR="/backup/docker-stacks/nextcloud/20260208-1400"

# 1. Compose-Dateien zurückkopieren
mkdir -p /opt/docker/$STACK_NAME
cd /opt/docker/$STACK_NAME
cp "$BACKUP_DIR/docker-compose.yml" "$BACKUP_DIR/.env" .

# 2. Volumes erstellen (docker-compose erstellt sie automatisch)
docker-compose up --no-start

# 3. Volumes wiederherstellen
for backup in "$BACKUP_DIR"/*.tar.gz; do
  volume=$(basename "$backup" .tar.gz)
  docker run --rm \
    -v "$_$:/data" \
    -v "$BACKUP_DIR:/backup" \
    alpine tar xzf "/backup/$.tar.gz" -C /data
done

# 4. Stack starten
docker-compose up -d

Datenbank-Backups – mysqldump & pg_dump#

Bei Datenbank-Containern ist ein Volume-Backup zwar möglich, aber nicht ideal. Besser: Die Datenbank-Tools verwenden.

MySQL/MariaDB Backup#

# Backup mit mysqldump
docker exec mariadb-container \
  mysqldump -u root -p'deinPasswort' --all-databases \
  | gzip > /backup/mysql-all-$(date +%Y%m%d).sql.gz

# Einzelne Datenbank
docker exec mariadb-container \
  mysqldump -u wordpress -p'dbpass' wordpress \
  | gzip > /backup/wordpress-$(date +%Y%m%d).sql.gz

MySQL Restore#

# Restore aus Backup
gunzip < /backup/wordpress-20260208.sql.gz | \
  docker exec -i mariadb-container mysql -u wordpress -p'dbpass' wordpress

PostgreSQL Backup#

# Postgres-Backup
docker exec postgres-container \
  pg_dumpall -U postgres | gzip > /backup/postgres-$(date +%Y%m%d).sql.gz

# Restore
gunzip < /backup/postgres-20260208.sql.gz | \
  docker exec -i postgres-container psql -U postgres

Wichtig: Für produktive Datenbanken solltest du zusätzlich Point-in-Time-Recovery (PITR) mit WAL-Archivierung einrichten.

Automatisiertes Backup-Script mit Cron#

Manuelle Backups sind fehleranfällig. Automatisiere sie mit einem zentralen Backup-Script:

#!/bin/bash
# /opt/scripts/docker-backup.sh

set -euo pipefail

BACKUP_BASE="/backup/docker"
DATE=$(date +%Y%m%d-%H%M)
RETENTION_DAYS=30

# Backup-Verzeichnis erstellen
mkdir -p "$BACKUP_BASE/$DATE"

# Funktion: Volume sichern
backup_volume() {
  local volume=$1
  echo "Backing up volume: $volume"
  docker run --rm \
    -v "$volume:/data:ro" \
    -v "$BACKUP_BASE/$DATE:/backup" \
    alpine tar czf "/backup/$.tar.gz" -C /data .
}

# Funktion: Compose-Stack sichern
backup_stack() {
  local stack_dir=$1
  local stack_name=$(basename "$stack_dir")
  
  echo "Backing up stack: $stack_name"
  
  cd "$stack_dir"
  cp docker-compose.yml .env "$BACKUP_BASE/$DATE/" 2>/dev/null || true
  
  # Volumes des Stacks finden und sichern
  docker-compose config --volumes 2>/dev/null | while read vol; do
    backup_volume "$_$"
  done
}

# Alle Stacks in /opt/docker durchgehen
for stack in /opt/docker/*; do
  if [ -f "$stack/docker-compose.yml" ]; then
    backup_stack "$stack"
  fi
done

# Datenbank-Backups
if docker ps --format '}' | grep -q mariadb; then
  echo "Creating database dump..."
  docker exec mariadb mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases \
    | gzip > "$BACKUP_BASE/$DATE/mysql-all.sql.gz"
fi

# Alte Backups löschen
find "$BACKUP_BASE" -type d -mtime +"$RETENTION_DAYS" -exec rm -rf  + 2>/dev/null || true

echo "Backup completed: $BACKUP_BASE/$DATE"

Cron-Job einrichten#

# Crontab bearbeiten
crontab -e

# Täglich um 2 Uhr nachts
0 2 * * * /opt/scripts/docker-backup.sh >> /var/log/docker-backup.log 2>&1

# Wöchentlich sonntags um 3 Uhr
0 3 * * 0 /opt/scripts/docker-backup.sh >> /var/log/docker-backup.log 2>&1

Monitoring: Verwende Healthchecks.io oder Uptime Kuma, um dich bei fehlgeschlagenen Backups benachrichtigen zu lassen.

Restore-Szenarien: Vom einzelnen Container bis zum kompletten Host#

Szenario 1: Einzelner Container crasht#

# Container neu erstellen
cd /opt/docker/nextcloud
docker-compose up -d nextcloud

# Falls Daten beschädigt: Volume restore
docker-compose stop nextcloud
docker run --rm \
  -v nextcloud_app:/data \
  -v /backup/docker/20260208-0200:/backup \
  alpine tar xzf /backup/nextcloud_app.tar.gz -C /data
docker-compose start nextcloud

Szenario 2: Kompletter Stack muss wiederhergestellt werden#

# Stack-Verzeichnis neu anlegen
mkdir -p /opt/docker/nextcloud
cd /opt/docker/nextcloud

# Compose-Dateien wiederherstellen
cp /backup/docker/20260208-0200/docker-compose.yml .
cp /backup/docker/20260208-0200/.env .

# Container erstellen (ohne zu starten)
docker-compose up --no-start

# Alle Volumes wiederherstellen
for backup in /backup/docker/20260208-0200/nextcloud_*.tar.gz; do
  volume=$(basename "$backup" .tar.gz)
  docker run --rm \
    -v "$volume:/data" \
    -v /backup/docker/20260208-0200:/backup \
    alpine tar xzf "/backup/$(basename $backup)" -C /data
done

# Stack starten
docker-compose up -d

Szenario 3: Neuer Host (Migration)#

# Auf dem alten Host: Backup erstellen
/opt/scripts/docker-backup.sh

# Backup auf neuen Host kopieren
rsync -avz /backup/docker/ neuer-host:/backup/docker/

# Auf neuem Host: Docker installieren (falls noch nicht vorhanden)
# Siehe: /tutorials/docker-auf-proxmox-einrichten/

# Stack-Struktur wiederherstellen
mkdir -p /opt/docker
cd /opt/docker

# Für jeden Stack
for stack_dir in /backup/docker/20260208-0200/*/docker-compose.yml; do
  stack_name=$(basename $(dirname "$stack_dir"))
  mkdir -p "$stack_name"
  cp "/backup/docker/20260208-0200/$stack_name/docker-compose.yml" "$stack_name/"
  cp "/backup/docker/20260208-0200/$stack_name/.env" "$stack_name/" 2>/dev/null || true
done

# Volumes wiederherstellen und Container starten (siehe Szenario 2)

Szenario 4: Versehentliches docker-compose down -v#

Wichtig: -v löscht die Volumes! Ohne Backup sind die Daten verloren.

# Panik nicht! Volumes erst mal checken
docker volume ls

# Falls Volume noch da: Container einfach neu starten
docker-compose up -d

# Falls Volume weg: Restore aus Backup (siehe Szenario 1)

Tipp: Erstelle einen Alias, der dich vor -v warnt:

# In ~/.bashrc
alias docker-compose-down-safe='echo "⚠️  WARNUNG: Verwende --volumes nicht ohne Backup!"; docker-compose down'

Offsite-Backups mit rsync und borg#

Lokale Backups schützen vor Bedienfehlern, aber nicht vor Hardware-Versagen oder Feuer. Für echte Datensicherheit brauchst du Offsite-Backups.

Rsync zu Remote-Host#

#!/bin/bash
# /opt/scripts/docker-backup-offsite.sh

BACKUP_SOURCE="/backup/docker"
REMOTE_HOST="backup-server.example.com"
REMOTE_USER="backup"
REMOTE_PATH="/mnt/backups/docker-homelab"

# Inkrementelles Backup mit rsync
rsync -avz --delete \
  -e "ssh -i /root/.ssh/backup_key" \
  "$BACKUP_SOURCE/" \
  "$REMOTE_USER@$REMOTE_HOST:$REMOTE_PATH/"

# SSH-Key ohne Passwort vorher erstellen:
# ssh-keygen -t ed25519 -f /root/.ssh/backup_key
# ssh-copy-id -i /root/.ssh/backup_key backup@backup-server.example.com

Borg Backup für Deduplizierung#

Borg ist perfekt für Docker-Backups, da es dedupliziert und verschlüsselt:

# Borg installieren
apt install borgbackup

# Repo initialisieren
export BORG_REPO="ssh://backup@backup-server.example.com/mnt/backups/docker-homelab"
borg init --encryption=repokey

# Backup erstellen
borg create \
  --compression lz4 \
  --stats \
  ::docker-backup- \
  /backup/docker

# Alte Backups aufräumen (7 tägliche, 4 wöchentliche, 6 monatliche behalten)
borg prune \
  --keep-daily=7 \
  --keep-weekly=4 \
  --keep-monthly=6

Automatisierung mit Cron:

# Täglich um 4 Uhr Offsite-Backup
0 4 * * * /opt/scripts/docker-backup-offsite.sh >> /var/log/offsite-backup.log 2>&1

Mehr Details zu Backup-Strategien findest du in unserem Guide: Backup-Strategie für dein Homelab

Troubleshooting: Häufige Probleme beim Backup/Restore#

Problem: “No space left on device” beim Backup#

# Speicherplatz prüfen
df -h /backup

# Alte Backups manuell löschen
rm -rf /backup/docker/202601*

# Docker-Images aufräumen
docker image prune -a

# Volumes die nicht mehr verwendet werden
docker volume prune

Problem: Volume-Restore funktioniert nicht#

# Überprüfe, ob Volume existiert
docker volume ls | grep mein-volume

# Überprüfe Volume-Inhalt
docker run --rm -v mein-volume:/data alpine ls -lah /data

# Neu erstellen und erneut versuchen
docker volume rm mein-volume
docker volume create mein-volume

Problem: Datenbank startet nach Restore nicht#

# Logs prüfen
docker-compose logs mariadb

# Häufige Ursache: Permissions
docker exec -it mariadb bash
chown -R mysql:mysql /var/lib/mysql

# Oder Volume-Restore mit korrekten Permissions
docker run --rm -v nextcloud_db:/data alpine chown -R 999:999 /data

Problem: Container findet nach Restore sein Volume nicht#

Überprüfe die Volume-Namen in docker-compose.yml:

volumes:
  db_data:
    external: true
    name: nextcloud_db  # Expliziter Name statt automatisch generiertem

Problem: Backup bricht bei großen Volumes ab#

Nutze --exclude für temporäre Dateien:

docker run --rm -v mein-volume:/data -v /backup:/backup \
  alpine tar czf /backup/mein-volume.tar.gz \
  --exclude='cache/*' \
  --exclude='tmp/*' \
  -C /data .

Checkliste: Deine Docker-Backup-Routine#

✅ Täglich:

  • Automatisches Volume-Backup aller Compose-Stacks
  • Datenbank-Dumps (mysqldump/pg_dump)
  • Logs auf Fehler prüfen

✅ Wöchentlich:

  • Offsite-Backup mit rsync/borg
  • Restore-Test auf Staging-System
  • Alte Backups aufräumen

✅ Monatlich:

  • Vollständigen Restore-Test durchführen
  • Backup-Script auf Fehler prüfen
  • Speicherplatz-Planung überprüfen

✅ Bei Änderungen:

  • docker-compose.yml und .env in Git committen
  • Dokumentation aktualisieren
  • Backup-Script anpassen (neue Stacks hinzufügen)

🛒 Empfohlene Hardware & Tools#

🐳

Docker Compose Starter Pack

15+ fertige Docker Compose Files inkl. Backup-Konfigurationen für die beliebtesten Homelab-Services. Starter Pack holen →

🖥️

Hetzner Cloud

Docker in der Cloud betreiben? Hetzner Cloud VPS mit Snapshots und Backups ab 4€/Monat. Hetzner ausprobieren →

Fazit#

Ein durchdachtes Backup-Konzept ist die Lebensversicherung deines Homelabs. Mit den hier gezeigten Methoden bist du für alle Szenarien gewappnet:

  • Volume-Backups mit tar für schnelle, unkomplizierte Sicherungen
  • Datenbank-Dumps für konsistente DB-Backups
  • Compose-Stack-Backups für reproduzierbare Deployments
  • Automatisierte Scripts für zuverlässige tägliche Backups
  • Offsite-Backups für echte Datensicherheit

Investiere die Zeit jetzt – dein zukünftiges Ich wird es dir danken, wenn du nach einem Ausfall in 10 Minuten statt 10 Stunden wieder online bist.

Wenn du Docker noch nicht installiert hast, schau dir unseren Guide an: Docker auf Proxmox einrichten

Hast du Fragen oder weitere Backup-Strategien? Schreib mir gerne!

Einige Links auf dieser Seite sind Affiliate-Links. Wenn du über diese Links einkaufst, erhalte ich eine kleine Provision — für dich ändert sich am Preis nichts. So unterstützt du diesen Blog und ermöglichst weitere kostenlose Tutorials. Danke! 🙏

[« Vorherige]
BorgBackup im Homelab: Einrichtung, Automatisierung und Cheat Sheet