Autorestic mit Docker Compose: restic-Backups und Restore

Autorestic ist ein konfigurationsgesteuerter Wrapper um restic. Statt komplizierte restic-Optionen für mehrere Quellen und Ziele zu wiederholen, beschreiben Sie Standorte und Backends in YAML und starten klar benannte Aufträge. Der Dienst besitzt keine Weboberfläche: Im hier getesteten Betrieb läuft das offizielle Docker-Image nur für einzelne Befehle. Die Anleitung führt Sie vom lokalen Repository über die Wiederherstellung gelöschter Dateien bis zu Integritätsprüfung und Updates. Getestet am 14. Oktober 2026 mit Autorestic 1.8.3 und dem enthaltenen restic 0.17.0.

Voraussetzungen

Planen Sie einen Linux-Host mit mindestens zwei CPU-Kernen, 4 GB RAM, Docker Engine und Compose-Plugin ein. Der tatsächliche Ressourcenbedarf hängt von Dateimenge und Änderungsrate ab. Autorestic benötigt für den gezeigten lokalen Betrieb weder GPU noch eine öffentliche IPv4-Adresse, Domain oder Netzwerkportfreigabe. Für produktive Sicherungen brauchen Sie zusätzlich Speicher auf einem unabhängigen System, etwa einem NAS oder einem geeigneten externen Backend, und einen geschützten Passwortmanager.

Arbeiten Sie in einem eigenen Verzeichnis wie /opt/autorestic. Docker-Zugriff erlaubt weitreichende Eingriffe in den Host und sollte nur vertrauenswürdigen Administratoren offenstehen. Die Konfiguration enthält den Schlüssel, der den Zugriff auf die verschlüsselten Repository-Daten ermöglicht. Schützen Sie Datei und Kopien vor unbefugtem Zugriff und legen Sie mindestens eine Wiederherstellungskopie außerhalb dieses Rechners ab.

Schritt 1: Projektordner und Compose-Datei anlegen

Autorestic wird hier als CLI-Werkzeug aufgerufen, nicht als dauerhaft laufender Server. Daher veröffentlicht die Compose-Datei keinen Port und benötigt weder Reverse Proxy noch Weblogin. Der offizielle Docker-Eintrag lautet cupcakearmy/autorestic. Für den Test war Docker Hub vorübergehend mit HTTP 429 gedrosselt; das offizielle Image wurde über den Spiegel mirror.gcr.io abgerufen. Der Buildworkflow veröffentlicht Versionstags auf Docker Hub. Für Ihre Produktion pinnen Sie nach Prüfung Image-Referenz und Digest.

mkdir -p /opt/autorestic/{source,repo,restore,config}
cd /opt/autorestic

services:
  backup:
    image: cupcakearmy/autorestic:1.8.3
    volumes:
      - ./source:/source:ro
      - ./repo:/repo
      - ./restore:/restore
      - ./config:/config

Eckdatum	Wert
Image	cupcakearmy/autorestic, Version 1.8.3
Enthaltenes Backup-Programm	restic 0.17.0, im Test ausgelesen
Port	Keiner veröffentlicht
Quelle	source nach /source, schreibgeschützt
Persistente Ordner	repo, restore und config
Konfiguration	/config/autorestic.yml

docker compose config
docker compose pull
docker compose run --rm backup autorestic --version
docker compose run --rm backup restic version
docker image inspect cupcakearmy/autorestic:1.8.3 --format '{{json .RepoDigests}}'

Verifizieren: Compose muss die Mounts fehlerfrei anzeigen. Im Praxistest meldete Autorestic Version 1.8.3 und restic Version 0.17.0. Der geprüfte Spiegel-Digest lautete sha256:0a826ea59ca452dadae50e618c0a14800450c920d22da0e35cb23e7a8be36d1f; der Spiegelpräfix gehört zur tatsächlich abgerufenen Image-Referenz.

Schritt 2: Standort und Repository konfigurieren

Autorestic verwendet die YAML-Konfiguration standardmäßig im aktuellen Verzeichnis. Ein expliziter Pfad verhindert, dass ein anderer Arbeitsordner versehentlich ein fremdes oder leeres Profil lädt. Legen Sie zuerst folgende Grundkonfiguration in config/autorestic.yml ab. Der Backendpfad bezeichnet den Repositoryordner im Container.

version: 2
locations:
  documents:
    from: /source
    to: local
backends:
  local:
    type: local
    path: /repo

Generieren Sie einen langen zufälligen Schlüssel, ohne ihn in die Shell-Historie oder ein Protokoll zu schreiben. Ergänzen Sie ihn unter dem Backend. Autorestic dokumentiert, dass dieser Schlüssel für verschlüsselte Daten nötig ist und empfiehlt ausdrücklich eine externe Kopie der Konfiguration. Schützen Sie das File mit restriktiven Berechtigungen. In der Praxis gehören Zugangsdaten bevorzugt in ein geeignetes Secret-Management und nicht in unverschlüsselte Versionsverwaltung.

umask 077
key=$(head -c 48 /dev/urandom | base64)
printf '    key: "%s"\n' "$key" >> config/autorestic.yml
chmod 600 config/autorestic.yml
unset key

Starten Sie die Funktion aus dem Projektverzeichnis. Sie ruft das CLI mit absolutem Konfigurationspfad auf. Der erste Prüfauftrag initialisiert ein noch nicht existierendes Backend. Im Test meldete Autorestic Initializing backend "local"... und Everything is fine..

r() { docker compose run --rm backup autorestic -c /config/autorestic.yml "$@"; }
r check

Verifizieren: Die Prüfung endet mit Everything is fine.. Kontrollieren Sie Dateirechte und sichern Sie Konfiguration samt Schlüssel außerhalb des Servers. Ohne diese Kopie riskieren Sie bei Verlust des Projektordners den dauerhaften Verlust des Zugangs zu verschlüsselten Daten.

Schritt 3: Beispielbestand sichern und Snapshot prüfen

Testen Sie zunächst mit Beispieldateien statt produktiven Verzeichnissen. Erstellen Sie eine kleine Textdatei, eine Datei in einem Unterverzeichnis und Binärdaten. Schreiben Sie vor dem Backup SHA256-Prüfsummen in eine separate Datei. Dadurch vergleichen Sie beim Restore den Dateiinhalt bytegenau.

printf 'Wiederherstellung prüfen\n' > source/marker.txt
mkdir -p source/sub
printf 'Datei im Unterordner\n' > source/sub/nested.txt
head -c 65536 /dev/urandom > source/binary.dat
sha256sum source/marker.txt source/sub/nested.txt source/binary.dat > expected.sha256
r backup -a
r exec -a -- snapshots
r exec -a -- check --read-data
r backup -a

Die Autorestic-Befehle backup -a und exec -a -- arbeiten über alle Standorte beziehungsweise Backends. Das Präfix -- trennt Autorestic-Optionen von Argumenten, die an restic weitergereicht werden. In der Ausgabe erscheinen für die Sicherung der Standortname und das Backend. Der Wiederholungsauftrag prüft zugleich, dass eine weitere Ausführung möglich ist.

Bei Datenbanken genügt eine Dateikopie häufig nicht. Erzeugen Sie vor dem Backup einen konsistenten Dump oder verwenden Sie eine anwendungsspezifische Sicherungsmethode. Übertragen Sie Dump, Konfiguration und Anhänge gemeinsam, wenn die Anwendung sie für einen vollständigen Stand benötigt. Das Repository ersetzt keine Prüfung auf Datenbankkonsistenz.

Verifizieren: Der Backup-Auftrag muss für documents mit Done enden. Die anschließende Check-Ausführung darf keinen Fehler melden. Prüfen Sie, ob der Standort weiterhin auf das vorgesehene Backend zeigt und nicht versehentlich ein leeres Profil verwendet wurde.

Schritt 4: Gelöschte Dateien wiederherstellen

Autorestic besitzt einen eigenen Restore-Aufruf, der den gewählten Standort, Backend und Zielordner entgegennimmt. Verwenden Sie dafür einen leeren, separaten Ordner. Ein erzwungener Restore kann vorhandene Dateien überschreiben; führen Sie ihn niemals blind auf produktive Quelldaten aus. Der Test stellte den neuesten Snapshot nach /restore wieder her. Der ursprüngliche Quellpfad lag anschließend unter restore/source.

r restore -l documents --to /restore --force
find restore -type f -print
rm source/marker.txt source/sub/nested.txt source/binary.dat
cp restore/source/marker.txt source/marker.txt
cp restore/source/sub/nested.txt source/sub/nested.txt
cp restore/source/binary.dat source/binary.dat
sha256sum -c expected.sha256
r exec -a -- check --read-data

Nutzen Sie --force nur, wenn das Ziel für den Test angelegt wurde und Sie den möglichen Überschreibeffekt verstanden haben. Bei echten Wiederherstellungen lesen Sie vorab die genaue Restore-Dokumentation und beginnen mit einem isolierten Ziel. Erst nach Sichtprüfung übernehmen Sie Dateien in produktive Pfade.

Verifizieren: Im Test meldete SHA256 für alle drei nachweislich gelöschten Beispieldateien OK. Die anschließende Repository-Prüfung endete erfolgreich. Damit wurden Sicherung, Wiederherstellung und Inhaltsgleichheit praktisch belegt.

Schritt 5: Aufbewahrung, Planung und Betrieb

Autorestic kann Standorte mit Cron-Zeitplänen konfigurieren und Backup-Aufträge per Scheduler ausführen. Legen Sie Zeitpunkte passend zu Änderungsrate, Betriebszeiten und Wiederherstellungsziel fest. Protokollieren Sie Exitcodes und Alarmieren Sie bei fehlgeschlagenen oder ausbleibenden Läufen. Im Test wurde der Backup-Aufruf manuell ausgelöst; automatische Zeitplanung sollten Sie an Ihren Betrieb anpassen und anschließend separat auf erwartete Ausführungszeiten kontrollieren.

Aufbewahrungs- und Prune-Optionen legt Autorestic standortbezogen unter options.forget fest. Prüfen Sie vor einer Löschung die genaue Konfiguration und testen Sie die Wirkung an einer Repository-Kopie. Alte Stände können die einzige Kopie eines erst spät entdeckten Fehlers sein. Begrenzen Sie Aufbewahrung nicht allein nach dem verfügbaren Speicher, sondern nach fachlichen Anforderungen und Wiederherstellungsfristen.

Ein lokales Repository auf derselben Platte wie die Quelldaten ist kein vollständiges Sicherungskonzept. Ergänzen Sie einen unabhängigen Datenträger oder ein externes Backend, und schützen Sie dessen Zugangsdaten getrennt. Eine Kopie, die unter denselben Administratorkonten jederzeit löschbar ist, bietet nur eingeschränkten Schutz vor einem kompromittierten Server.

Verifizieren: Lesen Sie Konfiguration und letzten erfolgreichen Snapshot aus, prüfen Sie den Speicherstand und testen Sie mindestens eine Wiederherstellung regelmäßig. Erst ein vollständig unabhängiger Speicherort schützt gegen den Ausfall des Hosts.

Schritt 6: Updates und Versionskontrolle

Der Tag latest kann sich ändern. Verwenden Sie für den Betrieb einen geprüften Versions-Tag und danach möglichst einen Digest. Die getestete Autorestic-Version 1.8.3 enthielt restic 0.17.0; protokollieren Sie beide Werte, da ein Wrapper-Update auch das eingebettete Werkzeug verändern kann. Vor Updates lesen Sie Release-Hinweise und behalten einen funktionierenden Rückweg.

docker compose pull
docker compose run --rm backup autorestic --version
docker compose run --rm backup restic version
r check
r exec -a -- check --read-data

Testen Sie größere Änderungen zunächst gegen eine Kopie des Repositorys. Nach dem Update führen Sie einen Backup-Auftrag und einen Restore-Test aus. Konfigurationsänderungen kontrollieren Sie mit einem kleinen Teststandort, bevor Sie Retention oder Backendpfade für produktive Daten ändern. Löschen Sie niemals das einzige Repository, um einen vermeintlich sauberen Neustart zu erzwingen.

Verifizieren: Beide Versionsbefehle zeigen die gewünschte Version. Check und vollständige Datenprüfung laufen fehlerfrei. Nach einem erfolgreichen Test-Restore pinnen Sie den Digest für den geplanten Betrieb fest.

Troubleshooting

• Docker Hub liefert 429: Im Test meldete die Registry 429 Too Many Requests. Das war ein Pull-Limit, kein Beweis für einen ungültigen Tag. Später erneut abrufen oder einen vertrauenswürdigen Spiegel verwenden.
• Ungültige Konfigurationsoption: Das Fehlerbild locations[documents] has invalid keys: forgetoption entstand durch eine falsch platzierte Retention-Einstellung. Die Standortstruktur verlangt den Schlüssel options; prüfen Sie das offizielle Schema.
• Schlüssel fehlt: Bewahren Sie Konfigurationsdatei und Schlüssel sicher außerhalb des Datenbestands auf. Ohne Schlüssel kein Zugriff auf verschlüsselte Inhalte.
• Dateien im Restore nicht gefunden: Prüfen Sie zunächst die vollständige Pfadstruktur. Das Quellverzeichnis wurde unter restore/source angelegt.
• Standort nicht vorhanden: Der Negativtest ergab Error: invalid location "missing". Kontrollieren Sie den Namen in der YAML-Datei.

Häufige Fragen

Hat Autorestic eine Weboberfläche?

Nein. Es ist ein Kommandozeilenwerkzeug, das Konfiguration und restic-Aufträge bündelt. Eine Weboberfläche oder Browser-Screenshots wären für diesen getesteten Betrieb unpassend.

Kann ich Docker-Volumes direkt sichern?

Ja. Die offizielle Docker-Dokumentation beschreibt einen Standort vom Typ volume. Das betreffende Docker-Volume muss beim Backup und Restore existieren.

Ist ein Backup auf derselben Maschine ausreichend?

Nein. Ein unabhängiges Ziel und regelmäßig geprüfte Wiederherstellung gehören zum Sicherungskonzept.

Fazit

Autorestic vereinfacht wiederholbare restic-Aufträge durch eine gemeinsame YAML-Konfiguration. Der Docker-Betrieb bleibt bewusst einfach und benötigt keinen offenen Port. Entscheidend sind die geschützte Schlüsselkopie, überprüfte Aufbewahrung und ein echter Restore-Test. Im Praxistest wurden drei gelöschte Dateien wiederhergestellt und ihre SHA256-Prüfsummen bestätigt.

Weiterführende Anleitungen und Quellen

• Offizielles Autorestic-Repository
• Autorestic Release 1.8.3
• Offizielle Dokumentation
• Docker-Nutzung
• Konfigurationsformat und Schlüsselhinweis
• restic-Backups mit Zeitplanung