Docker-Volume-Backup und Migration: Praxisleitfaden mit 3 Methoden im Vergleich

Letztes Jahr zum Singles’ Day migrierte unser Unternehmen die Server von Alibaba Cloud zu Tencent Cloud. Als der Chef fragte, was mit den Docker-Datenbankdaten passieren soll – ein PostgreSQL-Container, der seit Monaten lief, mehrere GB Nutzerdaten, nie ein Backup – war klar: Hier fehlte etwas Entscheidendes.

An dem Abend habe ich wild nach Docker-Backup-Methoden gesucht und unzählige Tutorials gelesen. docker cp, tar-Archiv, Tools wie docker-volume-backup … je mehr ich las, desto verwirrter wurde ich. Jede Methode klang plausibel, aber welche passt wirklich – und trau ich mich, sie in Produktion auszuprobieren? Am meisten fürchtete ich, mitten im Backup Schreibvorgänge zu erwischen und eine beschädigte Sicherung zu erzeugen.

Nach ein paar Fehlversuchen habe ich den Dreh raus. Docker-Daten-Backup ist gar nicht so kompliziert – entscheidend ist, welche Methode zu welchem Szenario passt. In diesem Artikel geht es um drei gängige Backup-Ansätze: wann Sie welchen nutzen, wie er funktioniert und welche Fallstricke es gibt. Danach wissen Sie, wie Sie Ihre Docker-Anwendung zuverlässig absichern.

Warum Docker-Daten-Backups wichtig sind

Kurz zur Docker-Datenspeicherung

Viele merken beim Einstieg in Docker gar nicht, wie Daten gespeichert werden. Container starten, Daten liegen da – alles wirkt stabil. Aber ein Punkt wird oft übersehen: Container sind flüchtig.

Schreiben Sie Daten direkt in den Container, sind sie beim Neustart oder nach einem Image-Update weg. Docker bietet deshalb zwei Wege zur Persistenz:

• Volume (Datenvolume): Von Docker verwalteter Speicher unter /var/lib/docker/volumes/. Offiziell empfohlen – Docker kümmert sich um Berechtigungen und Lebenszyklus.
• Bind Mount (Verzeichnis-Mount): Ein Host-Verzeichnis wird in den Container gemountet, z. B. /home/user/data → /data. Daten liegen an bekannter Stelle; Backup per cp ist trivial.

Was sollten Sie sichern?

• Datenbankdateien (PostgreSQL, MySQL, MongoDB)
• Hochgeladene Dateien (Avatare, Dokumente, Bilder)
• Konfigurationsdateien (viel lässt sich neu erzeugen, sensible Configs sichert man lieber mit)
• Logdateien (falls historische Analysen wichtig sind)

Typische Szenarien für Datenverlust

Die meisten Vorfälle, die ich selbst erlebt oder mitbekommen habe, fallen in diese Kategorien:

Container versehentlich gelöscht. Am häufigsten. Sie wollen einen Test-Container entfernen – und mit docker rm -v fliegt das zugehörige anonyme Volume mit. Beim ersten Mal kannte ich den -v-Schalter nicht; die Test-Datenbank war weg.

Festplattenausfall. Server läuft zwei, drei Jahre, plötzlich SMART-Alarm. Daten waren noch lesbar, aber das Gefühl im Nacken bleibt. Mit regelmäßigem Backup: neue Platte, Restore, in unter einer Stunde wieder online.

Server-Migration. Ob Rechenzentrum, Cloud-Anbieter oder VPS → Kubernetes: Ohne Backup hoffen Sie, dass scp nicht abbricht.

Ein weiteres Beispiel: Letztes Jahr stürzte bei einem Bekannten der DB-Container ab. Nach dem Neustart war das Volume beschädigt, PostgreSQL startete nicht. Das jüngste Backup war zwei Monate alt – zwei Monate Bestellungen weg, sechsstelliger Schaden.

Das soll nicht Angst machen, sondern eines klarstellen: Regelmäßige Backups sind unverzichtbar. Verlorene Daten holt keine Technik mehr zurück.

3 Backup-Methoden im Detail

Methode 1: Backup mit tar (⭐⭐⭐⭐⭐ empfohlen)

Meine Standardmethode für fast alle Szenarien. Prinzip: Temporären Container mit gemountetem Volume starten und per tar archivieren.

Backup-Befehl:

docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd):/backup \
  ubuntu tar czf /backup/postgres-backup-20251217.tar.gz -C /data .

Aufschlüsselung:

• --rm: Container nach Lauf automatisch entfernen
• -v postgres_data:/data:ro: Volume postgres_data read-only unter /data mounten
• -v $(pwd):/backup: Aktuelles Verzeichnis als Ziel für die Archivdatei
• tar czf: c = Archiv erstellen, z = gzip, f = Dateiname
• -C /data .: In /data wechseln und alles darunter packen

Wiederherstellung:

docker run --rm \
  -v postgres_data:/data \
  -v $(pwd):/backup \
  ubuntu tar xzf /backup/postgres-backup-20251217.tar.gz -C /data

x steht für Entpacken; die übrigen Parameter entsprechen dem Backup.

Wann diese Methode?

• Universell für alle Volume-Typen
• Komprimierung spart 30–50 % Speicher
• Archiv lässt sich einfach auf anderen Server oder Cloud-Storage übertragen

Hinweise:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Beim ersten Versuch sicherte ich einen laufenden MySQL-Container. Das Backup wirkte ok – beim Restore meldete MySQL jedoch Tabellenbeschädigung. Während aktiver Schreibvorgänge kann ein Datei-Backup inkonsistent sein.

Am sichersten:

1. Schreibzugriff stoppen (Container stoppen oder Tabellen sperren)
2. Backup ausführen
3. Schreibzugriff wieder freigeben

Wenn ein Stopp unmöglich ist: Journal oder WAL aktiv lassen – dann kann die DB nach dem Restore oft selbst reparieren.

Praxis: PostgreSQL-Volume sichern

# 1. PostgreSQL-Container stoppen (wenn möglich)
docker stop my-postgres

# 2. Volume sichern
docker run --rm \
  -v postgres_data:/data:ro \
  -v /backup:/backup \
  ubuntu tar czf /backup/pg-$(date +%Y%m%d-%H%M%S).tar.gz -C /data .

# 3. Backup-Datei prüfen
ls -lh /backup/pg-*.tar.gz

# 4. Container neu starten
docker start my-postgres

Im Dateinamen setze ich gern einen Zeitstempel – so erkennt man das Backup auf einen Blick.

Methode 2: docker cp (⭐⭐⭐)

Direkter: Dateien ohne Archiv kopieren. Gut für schnelle Sicherungen weniger Configs oder kleiner Verzeichnisse.

Backup:

# 1. Temporären Container mit Volume anlegen
docker create -v nginx_config:/data --name temp_backup busybox

# 2. Daten auf den Host kopieren
docker cp temp_backup:/data ./nginx-config-backup

# 3. Temporären Container entfernen
docker rm temp_backup

Wiederherstellung:

# Beispiel: in laufenden Container zurückspielen
docker cp ./nginx-config-backup/. my-nginx:/etc/nginx/

Wann diese Methode?

• Nur wenige Config-Dateien
• Kleine Datenmengen (bis etwa einige Dutzend MB)
• Inhalt ohne Entpacken einsehen

Nachteile:

• Keine Komprimierung – große Dateien brauchen viel Platz
• Langsamer als tar bei größeren Mengen
• Berechtigungen und Sonderattribute nicht immer perfekt erhalten

Praxis: Nginx-Config sichern

# Temporären Container anlegen
docker create -v nginx_config:/config --name nginx_temp busybox

# Config kopieren
docker cp nginx_temp:/config/nginx.conf ./backup/

# Gesamtes Verzeichnis
docker cp nginx_temp:/config/. ./backup/nginx-config/

# Aufräumen
docker rm nginx_temp

Vor größeren Nginx-Änderungen kopiere ich die Config so raus – bei Fehlkonfiguration geht der Rollback schnell.

Methode 3: docker-volume-backup (⭐⭐⭐⭐ erste Wahl für Automatisierung)

Die ersten beiden Methoden sind manuell – für Produktion brauchen Sie zeitgesteuerte Backups. Dafür nutze ich offen/docker-volume-backup:

• Automatische Zeitplanung (Cron-Ausdruck)
• Optional Container vor Backup stoppen (Konsistenz)
• Backends: S3, Google Drive, SSH, WebDAV
• Alte Backups automatisch löschen

Docker Compose Beispiel:

version: '3.8'

services:
  # Ihre Datenbank
  postgres:
    image: postgres:15
    volumes:
      - db_data:/var/lib/postgresql/data
    labels:
      # Container während Backup stoppen
      - "docker-volume-backup.stop-during-backup=true"

  # Backup-Service
  backup:
    image: offen/docker-volume-backup:latest
    environment:
      # Täglich um 2 Uhr
      BACKUP_CRON_EXPRESSION: "0 2 * * *"
      BACKUP_FILENAME: "db-backup-%Y%m%d-%H%M%S.tar.gz"
      BACKUP_RETENTION_DAYS: "7"
    volumes:
      - db_data:/backup/db_data:ro
      - ./backups:/archive
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  db_data:

Ablauf:

1. Um 2 Uhr startet der Backup-Container
2. postgres hat stop-during-backup → Container wird gestoppt
3. db_data wird per tar archiviert
4. Archiv landet in ./backups
5. postgres startet wieder
6. Backups älter als 7 Tage werden gelöscht

Wann diese Methode?

• Produktion mit regelmäßigen Backups
• Upload in Cloud-Storage (S3, GCS …)
• Mehrere Container zentral absichern

Hinweise:

Beim ersten Setup: /var/run/docker.sock muss lesbar sein, sonst können andere Container nicht gestoppt werden.

Der Dienst pausiert für Sekunden bis Minuten – je nach Datenmenge. Wenn kein Stopp möglich ist, stop-during-backup weglassen und das Risiko inkonsistenter Snapshots akzeptieren.

Praxis: MongoDB automatisch sichern

version: '3.8'

services:
  mongodb:
    image: mongo:7
    volumes:
      - mongo_data:/data/db
    labels:
      - "docker-volume-backup.stop-during-backup=true"

  backup:
    image: offen/docker-volume-backup:latest
    environment:
      BACKUP_CRON_EXPRESSION: "0 3 * * *"
      BACKUP_FILENAME: "mongo-%Y%m%d.tar.gz"
      BACKUP_RETENTION_DAYS: "14"
      AWS_S3_BUCKET_NAME: "my-backups"
      AWS_ACCESS_KEY_ID: "${AWS_KEY}"
      AWS_SECRET_ACCESS_KEY: "${AWS_SECRET}"
    volumes:
      - mongo_data:/backup/mongo_data:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  mongo_data:

Täglich um 3 Uhr → Backup nach S3, lokal nichts behalten. Läuft bei mir seit über einem halben Jahr stabil.

Vollständiger Migrations-Workflow

Server-Migration Schritt für Schritt

Nach den Backup-Methoden der praktische Ablauf – so lief meine Migration von Alibaba Cloud zu Tencent Cloud:

1. Vorbereitung (nicht überspringen)

Bestand erfassen:

# Alle Container
docker ps -a

# Alle Volumes
docker volume ls

# Container-Konfiguration exportieren (wichtig!)
docker inspect my-postgres > postgres-config.json
docker inspect my-nginx > nginx-config.json

# docker-compose.yml und .env sichern
cp docker-compose.yml docker-compose.backup.yml
cp .env .env.backup

Beim ersten Mal vergaß ich die Umgebungsvariablen – auf dem neuen Server stimmte das DB-Passwort nicht, Stunden Debug-Zeit.

2. Backup-Phase

Dienste stoppen, dann sichern:

# Alle Container stoppen
docker-compose down

# Jedes Volume sichern
docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/postgres_data.tar.gz -C /data .

docker run --rm \
  -v nginx_config:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/nginx_config.tar.gz -C /data .

# Backups prüfen
ls -lh backups/
md5sum backups/*.tar.gz > backups/checksums.txt

md5sum ist Gold wert – bei instabilem Transfer erkennen Sie beschädigte Dateien.

3. Übertragung

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Backup auf den neuen Server:

# rsync mit Fortsetzung
rsync -avP --partial backups/ user@new-server:/tmp/backups/

# oder scp
scp -r backups/ user@new-server:/tmp/backups/

Bei sehr großen Archiven (zig GB) und schwachem Netz: Zwischenstation über S3/OSS – oft schneller und stabiler.

Wiederherstellung auf dem neuen Server:

# 1. Volumes anlegen
docker volume create postgres_data
docker volume create nginx_config

# 2. Daten einspielen
docker run --rm \
  -v postgres_data:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/postgres_data.tar.gz -C /data

docker run --rm \
  -v nginx_config:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/nginx_config.tar.gz -C /data

# 3. Inhalt prüfen
docker run --rm -v postgres_data:/data ubuntu ls -lh /data

# 4. Dienste starten
docker-compose up -d

4. Validierung

Erst prüfen, dann Traffic umschalten:

# Container-Status
docker ps

# Logs auf Fehler
docker-compose logs -f

# DB-Verbindung testen
docker exec -it my-postgres psql -U postgres -c "SELECT COUNT(*) FROM users;"

# Datensätze alt vs. neu vergleichen
# (meist per Skript: Zeilen in Kerntabellen)

Alles grün → DNS oder Load Balancer anpassen.

Ein Fallstrick:

Ein 50-GB-Volume entpackte per docker run tar fast eine Stunde. Schneller: Volume anlegen und direkt unter /var/lib/docker/volumes/<name>/_data auf dem Host entpacken – dabei auf Berechtigungen achten.

Besonderheiten beim Datenbank-Backup

Datenbanken sind die größte Fehlerquelle – deshalb extra Abschnitt.

Warum reines Datei-Backup riskant ist

Während der Betrieb schreibt ständig. InnoDB hat Redo/Undo-Log, PostgreSQL WAL – alles für Transaktionskonsistenz. Packen Sie mitten in eine Transaktion, ist der Snapshot inkonsistent.

Extremfall: MySQL-Backup während eines Massen-Inserts – Archiv sieht gut aus, Restore scheitert mit InnoDB-Korruption.

Richtig: Anwendungsschicht

PostgreSQL:

# Eine Datenbank
docker exec my-postgres pg_dump -U postgres mydb > mydb-backup.sql

# Alle Datenbanken
docker exec my-postgres pg_dumpall -U postgres > all-dbs-backup.sql

# Wiederherstellung
docker exec -i my-postgres psql -U postgres mydb < mydb-backup.sql

MySQL:

# Backup
docker exec my-mysql mysqldump -u root -p mydb > mydb-backup.sql

# Restore
docker exec -i my-mysql mysql -u root -p mydb < mydb-backup.sql

MongoDB:

# Backup
docker exec my-mongo mongodump --out=/backup
docker cp my-mongo:/backup ./mongo-backup

# Restore
docker cp ./mongo-backup my-mongo:/backup
docker exec my-mongo mongorestore /backup

Doppelte Absicherung

Mein Setup: Anwendungs-Backup (pg_dump & Co.) + Volume-Backup.

• Anwendungsschicht: primärer Restore-Weg, konsistent
• Volume (tar): Notfall, falls SQL-Backup fehlt oder korrupt ist

Mehr Speicher, aber Ruhe. Der Bekannte mit dem Datenverlust hatte nur Volume-Backups – beim Restore kaputt, kein pg_dump.

Best Practices und Fallstricke

Backup-Strategie

Methoden allein reichen nicht – Sie brauchen eine Strategie.

3-2-1-Regel (Branchenstandard):

• 3 Kopien: Original + 2 Backups
• 2 Medien: z. B. lokale Platte + Cloud oder zwei getrennte Laufwerke
• 1 offsite: mindestens ein Backup geografisch getrennt

Meine Umsetzung:

• Server: 7 Tage tägliche Backups
• NAS: 30 Tage
• S3: 3 Monate monatliche Archive

Backup-Frequenz:

Namenskonvention:

<dienst>-<datentyp>-<YYYYMMDD>-<HHMMSS>.tar.gz

Beispiele:

myapp-postgres-20251217-020000.tar.gz
myapp-nginx-config-20251217-020000.tar.gz
myapp-uploads-20251217-020000.tar.gz

Sortierung nach Zeit, Inhalt auf einen Blick.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Häufige Probleme

Problem 1: „volume is in use“

Selten, weil Volumes mehrfach gemountet werden können. Mögliche Ursachen: Dateisperren, NFS-Probleme.

# Welche Container nutzen das Volume?
docker ps --filter volume=my_volume

# Container stoppen
docker stop container_name

# oder --volumes-from
docker run --rm --volumes-from=my_container -v $(pwd):/backup ubuntu tar czf /backup/data.tar.gz -C /data .

Problem 2: Falsche Berechtigungen nach Restore

tar behält Rechte oft – UID/GID können zwischen Ubuntu und CentOS abweichen.

Symptom: Container meldet fehlende Schreibrechte.

# Owner beim Entpacken setzen
docker run --rm -v my_volume:/data -v $(pwd):/backup ubuntu sh -c "tar xzf /backup/data.tar.gz -C /data && chown -R 999:999 /data"

# 999:999 = postgres im PostgreSQL-Image
# UID je Image prüfen (Dokumentation oder docker inspect)

Problem 3: Archiv zu groß für Transfer

50-GB-MySQL → 30 GB gzip über öffentliches Netz: langsam und fehleranfällig.

Lösungen:

1. Höhere Kompression – xz spart 20–30 % gegenüber gzip, dafür langsamer

   tar cJf backup.tar.xz /data  # J = xz

2. Split-Archive

   tar czf - /data | split -b 1G - backup.tar.gz.
   # Restore: cat backup.tar.gz.* | tar xzf -

3. Inkrementell – rsync oder spezialisierte Tools

Problem 4: Backup erst beim Restore als kaputt entdeckt

# Direkt nach Backup prüfen
md5sum backup.tar.gz > backup.tar.gz.md5

# Nach Transfer erneut
md5sum -c backup.tar.gz.md5

# Regelmäßig Restore testen – am wichtigsten!

Meine Gewohnheit: Nach jedem Backup die ersten Dateien im Archiv ansehen.

Automatisierung und Monitoring

Manuell ist ok – in Produktion vergisst man.

Crontab + Skript:

# /opt/scripts/backup-docker-volumes.sh
#!/bin/bash
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR=/backup

# PostgreSQL
docker run --rm \
  -v postgres_data:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/postgres-$DATE.tar.gz -C /data .

# Nginx-Config
docker run --rm \
  -v nginx_config:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/nginx-$DATE.tar.gz -C /data .

# Backups älter als 7 Tage löschen
find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete

# Optional: Benachrichtigung
echo "Backup completed: $DATE" | mail -s "Docker Backup Report" [email protected]

# crontab
crontab -e

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

Monitoring:

1. Log mit Zeit, Größe, MD5
2. Täglich prüfen, ob neues Backup existiert – sonst Alarm
3. Größenanomalien (>50 % Abweichung vom Mittel)

Einfaches Prüfskript:

#!/bin/bash
BACKUP_DIR=/backup
EXPECTED_SIZE=100000000  # 100 MB – anpassen

LATEST_BACKUP=$(ls -t $BACKUP_DIR/postgres-*.tar.gz | head -1)
if [ -z "$LATEST_BACKUP" ]; then
  echo "ERROR: No backup file found!"
  exit 1
fi

BACKUP_DATE=$(stat -c %Y "$LATEST_BACKUP")
TODAY=$(date +%s)
AGE=$((TODAY - BACKUP_DATE))

if [ $AGE -gt 86400 ]; then
  echo "ERROR: Latest backup is older than 24 hours!"
  exit 1
fi

SIZE=$(stat -c %s "$LATEST_BACKUP")
if [ $SIZE -lt $(($EXPECTED_SIZE / 2)) ]; then
  echo "WARNING: Backup file is too small: $SIZE bytes"
  exit 1
fi

echo "Backup check passed: $LATEST_BACKUP ($SIZE bytes)"

Integration in Prometheus, Zabbix oder Mail/Chat-Alerts ist straightforward.

Fazit

Zurück zur Kernfrage: Wie sichert man Docker-Daten?

Es gibt keine Universalmethode – wählen Sie nach Szenario:

• Ad-hoc, schnelle Migration: tar – universell und robust
• Configs, kleine Dateien: docker cp – minimaler Aufwand
• Produktion, Automatisierung: docker-volume-backup – weniger Handarbeit

Und vor allem: regelmäßig sichern und regelmäßig wiederherstellen testen. Nicht erst im Notfall feststellen, dass das Archiv unbrauchbar ist. Ich restore jeden Monat in einer Testumgebung.

Mein Vorschlag: Heute das erste Backup Ihrer Docker-App – mit der einfachen tar-Methode. Ein Archiv auf der Platte beruhigt.

Fragen, eigene Tricks oder bessere Ansätze? Tauschen wir uns in den Kommentaren aus – gemeinsam weniger Fallstricke.