Docker-Volumes auf einem VPS sichern und wiederherstellen

12 Min. Lesezeit·Matthieu·cronrclones3mysqlpostgresqlbackupdocker-composedocker|

Drei Backup-Strategien für Docker-Volumes auf einem VPS: Tar-Snapshots, datenbanknative Dumps und automatisierte verschlüsselte Backups mit offen/docker-volume-backup. Mit Cron-Planung, Off-Site-Kopien via rclone zu S3 und vollständigem Restore-Test auf einem frischen Server.

Benannte Docker-Volumes enthalten Ihre Produktionsdaten: Datenbanken, Uploads, Konfigurationszustände. Die Container sind austauschbar. Die Volumes nicht. Bei einem Festplattenausfall oder einer fehlgeschlagenen Migration sind es die Volumes, die Sie zurückbrauchen.

Diese Anleitung behandelt drei Backup-Strategien, automatisiert sie mit Cron, verschickt Kopien vom Server weg mit rclone und beweist dann, dass die Wiederherstellung funktioniert, indem alles auf einem frischen VPS neu aufgebaut wird. Wenn Sie Ihren Restore nie getestet haben, haben Sie keine Backups.

Was Sie lernen werden:

  • Tar-basierte Volume-Snapshots (einfach, universell)
  • Datenbanknative Dumps mit pg_dump und mysqldump (konsistent, ohne Ausfallzeit)
  • Automatisierte verschlüsselte Backups mit offen/docker-volume-backup (geplant, S3-fähig)
  • Cron-Automatisierung mit Aufbewahrungsrichtlinien
  • Off-Site-Kopien zu S3-kompatiblem Speicher via rclone
  • Vollständige Disaster-Recovery-Wiederherstellung auf einem frischen VPS

Voraussetzungen

Sie benötigen einen VPS mit Debian 12 oder Ubuntu 24.04, auf dem Docker und Docker Compose v2 installiert sind. Diese Anleitung setzt voraus, dass Sie einen laufenden Compose-Stack mit mindestens einem benannten Volume haben. Falls Sie das erst einrichten müssen, lesen Sie unsere Anleitung zu Docker Compose mit mehreren Services auf einem VPS.

Überprüfen Sie Ihre Installation:

docker --version
# Docker version 28.x or newer
docker compose version
# Docker Compose version v2.x or newer

Prüfen Sie Ihre vorhandenen Volumes:

docker volume ls

Die Ausgabe listet jedes benannte Volume auf dem System auf. Identifizieren Sie, welche wichtige Daten enthalten. Nutzen Sie docker system df -v, um den Speicherverbrauch jedes Volumes zu sehen. Das hilft bei der Abschätzung von Backup-Größen und Speicherbedarf.

Erstellen Sie ein Backup-Verzeichnis mit eingeschränkten Berechtigungen:

mkdir -p /opt/backups/docker
chmod 700 /opt/backups/docker

Nur root kann dieses Verzeichnis lesen. Backups enthalten oft Datenbank-Zugangsdaten, Session-Tokens oder Benutzerdaten.

Wie sichere ich Docker-Volumes auf einem VPS?

Es gibt drei Strategien mit unterschiedlichen Vor- und Nachteilen. Wählen Sie basierend auf dem Inhalt Ihrer Volumes und der tolerierbaren Ausfallzeit.

Methode Ausfallzeit Datenkonsistenz Automatisierung Verschlüsselung Geeignet für
Tar-Snapshot Kurz (Container gestoppt) Dateisystemebene Manuell oder Cron-Skript Nein (GPG separat hinzufügen) Statische Dateien, Uploads, Konfiguration
Datenbank-Dump Keine Transaktionskonsistent Manuell oder Cron-Skript Nein (GPG separat hinzufügen) PostgreSQL, MySQL, MariaDB
offen/docker-volume-backup Optional (konfigurierbar) Dateisystemebene Integrierter Scheduler Integriertes GPG Jedes Volume, Hands-off-Betrieb

Wie erstelle ich ein Tar-Backup eines Docker-Volumes?

Stoppen Sie den Container, der das Volume nutzt, starten Sie einen temporären Alpine-Container zum Archivieren des Volume-Inhalts per tar, und starten Sie den Container neu. Das dauert wenige Sekunden für die meisten Volumes und funktioniert mit jedem Datentyp.

1. Stoppen Sie den Container, der in das Volume schreibt:

# Replace "app" with your service name from docker-compose.yml
docker compose stop app

Das Stoppen des Schreibers verhindert unvollständige Schreibvorgänge während der Archivierung. Bei schreibgeschützten Volumes oder statischen Dateien können Sie diesen Schritt überspringen.

2. Erstellen Sie das Tar-Archiv:

docker run --rm \
  -v myapp_data:/source:ro \
  -v /opt/backups/docker:/backup \
  alpine tar czf /backup/myapp_data-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

Was das macht: Es startet einen Wegwerf-Alpine-Container, mountet Ihr Volume schreibgeschützt unter /source, mountet das Backup-Verzeichnis unter /backup und erstellt ein gzip-komprimiertes Tar-Archiv. Das Flag --rm löscht den Container nach Abschluss. Das Flag :ro verhindert, dass der Backup-Prozess versehentlich in Ihre Daten schreibt.

3. Starten Sie den Container neu:

docker compose start app

4. Überprüfen Sie das Archiv:

ls -lh /opt/backups/docker/myapp_data-*.tar.gz

Die Ausgabe zeigt das Archiv mit einer vernünftigen Dateigröße sehen. Ein 500-MB-Volume komprimiert sich je nach Datentyp typischerweise auf 60-120 MB.

Listen Sie den Archivinhalt auf, um die Dateien zu bestätigen:

tar tzf /opt/backups/docker/myapp_data-20260319-120000.tar.gz | head -20

Genau hinsehen: Die Pfade sollten mit ./ beginnen (kein führender Verzeichnisname). Das liegt daran, dass wir -C /source . im tar-Befehl verwendet haben. Das ist bei der Wiederherstellung wichtig.

Wie sichere ich eine PostgreSQL-Datenbank in Docker?

Verwenden Sie pg_dump innerhalb des laufenden Containers. Das erzeugt einen transaktionskonsistenten Dump, ohne die Datenbank zu stoppen. Das Custom-Format (-Fc) komprimiert die Ausgabe und unterstützt selektive Wiederherstellung.

docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -Fc \
  --no-owner \
  --no-acl \
  mydb > /opt/backups/docker/mydb-$(date +%Y%m%d-%H%M%S).dump

Was das macht: exec -T führt den Befehl im laufenden postgres-Container aus, ohne ein TTY zuzuweisen (erforderlich für die Ausgabeumleitung). -Fc wählt das Custom-Format, das komprimiert ist und pg_restore unterstützt. --no-owner und --no-acl machen den Dump portabel zwischen verschiedenen Datenbankbenutzern.

Die Variable $POSTGRES_USER sollte aus Ihrer Umgebungsdatei stammen, nicht fest kodiert sein. Wenn Ihr Compose-Stack eine env-Datei verwendet:

source /opt/myapp/.env
docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -Fc \
  --no-owner \
  --no-acl \
  "$POSTGRES_DB" > /opt/backups/docker/"$POSTGRES_DB"-$(date +%Y%m%d-%H%M%S).dump

Überprüfen Sie den Dump, indem Sie ihn durch pg_restore des Containers leiten:

docker compose exec -T postgres pg_restore --list < /opt/backups/docker/mydb-20260319-120000.dump | head -10

Das gibt das Inhaltsverzeichnis aus, ohne etwas wiederherzustellen. Wenn die Datei beschädigt ist, gibt pg_restore einen Fehler aus. Wir verwenden docker compose exec -T, weil pg_restore im Container liegt, nicht auf dem Host (es sei denn, Sie installieren postgresql-client separat).

Wie sichere ich eine MySQL-Datenbank in Docker?

Verwenden Sie mysqldump mit --single-transaction für InnoDB-Tabellen. Das liefert einen konsistenten Snapshot, ohne die Datenbank zu sperren.

docker compose exec -T mysql mysqldump \
  -u root \
  -p"$MYSQL_ROOT_PASSWORD" \
  --single-transaction \
  --routines \
  --triggers \
  mydb > /opt/backups/docker/mydb-$(date +%Y%m%d-%H%M%S).sql

Das Flag -p hat kein Leerzeichen vor dem Passwort. --single-transaction verwendet ein konsistentes Lesen für InnoDB-Tabellen. --routines und --triggers schließen gespeicherte Prozeduren und Trigger ein, die mysqldump standardmäßig auslässt.

Prüfen Sie, ob der Dump nicht leer ist und mit der Abschlussmarkierung endet:

tail -5 /opt/backups/docker/mydb-20260319-120000.sql

Die Ausgabe zeigt -- Dump completed on YYYY-MM-DD HH:MM:SS sehen. Wenn die Datei abgeschnitten oder leer ist, ist der Dump fehlgeschlagen.

Wie automatisiere ich Docker-Volume-Backups mit offen/docker-volume-backup?

offen/docker-volume-backup läuft als Sidecar-Container in Ihrem Compose-Stack. Es sichert gemountete Volumes nach Zeitplan, verschlüsselt die Archive optional mit GPG und kann direkt zu S3-kompatiblem Speicher hochladen. Es kann auch Container während des Backups stoppen, um Konsistenz sicherzustellen.

Fügen Sie den Backup-Service zu Ihrer docker-compose.yml hinzu:

services:
  # ... your existing services ...

  backup:
    image: offen/docker-volume-backup:v2.47.2
    restart: unless-stopped
    env_file:
      - ./backup.env
    volumes:
      - myapp_data:/backup/myapp_data:ro
      - myapp_db:/backup/myapp_db:ro
      - /opt/backups/docker:/archive
      - /var/run/docker.sock:/var/run/docker.sock
    labels:
      - docker-volume-backup.stop-during-backup=false

Was das macht: Es mountet jedes zu sichernde Volume schreibgeschützt unter /backup/, mountet /archive für die lokale Backup-Speicherung und mountet den Docker-Socket, damit das Tool Container stoppen und neu starten kann, wenn es so konfiguriert ist. Der Image-Tag v2.47.2 fixiert die Version. Verwenden Sie nicht latest in der Produktion.

Sicherheitshinweis: Das Mounten des Docker-Sockets gibt dem Backup-Container volle Kontrolle über Docker auf dem Host. Das ist für die Stop-During-Backup-Funktion erforderlich. Wenn Sie diese Funktion nicht benötigen, können Sie ihn schreibgeschützt mounten (/var/run/docker.sock:/var/run/docker.sock:ro), was dem Tool erlaubt, Container-Labels zu lesen, aber es daran hindert, Container zu stoppen oder zu starten.

Erstellen Sie die Umgebungsdatei mit eingeschränkten Berechtigungen:

touch /opt/myapp/backup.env
chmod 600 /opt/myapp/backup.env

# /opt/myapp/backup.env
BACKUP_CRON_EXPRESSION=0 3 * * *
BACKUP_RETENTION_DAYS=7
BACKUP_COMPRESSION=gz
BACKUP_FILENAME=backup-%Y%m%dT%H%M%S.tar.gz

# GPG encryption (generate a strong passphrase)
GPG_PASSPHRASE=your-generated-passphrase-here

# S3-compatible storage (optional, see rclone section for alternative)
# AWS_S3_BUCKET_NAME=my-backups
# AWS_S3_PATH=myapp
# AWS_ENDPOINT=s3.eu-central-1.amazonaws.com
# AWS_ACCESS_KEY_ID=
# AWS_SECRET_ACCESS_KEY=

Generieren Sie die GPG-Passphrase:

openssl rand -base64 32

Bewahren Sie diese Passphrase sicher außerhalb des Servers auf. Wenn Sie sie verlieren, sind die verschlüsselten Backups nicht wiederherstellbar.

Wenn das Backup-Tool bestimmte Container während des Backups stoppen soll, um Dateisystemkonsistenz zu gewährleisten, fügen Sie diesen Services ein Label hinzu:

services:
  app:
    # ... your config ...
    labels:
      - docker-volume-backup.stop-during-backup=true

Starten Sie den Backup-Service:

docker compose up -d backup

Prüfen Sie, ob er läuft:

docker compose logs backup

Die Ausgabe zeigt eine Logzeile sehen, die den Cron-Zeitplan bestätigt. Warten Sie auf die erste planmäßige Ausführung oder lösen Sie ein manuelles Backup aus:

docker compose exec backup backup

Prüfen Sie, ob das Archiv erstellt wurde:

ls -lh /opt/backups/docker/

Wie plane ich Docker-Backups mit Cron?

Für Tar-basierte und Datenbank-Dump-Strategien übernimmt ein Shell-Skript mit Cron die Planung und Aufbewahrung. Das offen-Tool hat einen eigenen Scheduler; überspringen Sie diesen Abschnitt, wenn Sie nur dieses verwenden.

Erstellen Sie das Backup-Skript:

touch /opt/backups/docker-backup.sh
chmod 700 /opt/backups/docker-backup.sh

#!/usr/bin/env bash
# /opt/backups/docker-backup.sh
# Backs up Docker volumes and databases, removes old archives.

set -euo pipefail

BACKUP_DIR="/opt/backups/docker"
RETENTION_DAYS=7
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
COMPOSE_DIR="/opt/myapp"

# Load database credentials from env file
source "${COMPOSE_DIR}/.env"

cd "$COMPOSE_DIR"

# --- Tar backup of application data volume ---
docker compose stop app
docker run --rm \
  -v myapp_data:/source:ro \
  -v "${BACKUP_DIR}":/backup \
  alpine tar czf "/backup/myapp_data-${TIMESTAMP}.tar.gz" -C /source .
docker compose start app

# --- PostgreSQL dump (no downtime) ---
docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -Fc --no-owner --no-acl \
  "$POSTGRES_DB" > "${BACKUP_DIR}/${POSTGRES_DB}-${TIMESTAMP}.dump"

# --- Retention: delete backups older than N days ---
find "$BACKUP_DIR" -type f -name "*.tar.gz" -mtime +${RETENTION_DAYS} -delete
find "$BACKUP_DIR" -type f -name "*.dump" -mtime +${RETENTION_DAYS} -delete

echo "[$(date -Iseconds)] Backup completed successfully"

Überprüfen Sie, ob das Skript fehlerfrei läuft:

/opt/backups/docker-backup.sh

Prüfen Sie die Ausgabedateien:

ls -lh /opt/backups/docker/

Fügen Sie einen Cron-Eintrag hinzu, der täglich um 03:00 Uhr ausgeführt wird und die Ausgabe protokolliert:

crontab -e

0 3 * * * /opt/backups/docker-backup.sh >> /var/log/docker-backup.log 2>&1

Das 2>&1 leitet stderr in dieselbe Logdatei um, sodass Fehler erfasst werden. Prüfen Sie das Log nach der ersten Ausführung:

cat /var/log/docker-backup.log

Wenn das Skript fehlschlägt, schluckt Cron den Fehler stillschweigend, sofern Sie die Ausgabe nicht umleiten. Um bei Fehlern E-Mail-Benachrichtigungen zu erhalten, fügen Sie diesen Wrapper hinzu:

0 3 * * * /opt/backups/docker-backup.sh >> /var/log/docker-backup.log 2>&1 || echo "Docker backup failed on $(hostname)" | mail -s "BACKUP FAILED" you@example.com

Das erfordert mailutils oder ein ähnliches Paket. Passen Sie die Empfängeradresse an.

Wie kopiere ich Docker-Backups mit rclone zu S3-kompatiblem Speicher?

Lokale Backups schützen vor Anwendungsfehlern. Sie schützen nicht vor Festplattenausfällen oder einem kompromittierten Server. Sie brauchen Off-Site-Kopien. rclone funktioniert mit jedem S3-kompatiblen Speicher: AWS S3, Backblaze B2, Wasabi, MinIO, OVH Object Storage, Scaleway und andere.

Installieren Sie rclone:

apt update && apt install -y rclone

Konfigurieren Sie ein S3-kompatibles Remote:

rclone config

Folgen Sie den interaktiven Eingabeaufforderungen:

  1. n für ein neues Remote
  2. Nennen Sie es s3backup
  3. Wählen Sie s3 (Amazon S3 Compliant Storage Providers)
  4. Wählen Sie Ihren Anbieter (oder „Any other S3 compatible provider")
  5. Geben Sie Ihren Access Key und Secret Key ein
  6. Setzen Sie die Region und Endpoint-URL Ihres Anbieters
  7. Belassen Sie die übrigen Optionen auf Standardwerten

Prüfen Sie, ob das Remote funktioniert:

rclone lsd s3backup:

Das listet Ihre Buckets auf. Bei einem Fehler stimmen Ihre Zugangsdaten oder der Endpoint nicht.

Erstellen Sie einen Bucket für Backups (wenn Ihr Anbieter das via rclone unterstützt):

rclone mkdir s3backup:my-docker-backups

Synchronisieren Sie Ihr lokales Backup-Verzeichnis mit dem Bucket:

rclone sync /opt/backups/docker s3backup:my-docker-backups/$(hostname)/ \
  --transfers 4 \
  --checkers 8 \
  --log-file /var/log/rclone-backup.log \
  --log-level INFO

Was das macht: sync gleicht das Remote mit dem lokalen Verzeichnis ab. Lokal gelöschte Dateien (durch die Aufbewahrungsrichtlinie) werden auch remote gelöscht. Das Präfix $(hostname) trennt Backups, wenn Sie mehrere Server haben.

Überprüfen Sie den Upload:

rclone ls s3backup:my-docker-backups/$(hostname)/

Die Ausgabe zeigt Ihre Backup-Dateien mit Größen sehen, die den lokalen Kopien entsprechen.

Fügen Sie rclone sync zum Backup-Skript oder als separaten Cron-Eintrag hinzu, der nach dem Backup läuft:

30 3 * * * rclone sync /opt/backups/docker s3backup:my-docker-backups/$(hostname)/ --transfers 4 --log-file /var/log/rclone-backup.log --log-level INFO

Das läuft um 03:30 Uhr und gibt dem Backup-Job um 03:00 Uhr Zeit zum Abschließen.

Schützen Sie die rclone-Konfiguration: Sie enthält Ihre S3-Zugangsdaten.

chmod 600 ~/.config/rclone/rclone.conf
ls -la ~/.config/rclone/rclone.conf

Die Ausgabe zeigt die Berechtigungen -rw------- sehen. Nur root kann diese Datei lesen.

Sollte ich Container vor dem Backup von Docker-Volumes stoppen?

Das hängt vom Inhalt des Volumes ab. Hier einen Fehler zu machen, ist die häufigste Ursache für beschädigte Backups.

Datenbanken (PostgreSQL, MySQL, MongoDB): Archivieren Sie nie ein laufendes Datenbank-Volume per tar. Die Dateien auf der Festplatte repräsentieren einen laufenden Transaktionszustand. Ein tar dieser Dateien ist wie das Fotokopieren eines Buches, während jemand Kapitel umschreibt. Das Ergebnis ist intern inkonsistent. Verwenden Sie stattdessen pg_dump, mysqldump oder mongodump. Diese Tools erzeugen einen transaktionskonsistenten Snapshot, während die Datenbank weiterläuft.

Anwendungsdaten (Uploads, statische Dateien, Konfiguration): Tar ist sicher, wenn die Anwendung einen kurzen Stopp toleriert. Wenn die Anwendung kontinuierlich schreibt und Sie sie nicht stoppen können, kann das Tar-Archiv teilweise geschriebene Dateien enthalten. Für die meisten Webanwendungen ist ein 2-Sekunden-Stopp während eines Backups um 3 Uhr morgens akzeptabel.

Redis, Key-Value-Stores: Redis schreibt periodisch RDB-Snapshots auf die Festplatte. Lösen Sie vor dem Tarring des Volumes ein BGSAVE aus und warten Sie, bis es abgeschlossen ist. Das gibt Ihnen einen konsistenten Snapshot, ohne Redis zu stoppen.

docker compose exec redis redis-cli BGSAVE
# Wait a few seconds
docker compose exec redis redis-cli LASTSAVE

Die sichere Standardoption: Im Zweifelsfall stoppen Sie den Container, sichern, starten neu. Kurze Ausfallzeit ist besser als beschädigte Backups.

Wie stelle ich Docker-Volumes auf einem neuen VPS wieder her?

Das ist die Prozedur, die beweist, dass Ihre Backups funktionieren. Installieren Sie Docker auf einem frischen Server, übertragen Sie die Backup-Dateien, erstellen Sie Volumes neu, stellen Sie Daten wieder her und prüfen Sie, ob die Anwendung läuft.

1. Docker auf dem neuen VPS installieren

apt update && apt install -y ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | tee /etc/apt/sources.list.d/docker.list > /dev/null

apt update && apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Überprüfen:

docker --version && docker compose version

2. Backup-Dateien auf den neuen Server übertragen

Von Ihrem lokalen Rechner oder dem alten Server:

rsync -avz --progress /opt/backups/docker/ root@NEW_SERVER_IP:/opt/backups/docker/

Oder von S3 herunterladen:

# On the new server, install and configure rclone first
apt install -y rclone
# Re-run rclone config with the same credentials
rclone copy s3backup:my-docker-backups/OLD_HOSTNAME/ /opt/backups/docker/

Prüfen Sie, ob die Dateien angekommen sind:

ls -lh /opt/backups/docker/

3. Compose- und env-Dateien kopieren

rsync -avz /opt/myapp/ root@NEW_SERVER_IP:/opt/myapp/

Oder stellen Sie sie aus Ihrem Git-Repository wieder her. Ihre docker-compose.yml und .env sollten versioniert sein. Die .env-Datei sollte in .gitignore stehen und separat gesichert werden.

4. Das tar-basierte Volume wiederherstellen

# Create the volume (Docker Compose will also do this on first `up`,
# but creating it explicitly lets us restore data before starting services)
docker volume create myapp_data

# Restore from archive
docker run --rm \
  -v myapp_data:/target \
  -v /opt/backups/docker:/backup:ro \
  alpine sh -c "cd /target && tar xzf /backup/myapp_data-20260319-030000.tar.gz"

Was das macht: Es erstellt das benannte Volume und startet dann einen temporären Container, der das Archiv darin entpackt. Das Backup-Verzeichnis wird schreibgeschützt gemountet, um Unfälle zu vermeiden.

Überprüfen Sie die wiederhergestellten Daten:

docker run --rm -v myapp_data:/data:ro alpine ls -la /data/

Die Ausgabe zeigt dieselben Dateien sehen wie im ursprünglichen Volume.

5. Die PostgreSQL-Datenbank wiederherstellen

Starten Sie nur den Datenbank-Container:

cd /opt/myapp
docker compose up -d postgres

Warten Sie, bis er bereit ist:

docker compose logs -f postgres
# Wait until you see "database system is ready to accept connections"

Stellen Sie den Dump wieder her:

docker compose exec -T postgres pg_restore \
  -U "$POSTGRES_USER" \
  -d "$POSTGRES_DB" \
  --clean \
  --if-exists \
  --no-owner \
  --no-acl \
  < /opt/backups/docker/mydb-20260319-030000.dump

Was das macht: --clean löscht vorhandene Objekte vor der Neuerstellung. --if-exists verhindert Fehler, wenn die Objekte noch nicht existieren. Das macht die Wiederherstellung idempotent.

Überprüfen Sie die Daten:

docker compose exec postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "\dt"

Die Ausgabe zeigt Ihre Tabellen aufgelistet sehen. Führen Sie eine schnelle Zeilenzählung auf einer bekannten Tabelle durch:

docker compose exec postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "SELECT count(*) FROM your_table;"

6. Alle Services starten und prüfen

docker compose up -d

Prüfen Sie, ob alle Container laufen:

docker compose ps

Jeder Service sollte Up oder running anzeigen. Wenn ein Container in einer Neustart-Schleife steckt, prüfen Sie seine Logs:

docker compose logs --tail 50 service_name

Testen Sie die Anwendung von außerhalb des Servers. Von Ihrem lokalen Rechner:

curl -I http://NEW_SERVER_IP:PORT

Die Ausgabe zeigt eine gültige HTTP-Antwort erhalten. Wenn die Anwendung einen Health-Check-Endpoint hat, rufen Sie diesen auf:

curl http://NEW_SERVER_IP:PORT/health

Mehr zu Health Checks finden Sie in unserer Anleitung zu Docker Compose Resource Limits und Health Checks.

Wie überprüfe ich, ob ein Docker-Volume-Backup gültig ist?

Ein Backup, das Sie nie getestet haben, ist ein Risiko. Führen Sie diese Prüfungen regelmäßig durch, nicht nur im Notfall.

Archivintegrität prüfen:

# For tar.gz files
gzip -t /opt/backups/docker/myapp_data-20260319-030000.tar.gz && echo "OK" || echo "CORRUPT"

Archivinhalt prüfen:

tar tzf /opt/backups/docker/myapp_data-20260319-030000.tar.gz | wc -l

Vergleichen Sie die Dateianzahl mit einem bekanntermaßen guten Backup. Ein plötzlicher Rückgang der Dateianzahl deutet auf ein Problem hin.

Restore in ein Wegwerf-Volume testen:

docker volume create test_restore
docker run --rm \
  -v test_restore:/target \
  -v /opt/backups/docker:/backup:ro \
  alpine sh -c "cd /target && tar xzf /backup/myapp_data-20260319-030000.tar.gz"

# Inspect the restored data
docker run --rm -v test_restore:/data:ro alpine ls -la /data/

# Clean up
docker volume rm test_restore

Datenbank-Dump überprüfen:

docker compose exec -T postgres pg_restore --list < /opt/backups/docker/mydb-20260319-030000.dump | wc -l

Wenn das eine Anzahl von Objekten (Tabellen, Indizes, Sequenzen) zurückgibt, ist der Dump lesbar. Bei einem Fehler ist die Datei beschädigt.

Prüfsummen für die Langzeitaufbewahrung generieren:

sha256sum /opt/backups/docker/*.tar.gz /opt/backups/docker/*.dump > /opt/backups/docker/checksums-$(date +%Y%m%d).sha256

Laden Sie die Prüfsummendatei zusammen mit den Backups hoch. Vor der Wiederherstellung überprüfen:

sha256sum -c /opt/backups/docker/checksums-20260319.sha256

Fehlerbehebung

„Permission denied" beim Erstellen des Tar-Archivs: Der temporäre Container läuft standardmäßig als root. Das bedeutet meistens, dass das Backup-Verzeichnis nicht existiert oder falsche Berechtigungen hat. Führen Sie ls -la /opt/backups/ aus und prüfen Sie, ob das Unterverzeichnis docker mit den Berechtigungen 700 existiert.

pg_dump/pg_restore hängt: Sie haben wahrscheinlich das Flag -T in docker compose exec vergessen. Ohne -T versucht exec, ein TTY zuzuweisen, was bei der Ausgabeumleitung blockiert. Verwenden Sie docker compose exec -T.

Backup-Dateien sind 0 Byte groß: Der Container hat an einen anderen Pfad geschrieben als erwartet. Überprüfen Sie, ob der Volume-Name in docker volume ls mit dem im -v-Flag verwendeten übereinstimmt. Benannte Volumes unterscheiden Groß- und Kleinschreibung.

rclone sync bricht mit Timeout ab: Große initiale Synchronisierungen können Standard-Timeouts überschreiten. Fügen Sie --timeout 30m und --retries 3 zum rclone-Befehl hinzu.

offen/docker-volume-backup läuft nicht nach Zeitplan: Prüfen Sie die Syntax von BACKUP_CRON_EXPRESSION. Das Tool verwendet die Standard-Cron-Syntax mit 5 Feldern. Führen Sie docker compose logs backup aus und suchen Sie nach Parse-Fehlern.

Wiederhergestellte Datenbank hat falsche Berechtigungen: Sie haben einen Dump ohne --no-owner verwendet. Der Dump versucht, den Besitzer auf den ursprünglichen Benutzer zu setzen, der auf dem neuen Server möglicherweise nicht existiert. Erstellen Sie den Dump erneut mit --no-owner --no-acl oder führen Sie REASSIGN OWNED BY old_user TO new_user; in psql aus.

Weiterführende Themen

  • Vollständige Docker-Produktionseinrichtung
  • Health Checks, die nach einer Wiederherstellung bestätigen, dass Services laufen
  • Docker-CLI-Grundlagen

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.

Bereit, es selbst auszuprobieren?

Betreiben Sie Docker mit automatisierten Backups auf Ihrem VPS.

VPS-Angebote ansehen