Rustic mit Docker Compose: verschlüsselte Backups und geprüfter Restore

Rustic sichert Dateien verschlüsselt und dedupliziert in einem Repository, dessen Format mit restic kompatibel ist. Die in Rust geschriebene Anwendung eignet sich für Administratoren, die Sicherungen nachvollziehbar über Konfiguration und Kommandozeile betreiben möchten. Diese Anleitung verwendet das offizielle Docker-Image und einen abgeschlossenen Projektordner. Sie richten ein Repository ein, erstellen wiederholte Sicherungen und stellen gelöschte Dateien mit anschließendem Prüfsummenvergleich wieder her. Grundlage ist Rustic 0.11.4, praktisch geprüft am 14. Oktober 2026.

Voraussetzungen

Planen Sie einen Linux-Host mit zwei CPU-Kernen, 4 GB RAM, Docker Engine und Compose-Plugin ein. Diese Ausstattung ist eine sinnvolle Ausgangsbasis für kleine Dateibestände, keine gemessene Obergrenze für große Archive. Der offizielle Dockerfile berücksichtigt x86-64 und ARM64. Sie brauchen Platz für Quelldaten, Repository und einen vollständigen Test-Restore. Bei überwiegend bereits komprimierten Dateien sollten Sie nicht auf große Einsparungen durch Kompression hoffen.

Verwenden Sie einen Administratorzugang für Docker und ein separates Verzeichnis, beispielsweise /opt/rustic. Docker-Zugriff ist sicherheitstechnisch weitreichend und gehört nicht an beliebige Benutzerkonten. Speichern Sie das Repository-Passwort zusätzlich in Ihrem Passwortmanager. Ohne Passwort hilft auch ein vollständig erhaltenes Repository nicht. Eine Domain, ein Reverse Proxy und offene Netzwerkports sind für diesen lokalen Ablauf unnötig.

Schritt 1: Projekt und Image vorbereiten

Rustic ist kein Backup-Dashboard. Die Container starten für genau einen Auftrag und verschwinden danach. Damit vermeiden Sie zusätzliche Webanmeldung, TLS-Konfiguration und eine dauerhaft laufende Administrationsoberfläche. Das Projekt hatte bei der Prüfung 3322 GitHub-Sterne, war nicht archiviert und verzeichnete den letzten Push am 1. September 2026. Das aktuelle Release war v0.11.4. Popularität ersetzt jedoch weder Ihre eigene Prüfung noch eine dokumentierte Rückfallstrategie.

mkdir -p /opt/rustic
cd /opt/rustic
mkdir -p source repo restore config

Legen Sie eine compose.yaml an. Für reproduzierbaren Betrieb verwenden Sie den im Test ermittelten Image-Digest aus der unten beschriebenen Inspektion statt eines dauerhaft beweglichen Tags. Die Datei schreibt den im Test ausgeführten offiziellen Build fest; prüfen Sie dessen Versionsausgabe unmittelbar nach dem Pull.

services:
  backup:
    image: ghcr.io/rustic-rs/rustic@sha256:bb8e60aef240ca54ea1091f42f07d48f552edf8474062e55b5c72e7cdf3a9949
    volumes:
      - ./source:/source:ro
      - ./repo:/repo
      - ./restore:/restore
      - ./config:/config

docker compose config
 docker compose pull
 docker compose run --rm backup --version
 docker image inspect ghcr.io/rustic-rs/rustic:latest --format '{{json .RepoDigests}}'

Verifizieren: Die Konfiguration muss ohne Fehlermeldung rendern. Im Praxistest meldete der Container rustic v0.11.4. Notieren Sie Ausgabe und Digest gemeinsam. Eine leere Ausgabe von docker compose ps ist nach einem abgeschlossenen Einmalauftrag normal und kein Startfehler.

Schritt 2: Passwort und Profil festlegen

Das Profil verhindert, dass Sie Speicherziel und Zugangsdaten bei jedem Auftrag neu zusammensetzen. Erzeugen Sie ein zufälliges Passwort direkt als Datei, ohne es in die Shell-Historie zu schreiben. Die restriktive Dateiberechtigung schützt vor gewöhnlichen lokalen Konten, nicht vor root oder Personen mit Docker-Zugriff. Übertragen Sie den Inhalt über Ihren sicheren Verwaltungsweg in den Passwortmanager.

umask 077
head -c 48 /dev/urandom | base64 > config/password
chmod 600 config/password

Speichern Sie folgendes Profil unter config/rustic.toml. Ein stabiler Hostname hält die Gruppierung unabhängig vom zufälligen Containernamen. Die Aufbewahrungsregeln werden zunächst nur für eine Vorschau verwendet.

[repository]
repository = "/repo"
password-file = "/config/password"
cache-dir = "/tmp/cache"
[backup]
host = "backup-server"
[forget]
keep-last = 7
keep-daily = 14
keep-weekly = 8
keep-monthly = 12

Definieren Sie für die folgenden Befehle eine Shell-Funktion. Bei einer neuen Shell müssen Sie diese erneut definieren. Das Argument nach -P bezeichnet das Profil ohne die Endung .toml. Das offizielle Image basiert auf scratch und bietet keine gewöhnliche Shell für Wartungsbefehle im Container.

r() { docker compose run --rm backup -P /config/rustic "$@"; }
r init

Verifizieren: Rustic bestätigt das geladene Profil, einen erfolgreich hinzugefügten Schlüssel und ein erstelltes Repository. Bewahren Sie das Passwort außerhalb dieses Projektordners auf. Eine Sicherung der Passwortdatei ausschließlich im damit verschlüsselten Repository wäre ein unlösbarer Wiederherstellungskreislauf.

Schritt 3: Erste Sicherung und Integrität prüfen

Verwenden Sie zuerst harmlose Beispieldateien. Erst nach dem vollständigen Restore-Test ersetzen Sie den Quellordner durch produktive Daten. Schreiben Sie die Prüfsummen vor der Sicherung auf, damit Sie später nicht nur Dateinamen und Größen vergleichen. Eine verschachtelte Datei prüft zusätzlich, wie der Restore mit Unterverzeichnissen umgeht.

printf 'Wiederherstellung prüfen\n' > source/marker.txt
mkdir -p source/sub
printf 'Unterverzeichnis\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 /source
r snapshots
r check --read-data
r backup /source

Der zweite Auftrag zeigt die Deduplizierung bei unveränderten Daten. Im Test erkannte Rustic drei unveränderte Dateien und fügte null Byte Dateidaten hinzu, erzeugte aber einen weiteren Snapshot. Ein Snapshot repräsentiert einen Wiederherstellungszeitpunkt, nicht zwingend eine neue vollständige physische Kopie. Die Integritätsprüfung mit --read-data liest auch die gespeicherten Pack-Daten statt nur Metadaten abzugleichen.

Bei laufenden Datenbanken genügt das Kopieren ihrer Dateien nicht für eine konsistente Sicherung. Erzeugen Sie einen unterstützten Datenbank-Dump oder stoppen Sie die Anwendung kontrolliert. Prüfen Sie außerdem, ob Konfiguration, Schlüssel und hochgeladene Dateien zum gleichen Sicherungsstand gehören. Ein technisch lesbares Repository beweist keine Anwendungskonsistenz.

Verifizieren: Die Snapshot-Liste enthält die Quelle /source und den festen Hostnamen. Beide Backup-Aufträge und die vollständige Datenprüfung müssen erfolgreich enden. Im Test wurden drei Dateien mit insgesamt rund 64 KiB gesichert und beim zweiten Durchlauf wiedererkannt.

Schritt 4: Gelöschte Dateien wirklich wiederherstellen

Restores gehören in einen separaten, leeren Zielordner. Spielen Sie nicht vorschnell über vorhandene produktive Dateien zurück. Rustic stellt bei diesem Befehl den Quellpfad als Unterordner wieder her: Die Dateien liegen unter restore/source, nicht unmittelbar unter restore. Genau diese Pfadannahme führte im ersten Test zu einem fehlgeschlagenen Kopierbefehl, obwohl die Wiederherstellung selbst korrekt war.

r restore latest /restore
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 check --read-data

Die Löschbefehle gelten ausschließlich für die hier erstellten Beispieldateien. Bei echten Daten untersuchen Sie zunächst den Restore und übertragen anschließend nur freigegebene Dateien. Für eine gezielte ältere Wiederherstellung verwenden Sie eine Snapshot-ID aus der Liste statt latest. Das verhindert, dass ein zwischenzeitlicher Backup-Auftrag Ihre Auswahl verschiebt.

Verifizieren: Im Test meldete SHA256 für Marker, Unterverzeichnis-Datei und Binärdatei jeweils OK, nachdem die Originale gelöscht und aus dem Restore zurückkopiert worden waren. Die anschließende vollständige Repository-Prüfung war ebenfalls erfolgreich. Erst diese Kombination belegt einen echten Restore.

Schritt 5: Aufbewahrung und laufenden Betrieb organisieren

Aufbewahrung ist eine fachliche Entscheidung: Wie weit zurück müssen Sie versehentlich gelöschte oder schleichend beschädigte Daten finden können? Die Beispielwerte behalten mehrere tägliche, wöchentliche und monatliche Stände. Mehrere Regeln können denselben Snapshot erhalten, die Zahlen sind deshalb keine einfache Summe erwarteter Kopien. Schauen Sie sich die Entscheidungsgründe an, bevor Sie Löschoperationen automatisieren.

r forget --dry-run
r snapshots

Im Test blieben beide vorhandenen Snapshots erhalten und Rustic meldete nothing to remove. Verwenden Sie die Vorschau nach jeder Änderung Ihrer Regeln. Lassen Sie Sicherungen regelmäßig durch Ihren vorhandenen Scheduler ausführen, protokollieren Sie Exitcodes und melden Sie ausbleibende erfolgreiche Aufträge. Überwachen Sie nicht nur, ob irgendein Prozess gestartet wurde, sondern ob ein neuer brauchbarer Wiederherstellungsstand existiert.

Repository und Quelle auf derselben Platte sind für die Einführung bequem, schützen aber nicht gegen ihren Ausfall. Verschieben Sie das Repository später auf einen getrennten Datenträger oder ergänzen Sie ein externes Ziel anhand der offiziellen Backend-Dokumentation. Eine ständig beschreibbare Sicherung kann durch kompromittierte Administratorzugänge gelöscht werden. Offline-Kopien und getrennte Berechtigungen bleiben deshalb wichtig.

Verifizieren: Die Vorschau zeigt für jeden Snapshot Aktion und Grund. Kontrollieren Sie verfügbaren Speicher, aktuelle Snapshot-Zeitpunkte und das Ergebnis des letzten Restore-Tests. Dokumentieren Sie Verantwortliche und Passwortzugriff, damit die Wiederherstellung nicht an einer einzelnen Person hängt.

Schritt 6: Updates kontrollieren und Konfiguration sichern

Archivieren Sie Compose-Datei, Profil und Passwortdatei auf einem getrennten, geschützten Ziel. Repository-Daten allein beschreiben nicht automatisch Ihre Einbindung und Betriebsabläufe. Vor einem Update notieren Sie den aktuellen Digest und lesen die Release-Hinweise. Testen Sie ein neues Image zuerst gegen eine Kopie Ihres Repositorys, wenn Ihre Wiederherstellungsfristen keine Experimente erlauben.

docker compose pull
r --version
r snapshots
r check --read-data

Ein beweglicher Tag kann eine andere Version liefern als am Veröffentlichungstag. Ersetzen Sie ihn für den Dauerbetrieb durch ghcr.io/rustic-rs/rustic@sha256:… mit Ihrem bestätigten Digest. Ein Versionswechsel ist erst abgeschlossen, wenn Zugriff, Integritätsprüfung und ein erneuter Restore erfolgreich sind. Den Projektordner entfernen Sie nur nach bestätigter Migration; repo enthält Ihre eigentlichen Sicherungen.

Verifizieren: Vergleichen Sie die ausgeführte Version mit dem vorgesehenen Release, kontrollieren Sie die Snapshot-Liste und wiederholen Sie den Prüfsummen-Restore. Bewahren Sie den vorherigen Digest für eine gezielte Rückkehr auf, sofern die Release-Hinweise keine Formatänderung ausschließen.

Troubleshooting

1. Falsches Passwort: Der Negativtest meldete No suitable key found for the given password. Prüfen Sie Passwortdatei und Profil, erzeugen Sie nicht versehentlich ein neues Repository.
2. Fehlende Quelle: Der Auftrag für /missing endete mit Not all snapshots were generated successfully!. Kontrollieren Sie Bind-Mount und tatsächlichen Containerpfad.
3. Restore-Datei scheinbar verschwunden: Prüfen Sie restore/source. Die ursprüngliche Pfadstruktur bleibt bei diesem Ablauf erhalten.
4. Zeitzonenwarnung: Das scratch-Image meldete fehlende zoneinfo und einen Rückfall auf UTC. Beurteilen Sie Zeitangaben entsprechend, statt die Warnung mit Datenverlust gleichzusetzen.
5. Keine Container in der Übersicht: run --rm entfernt abgeschlossene Aufträge absichtlich. Lesen Sie deren Ausgaben und Exitcodes.

Häufige Fragen

Kann restic dasselbe Repository lesen?

Laut upstream implementiert Rustic das restic-Repositoryformat. Prüfen Sie Ihre konkrete Werkzeugkombination an einer Kopie, besonders vor gleichzeitiger Nutzung unterschiedlicher Versionen.

Brauche ich eine Weboberfläche?

Nein. Der gezeigte Ablauf ist CLI-basiert und veröffentlicht keinen Port. Deshalb gehören hier keine erfundenen Dashboard-Screenshots zur Anleitung.

Ist das lokale Repository bereits eine vollständige Backup-Strategie?

Nein. Es bietet Versionierung und Verschlüsselung, benötigt aber getrennte Kopien, Zugangsschutz und regelmäßig überprüfte Wiederherstellungsabläufe.

Fazit

Rustic bietet einen schlanken Docker-Weg für nachvollziehbare Dateisicherungen. Entscheidend sind das geschützte Passwort, eine schreibgeschützte Quelle und ein tatsächlich durchgeführter Restore. Der Test mit Version 0.11.4 belegte wiederholte Sicherung, Datenprüfung und bytegenaue Wiederherstellung. Ergänzen Sie diesen technischen Ablauf um getrennte Sicherungsziele und klare betriebliche Verantwortlichkeiten.

Weiterführende Anleitungen und Quellen

1. Offizielles Rustic-Repository und Dockerfile
2. Release v0.11.4
3. Offizielle Einführung
4. Vollständiges Konfigurationsbeispiel
5. restic mit Cron betreiben
6. 3-2-1-Backup-Strategie praktisch umsetzen