Restic Docker Backup: Volumes sicher sichern

Ein Restic Docker Backup sichert die Daten deiner Container, indem Restic die relevanten Bind-Mount-Verzeichnisse oder Volumes liest und verschlüsselte Snapshots in ein Repository schreibt. Mit Docker Compose trennst du Anwendung, Sicherungsziel und Zugangsdaten sauber; entscheidend ist aber, dass du eine Wiederherstellung regelmäßig prüfst.

Stand: 09.10.2026

Auf einen Blick

• Restic erstellt verschlüsselte Snapshots und erkennt unveränderte Daten erneut.
• Für Container sind persistente Daten wichtiger als das Container-Dateisystem.
• Ein Backup ohne getestete Wiederherstellung ist keine belastbare Sicherung.
• Passwörter und Repository-Adresse gehören nicht in die Compose-Datei.

Was ist ein Restic Docker Backup?

Ein Restic Docker Backup ist eine Sicherung persistenter Docker-Daten mit dem Backup-Programm Restic. Restic speichert einen Verzeichnisstand als Snapshot in einem Repository; laut Restic-Dokumentation wird bereits vorhandener Inhalt nur einmal gespeichert. Deshalb eignen sich wiederkehrende Sicherungen für Datenverzeichnisse und Docker-Volumes.

Ein Container selbst ist normalerweise nicht das Ziel. Das Image lässt sich wieder beschaffen oder neu bauen. Wichtig sind dagegen Datenbanken, Uploads, Konfigurationen und Schlüssel in persistenten Mounts. Prüfe zuerst deine Compose-Datei: Ein Pfad links vom Doppelpunkt ist ein Bind Mount; ein benannter Eintrag wie app_data:/var/lib/app ist ein Volume.

Wenn du erst ein solides Compose-Setup brauchst, hilft der Beitrag zu den Docker-Compose-Grundlagen. Für den laufenden Betrieb ergänzt ein Docker-Healthcheck die Sicherung, ersetzt sie aber nicht.

Welche Daten musst du tatsächlich sichern?

Sichere ausschließlich Daten, die nach einem Neuaufsetzen nicht automatisch wieder entstehen. Docker empfiehlt Volumes für persistente, von Containern erzeugte Daten; ein Volume bleibt auch erhalten, wenn ein Container gelöscht wird. Die Details beschreibt die offizielle Docker-Dokumentation zu Volumes.

Bei Datenbanken reicht ein Dateikopie-Backup während des laufenden Betriebs nicht immer aus. Lies deshalb die Sicherungshinweise der jeweiligen Datenbank. Restic kann laut eigener Dokumentation auch die Ausgabe eines Befehls mit --stdin-from-command sichern; schlägt der Befehl fehl, wird kein Snapshot erstellt. Das eignet sich etwa für einen vorgesehenen Datenbank-Dump.

Restic Docker Backup mit Compose einrichten

Das folgende Muster sichert einen bereits vorhandenen Host-Ordner ./data in ein lokales Repository unter ./restic-repository. Es ist absichtlich als manuell gestarteter Dienst angelegt. So kontrollierst du den ersten Lauf, bevor du ihn über den Scheduler deines Hosts automatisierst.

services:
  restic:
    image: restic/restic:latest
    environment:
      RESTIC_REPOSITORY: /repository
      RESTIC_PASSWORD_FILE: /run/secrets/restic_password
    volumes:
      - ./data:/data:ro
      - ./restic-repository:/repository
    secrets:
      - restic_password

secrets:
  restic_password:
    file: ./secrets/restic_password

Lege die Passwortdatei mit einem langen, einzigartigen Passwort an und behandle sie wie einen Schlüssel. Restic dokumentiert RESTIC_PASSWORD_FILE ausdrücklich als Möglichkeit für automatisierte Läufe. Geht dieses Passwort verloren, sind die Daten im Repository laut Dokumentation nicht mehr zugänglich.

Erstelle anschließend das Repository einmalig. Der Befehl nutzt die im Dienst gesetzten Variablen und schreibt kein Passwort in die Shell-Historie:

docker compose run --rm restic init

Danach erzeugst du den ersten Snapshot. Der Mount /data ist absichtlich schreibgeschützt eingebunden. Dadurch kann der Backup-Container die Quelle lesen, aber nicht verändern.

docker compose run --rm restic backup /data --tag compose

Die offizielle Restic-Anleitung zeigt restic backup als Standardbefehl und empfiehlt danach restic check, um die interne Struktur des Repositorys zu prüfen. Führe deshalb direkt danach aus:

docker compose run --rm restic snapshots
docker compose run --rm restic check

Wie sicherst du Docker-Volumes statt Bind Mounts?

Bei einem benannten Volume muss der Backup-Container dasselbe Volume einhängen. Deklariere das Volume als extern, wenn es bereits von einem anderen Compose-Projekt verwaltet wird. Damit versucht Compose nicht, es neu anzulegen.

services:
  restic:
    image: restic/restic:latest
    environment:
      RESTIC_REPOSITORY: /repository
      RESTIC_PASSWORD_FILE: /run/secrets/restic_password
    volumes:
      - app_data:/source:ro
      - ./restic-repository:/repository
    secrets:
      - restic_password

volumes:
  app_data:
    external: true

secrets:
  restic_password:
    file: ./secrets/restic_password

Danach sicherst du /source statt /data. Den tatsächlichen Volume-Namen findest du mit docker volume ls. Docker unterscheidet benannte und anonyme Volumes; verwende für wichtige Daten daher bewusst benannte Volumes. Das macht Zuordnung und Wiederherstellung nachvollziehbar.

Wie prüfst du die Wiederherstellung?

Eine erfolgreiche Ausgabe von backup beweist nur, dass ein Snapshot geschrieben wurde. Prüfe zusätzlich, ob sich Daten an einen leeren Zielpfad zurückholen lassen. Restic stellt Snapshots mit restore wieder her; wähle für den Test ein Verzeichnis, das nicht von deiner Anwendung verwendet wird.

mkdir -p ./restore-test
docker compose run --rm -v ./restore-test:/restore restic restore latest --target /restore

Kontrolliere danach Dateinamen, Größen und bei Anwendungen auch, ob sich die wiederhergestellte Konfiguration öffnen lässt. Für produktive Datenbanken gehört ein dokumentierter Dump- und Restore-Test dazu. Nutzt du etwa Nextcloud, beachte zusätzlich die Punkte aus der Nextcloud-Upgrade-Checkliste, insbesondere Datenbank und Konfiguration.

Typische Fehler beim Restic Docker Backup

Der häufigste Fehler ist das falsche Sichern des Container-Dateisystems statt der persistenten Daten. Prüfe daher vor dem ersten Lauf die Mounts der Anwendung. Außerdem darf das Repository nicht im Quellpfad liegen, sonst kann Restic seine eigenen Sicherungsdaten erneut einlesen.

Ein weiterer Fehler ist ein Backup in dasselbe Volume oder auf dieselbe Platte ohne zweite Kopie. Das schützt nicht vor dem Ausfall dieses Speichers. Lege das Repository deshalb auf einen getrennten Speicherort oder nutze einen von Restic unterstützten Remote-Backend-Typ. Die Restic-Dokumentation zu Repositories beschreibt lokale sowie entfernte Ziele wie SFTP und S3-kompatiblen Speicher.

Schließlich sollte die Automatisierung nicht mehrere Läufe gleichzeitig starten. Restic weist bei geplanten Backups darauf hin, bereits laufende Instanzen zu erkennen. Richte die Zeitplanung erst ein, wenn Initialisierung, Backup, check und Restore-Test funktioniert haben.

Fazit

Ein Restic Docker Backup beginnt mit der richtigen Auswahl persistenter Daten und endet erst mit einem getesteten Restore. Compose bietet dafür eine klar getrennte Umgebung: Quelle nur lesbar, Repository separat und Passwort außerhalb der Konfiguration. Ergänze die manuelle Routine erst danach um eine verlässliche Zeitplanung.

Quellen

• Restic: Backing up
• Restic: Preparing a new repository
• Docker Docs: Volumes

Häufige Fragen