restic ist eines der zuverlässigsten Werkzeuge für verschlüsselte, deduplizierte Backups. Im Alltag scheitert es aber selten an restic selbst, sondern an allem drumherum: Cronjobs, die niemand überwacht, Aufbewahrungsregeln, die nur im Skript stehen, und ein Restore, den im Ernstfall nur eine Person auf der Kommandozeile beherrscht. Genau hier setzt Backrest an. Das Projekt legt eine Weboberfläche und einen eigenen Scheduler über restic, plant Backups, Prune und Check, zeigt jede Operation mit Status an und erlaubt den Restore einzelner Dateien per Klick.

Diese Anleitung zeigt den kompletten Weg mit Docker Compose: vollständige compose.yaml, Erstkonfiguration mit Login, lokales Repository, Backup-Plan mit Zeitplan und Aufbewahrung, Prüfung des Repositorys, Restore mit Prüfsummenvergleich, Sicherung von Backrest selbst sowie Updates und Deinstallation. Alle Befehle und Fehlermeldungen stammen aus einer eigenen Testumgebung mit Backrest 1.14.1 am 27.09.2026. Wer restic bisher per Skript und Cron betreibt, findet in der Anleitung zu restic mit Cron die Kommandozeilen-Variante; Backrest ist die Alternative mit Oberfläche.

Was Backrest ist und wo die Grenzen liegen

Backrest ist ein in Go geschriebener Dienst unter GPL-3.0, der die restic-Kommandozeile aufruft und deren Ergebnisse in einer eigenen Operationshistorie (SQLite) speichert. Das Repository garethgeorge/backrest hatte laut GitHub-API am 27.09.2026 rund 7.400 Sterne (exakt 7409), der letzte Push war am 21.09.2026, das Projekt ist nicht archiviert. Das aktuelle Release ist v1.14.1 vom 12.07.2026.

Was Backrest leistet:

Anlegen neuer und Einbinden vorhandener restic-Repositories, lokal oder auf jedem restic-Backend wie S3, B2, SFTP, Azure, GCS sowie über rclone
Backup-Pläne mit Pfaden, Ausschlüssen, Zeitplan (Cron-Ausdruck oder Intervall) und Aufbewahrungsregel
Geplante Wartung pro Repository: prune und check mit eigenem Zeitplan
Snapshot-Browser und Restore einzelner Dateien oder Verzeichnisse
Hooks vor und nach Backups sowie Benachrichtigungen, etwa an Gotify, Healthchecks, Slack, Discord, Telegram oder per Webhook
Eine JSON-API für Skripte, etwa um ein Backup von außen anzustoßen

Die Grenzen sind ebenso klar. Backrest ist kein Ersatz für ein Konzept: Es sichert Dateien, keine konsistenten Datenbankzustände. Für MariaDB oder PostgreSQL brauchen Sie einen Dump per Hook vor dem Backup. Ein lokales Repository auf demselben Host schützt nicht vor Hardwareverlust oder Ransomware; dafür gehört mindestens eine Kopie außer Haus, idealerweise unveränderlich, wie in der Anleitung zu Immutable Backups nach 3-2-1-1-0 mit restic beschrieben. Außerdem speichert Backrest die Repository-Passwörter im Klartext in seiner config.json. Wer die Konfigurationsdatei oder die ungeschützte API erreicht, erreicht damit auch alle Backups.

Voraussetzungen und Ressourcen

Backrest ist ausgesprochen sparsam. Im Test belegte der Container im Leerlauf zwischen 6,8 und 7,8 MiB RAM; das Image ghcr.io/garethgeorge/backrest:v1.14.1 belegte 315 MB auf der Platte. Während eines Backups steigt der Bedarf, weil restic selbst Speicher für Index und Deduplizierung braucht. Bei großen Repositories mit vielen Millionen Dateien sind mehrere hundert MB realistisch, das hängt aber von Datenmenge und Backend ab.

Linux-Host mit Docker Engine und Compose-Plugin
Lesezugriff auf die zu sichernden Verzeichnisse, die in den Container gemountet werden
Ein Ziel für das Repository: lokale Platte, NAS-Freigabe, S3-kompatibler Speicher oder SFTP
Ein Passwortmanager für das Repository-Passwort. Ohne dieses Passwort ist kein Restore möglich, auch nicht mit restic direkt.

Unterstützte Plattformen und getestete Version

Das Multi-Arch-Image auf GHCR enthält Varianten für linux/amd64, linux/arm64, linux/arm/v6, linux/arm/v7 und linux/386. Neben Docker gibt es native Builds für Linux, macOS, Windows und FreeBSD. Wichtig bei der Tag-Wahl: Die Tags tragen das v aus dem Release-Namen.

Tag	Ergebnis der Registry-Abfrage	Hinweis
`v1.14.1`	vorhanden	Standard-Image mit rclone und Unix-Werkzeugen, im Test verwendet
`v1.14.1-alpine`	vorhanden	Alpine-Variante
`v1.14.1-scratch`	vorhanden	Minimal-Image ohne Shell, keine Hooks mit Shellbefehlen
`latest`	vorhanden	wandert mit jedem Release mit, für Produktion besser fest pinnen
`1.14.1`	nicht vorhanden	ohne `v` schlägt der Pull fehl

Im Container meldete Backrest 1.14.1 beim Start, dass das mitgelieferte /bin/restic in Version 0.19.1 passt und verwendet wird. Zusätzlich ist rclone v1.74.4 enthalten. Findet Backrest kein passendes restic, lädt es laut Dokumentation eine signaturgeprüfte Version von GitHub herunter.

Vollständige compose.yaml und .env

Die folgende Datei basiert auf dem offiziellen Beispiel aus dem README, bindet den Port aber nur an 127.0.0.1, mountet die Quelldaten schreibgeschützt und ergänzt einen Healthcheck. Das offizielle Beispiel enthält noch die veraltete Zeile version:, die aktuelle Compose-Versionen ignorieren; sie fehlt hier.

services:
  backrest:
    image: ghcr.io/garethgeorge/backrest:v1.14.1
    container_name: backrest
    hostname: backrest
    volumes:
      - ./backrest/data:/data
      - ./backrest/config:/config
      - ./backrest/cache:/cache
      - ./backrest/tmp:/tmp
      - ./backrest/rclone:/root/.config/rclone
      - ${BACKUP_SOURCE}:/userdata:ro
      - ${REPO_PATH}:/repos
      - ./restore:/restore
    environment:
      - BACKREST_DATA=/data
      - BACKREST_CONFIG=/config/config.json
      - XDG_CACHE_HOME=/cache
      - TMPDIR=/tmp
      - TZ=${TZ}
    ports:
      - "127.0.0.1:${BACKREST_HOST_PORT}:9898"
    healthcheck:
      test: ["CMD", "wget", "-q", "-O", "/dev/null", "http://127.0.0.1:9898/"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 20s
    restart: unless-stopped

Die zugehörige .env im selben Verzeichnis enthält keine Geheimnisse, nur Pfade und Zeitzone. Passwörter für Login und Repository legen Sie in der Oberfläche fest.

# .env für Backrest
TZ=Europe/Berlin
BACKREST_HOST_PORT=9898
BACKUP_SOURCE=/srv/daten
REPO_PATH=/mnt/backup/restic

Die Parameter im Überblick:

Pfad oder Variable	Zweck
`/data` (`BACKREST_DATA`)	Operationshistorie `oplog.sqlite`, `jwt-secret`, Task- und Prozesslogs
`/config/config.json` (`BACKREST_CONFIG`)	Gesamte Konfiguration: Repos mit Passwörtern, Pläne, Benutzer, Instanz-ID
`/cache` (`XDG_CACHE_HOME`)	restic-Cache, beschleunigt Operationen deutlich, verzichtbar beim Backup
`/userdata`	Quelldaten, schreibgeschützt eingebunden
`/repos`	Lokale restic-Repositories, entfällt bei reinem Remote-Speicher
`/restore`	Beschreibbares Ziel für Wiederherstellungen
`TZ`	Zeitzone für Cron-Zeitpläne mit lokaler Uhr

Der eigene Mount /restore ist kein Zierrat. Weil /userdata schreibgeschützt ist, schlägt ein Restore dorthin fehl; dazu mehr im Abschnitt zu typischen Fehlern.

Installation und Start

# Verzeichnis anlegen und compose.yaml sowie .env hineinlegen
mkdir -p /opt/backrest && cd /opt/backrest
# Image laden und Container starten
docker compose up -d
# Startmeldungen prüfen
docker compose logs --no-log-prefix | head -20

Im Test erschienen unter anderem diese Zeilen:

Setting docker defaults for env variables:
 - BACKREST_PORT="0.0.0.0:9898"
INFO  backrest starting  {"version": "1.14.1", "commit": "875c9cb5..."}
INFO  restic binary "/bin/restic" in $PATH matches required version 0.19.1, it will be used for backrest commands
INFO  generating new auth secret
INFO  starting web server  {"addr": "0.0.0.0:9898"}

Das Image setzt BACKREST_PORT auf 0.0.0.0:9898, damit der Dienst im Container erreichbar ist. Die Einschränkung auf localhost erfolgt deshalb über das Port-Mapping in der compose.yaml, nicht über diese Variable.

Funktionsprüfung und Healthcheck

# Status inklusive Healthcheck
docker compose ps
# Weboberfläche antwortet mit HTTP 200
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:9898/

Nach rund 30 Sekunden zeigte docker compose ps im Test Up 30 seconds (healthy), die Startseite lieferte HTTP 200 mit dem Seitentitel Backrest. Das Image enthält sowohl wget als auch curl, der Healthcheck funktioniert also ohne Zusatzpakete. Das gilt nicht für die scratch-Variante, die keine Shell-Werkzeuge mitbringt.

Rufen Sie die Oberfläche unter http://127.0.0.1:9898 auf, bei einem entfernten Server per SSH-Tunnel (ssh -L 9898:127.0.0.1:9898 server). Beim ersten Aufruf fragt Backrest nach Instanz-ID, Benutzername und Passwort. Die Instanz-ID landet als Tag created-by:<ID> an jedem Snapshot und lässt sich laut Dokumentation in der Oberfläche später nicht mehr ändern. Wählen Sie also einen sprechenden Namen wie den Hostnamen.

Wichtiger Befund aus dem Test: Bis zu dieser Ersteinrichtung ist die API völlig offen. Eine frische Instanz beantwortete GetConfig ohne jede Anmeldung mit HTTP 200 und "auth":{"disabled":true}. Wer den Port vor der Einrichtung ins Netz stellt, überlässt die Instanz dem ersten Besucher. Richten Sie den Login deshalb sofort nach dem Start ein.

Ohne Browser geht die Einrichtung auch per API, was sich für automatisierte Installationen eignet. Der Aufruf HashPassword erwartet ein JSON-Objekt mit dem Feld value; ein nackter String wird mit unmarshal into *types.StringValue: proto: syntax error abgelehnt.

# bcrypt-Hash für das Admin-Passwort erzeugen lassen
curl -s -X POST http://127.0.0.1:9898/v1.Authentication/HashPassword \
  -H 'Content-Type: application/json' -d '{"value":"IhrSicheresPasswort"}'

Den zurückgegebenen Wert tragen Sie als passwordBcrypt eines Benutzers in die mit GetConfig gelesene Konfiguration ein und schreiben sie mit SetConfig zurück. Danach lieferte die API im Test ohne Anmeldung 401 Unauthorized (No Authorization Header), mit falschem Passwort ebenfalls 401 und mit korrekten Zugangsdaten per HTTP Basic Auth 200. Der Login-Endpunkt /v1.Authentication/Login antwortete bei falschem Passwort mit {"code":"unauthenticated","message":"invalid password"}.

Repository anlegen

Unter Add Repo vergeben Sie einen Namen, die URI und das Repository-Passwort. Für ein lokales Repository im gemounteten Verzeichnis lautet die URI zum Beispiel /repos/server01. Für entfernte Ziele gelten die restic-Formate wie s3:bucket/prefix, b2:bucket, sftp:user@host:/pfad oder rclone:remote:pfad; Zugangsdaten kommen als Umgebungsvariablen in das Repo, etwa AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY.

Im selben Dialog legen Sie die Wartung fest. Bewährt hat sich im Test diese Kombination, die Backrest auch korrekt einplante:

Prune monatlich mit Cron 0 3 1 * * und Uhr „Last Run Time“, Schwelle 10 Prozent ungenutzter Daten
Check monatlich mit Cron 0 4 1 * * und Uhr „Last Run Time“, dabei 5 Prozent der Datenpakete tatsächlich lesen

Die Uhr „Last Run Time“ empfiehlt die Dokumentation für seltene Operationen, weil ein verpasster Termin, etwa bei ausgeschaltetem Server, dann nicht einfach bis zum nächsten Monat übersprungen wird. Das Repository wurde im Test innerhalb einer Sekunde initialisiert.

Backup-Plan mit Zeitplan und Aufbewahrung

Unter Add Plan verbinden Sie Quellpfade mit einem Repository. Die Dokumentation empfiehlt Namen nach dem Muster [speicher]-[inhalt], denn Planname und zugeordnetes Repo lassen sich nachträglich nicht ändern. Der Testplan sah so aus:

Einstellung	Wert im Test
Pfade	`/userdata`
Ausschlüsse	`*.tmp`
Zeitplan	Cron `30 1 * * *`, Uhr lokal (täglich 01:30 Uhr)
Aufbewahrung	zeitbasiert: 7 tägliche, 4 wöchentliche, 6 monatliche, zusätzlich immer die letzten 3

Nach dem Speichern zeigte das Log, dass der Scheduler die Aufgaben korrekt eingeplant hatte, und zwar auch nach einem Neustart des Containers wieder:

INFO  scheduled task  {"task": "backup for plan \"testdaten\"", "runAt": "2026-09-28T01:30:00+02:00"}
INFO  scheduled task  {"task": "prune repo \"lokal\"", "runAt": "2026-10-01T03:00:00+02:00"}
INFO  scheduled task  {"task": "check for repo \"lokal\"", "runAt": "2026-10-01T04:00:00+02:00"}

Backrest prüft Cron-Ausdrücke beim Speichern. Der unmögliche Termin 0 0 30 2 * (30. Februar) wurde abgelehnt mit backup schedule: invalid cron "0 0 30 2 *": next scheduled time is invalid. Das ist ein echter Vorteil gegenüber klassischem Cron, das solche Einträge stillschweigend nie ausführt.

Den ersten Lauf starten Sie in der Oberfläche mit Backup Now oder per API. Der Aufruf blockiert, bis das Backup fertig ist, und eignet sich damit auch für Hooks anderer Systeme:

# Plan "testdaten" sofort ausführen
curl -X POST http://127.0.0.1:9898/v1.Backrest/Backup \
  -H 'Content-Type: application/json' -u admin:IhrSicheresPasswort \
  --data '{"value": "testdaten"}'

Im Test lief das Backup von vier Dateien mit rund 600 KB in 4,7 Sekunden durch. Direkt danach führte Backrest automatisch ein forget gemäß Aufbewahrungsregel und eine Indizierung der Snapshots aus. Der Snapshot trug die Tags plan:testdaten und created-by:sedv-test.

Backups prüfen

Ein Backup ohne Prüfung ist eine Hoffnung. Backrest bietet drei Ebenen:

Operationshistorie: Jede Operation erscheint mit Status in der Oberfläche; per API liefert GetOperations dieselben Daten, zum Beispiel STATUS_SUCCESS oder STATUS_ERROR samt Fehlermeldung.
Repository-Check: Neben dem geplanten Check lässt er sich manuell starten. Im Test lieferte ein manueller Check STATUS_SUCCESS, die Statistik zeigte Größe, Kompressionsrate und Anzahl der Snapshots.
Unabhängige Gegenprobe mit restic: Das Repository ist ein normales restic-Repository. Damit kommen Sie auch ohne Backrest an die Daten.

# Snapshots mit restic direkt im Container auflisten
docker compose exec -e RESTIC_PASSWORD='IhrRepoPasswort' backrest \
  restic -r /repos/server01 snapshots

Für Benachrichtigungen legen Sie am Plan oder Repo einen Hook an, etwa mit der Bedingung CONDITION_ANY_ERROR an Gotify oder als Healthchecks-Ping bei CONDITION_SNAPSHOT_SUCCESS. So fällt ein ausbleibendes Backup auf, statt erst beim Restore.

Dateien wiederherstellen

Für den Test wurde eine Datei aus der Quelle gelöscht und anschließend zurückgeholt. In der Oberfläche öffnen Sie dazu den Snapshot, klappen den Snapshot Browser auf, wählen am gewünschten Ordner oder an der Datei Restore to path und geben ein Ziel an. Bleibt das Ziel leer, versucht Backrest laut Dokumentation in ein Downloads-Verzeichnis zu schreiben; in Docker sollten Sie deshalb immer einen gemounteten Pfad wie /restore/… angeben.

Das Ergebnis im Test, geprüft mit sha256 im Container:

# Prüfsumme der Originaldatei vor dem Löschen
bbbf5751f586881a00d71e4662c98918cee2d2ac8cb1fe778cc2ff950228e14f  source/rechnung.txt
# Prüfsumme nach Restore über Backrest
bbbf5751f586881a00d71e4662c98918cee2d2ac8cb1fe778cc2ff950228e14f  /restore/r1/rechnung.txt

Auch ein vollständiger Restore des Verzeichnisses brachte alle vier Dateien mit identischen Prüfsummen zurück. Als dritte Gegenprobe holte restic restore latest --include direkt mit restic eine Einzeldatei, ebenfalls bitgenau. Prüfen Sie die Rechte nach dem Restore: Der Container läuft als root, wiederhergestellte Dateien gehören also zunächst root.

# Wiederherstellung an Ort und Stelle zurückkopieren, Rechte anpassen
sudo cp -a /opt/backrest/restore/r1/rechnung.txt /srv/daten/
sudo chown benutzer:gruppe /srv/daten/rechnung.txt

Persistente Daten, Rechte und Sicherung von Backrest selbst

Alle Dateien unter ./backrest gehören root. Die config.json war im Test für den normalen Host-Benutzer nicht lesbar (Permission denied); das ist gewollt, denn sie enthält die Repository-Passwörter im Klartext. Lesen Sie sie mit docker compose exec backrest cat /config/config.json oder mit sudo. Bei jeder Änderung legt Backrest zusätzlich eine Kopie config.json.bak.<Zeitstempel> an.

Die Backups selbst liegen im restic-Repository. Backrest ist nur die Steuerung. Trotzdem sollten Sie config und data sichern, denn dort stecken Pläne, Hooks, Passwörter und die Historie. Im Test funktionierte dieser Weg vollständig:

# Backrest anhalten, damit die SQLite-Dateien konsistent sind
docker compose stop
# Konfiguration und Daten sichern
sudo tar czf backrest-config-$(date +%F).tgz -C /opt/backrest/backrest config data
docker compose start

Nach dem Löschen von config, data und cache und dem Zurückspielen des Archivs startete die Instanz mit aktivem Login, die Snapshots waren sofort wieder sichtbar. Das Archiv enthält Klartext-Passwörter und gehört verschlüsselt an einen anderen Ort, etwa in den Passwortmanager oder als Teil eines anderen Backups. Unabhängig davon sollte das Repository-Passwort separat notiert sein: Mit Pfad und Passwort kommen Sie per restic auch ohne Backrest an jede Datei.

Netzwerkfreigabe, Reverse Proxy und TLS

Backrest spricht selbst nur HTTP. Für den Zugriff aus dem Netz gehört ein Reverse Proxy mit TLS davor. Die Projektdokumentation zeigt ein Beispiel mit Caddy, bei dem der Proxy per Containername auf backrest:9898 weiterleitet. Mit einem Caddy im selben Compose-Netz genügt:

backup.example.de {
    reverse_proxy backrest:9898
}

Die Einrichtung von Caddy selbst beschreibt die Anleitung zu Caddy als Reverse Proxy mit automatischem HTTPS. Beachten Sie drei Punkte: Lassen Sie den Login in Backrest aktiv, auch hinter dem Proxy. Veröffentlichen Sie den Port 9898 nicht zusätzlich auf 0.0.0.0. Und überlegen Sie, ob eine Backup-Konsole überhaupt aus dem Internet erreichbar sein muss; VPN oder SSH-Tunnel sind für die meisten Firmen die bessere Wahl.

Updates und Rollback-Grenzen

# Vorher Konfiguration sichern (siehe oben), dann Tag in compose.yaml anheben
docker compose pull
docker compose up -d
# Version im Log prüfen
docker compose logs --no-log-prefix | grep 'backrest starting'

Beim ersten Start migriert Backrest die Operationshistorie; im Test lief eine Schema-Migration von Stand 0 auf 6 und legte dabei automatisch eine Kopie oplog.sqlite-<Datum>-s06m06.backup an. Ein Rollback auf eine ältere Version ist nach einer Migration nicht garantiert. Halten Sie deshalb das Archiv von config und data vor dem Update bereit. Die Backups im restic-Repository sind davon nicht betroffen, sofern die neue restic-Version das Repository-Format nicht anhebt; lesen Sie vor größeren Sprüngen die Release-Notes.

Typische Fehler mit Diagnose und Lösung

Die folgenden Meldungen wurden im Test absichtlich provoziert und stammen wörtlich aus Backrest 1.14.1:

Meldung	Ursache	Lösung
`Fatal: wrong password or no key found` (restic Exit-Code 12)	Falsches Repository-Passwort beim Einbinden oder in der gespeicherten Konfiguration; betroffen waren Backup und geplanter Prune	Passwort im Repo korrigieren, dann Index Snapshots
`failed to init repo ... config file already exists`	Neues Repo zeigt auf einen Pfad, in dem schon ein restic-Repository liegt	Vorhandenes Repository mit dessen Passwort einbinden statt neu anlegen
`auto_initialize set with guid but guid implies that repo is already initialized`	API-Aufruf mit `autoInitialize` für ein Repo, das beim Anlegen bereits initialisiert wurde	Option weglassen; im Test war das Repo trotz Fehlermeldung schon angelegt
`invalid cron "0 0 30 2 *": next scheduled time is invalid`	Cron-Ausdruck, der nie zutrifft	Ausdruck korrigieren, etwa mit crontab.guru prüfen
`restore failed output processing: cannot create target director...`	Restore-Ziel liegt in einem schreibgeschützten Mount wie `/userdata`	Beschreibbares Ziel wie `/restore/…` verwenden
`FATAL error loading config {"error": "... auth: auth enabled but no users"}`, Container im Neustart-Loop	Nur der Schlüssel `users` wurde aus der `config.json` gelöscht	Siehe folgender Absatz

Der letzte Fall betrifft das vergessene Admin-Passwort. Die Dokumentation empfiehlt, den Schlüssel "users" aus der config.json zu entfernen und neu zu starten. In Version 1.14.1 führte genau das im Test zum Abbruch mit auth enabled but no users. Erst das Entfernen des gesamten Blocks "auth" ließ die Instanz wieder starten. Dann ist die API allerdings wieder ohne Anmeldung erreichbar und gibt die Repository-Passwörter im Klartext aus. Führen Sie diesen Schritt deshalb nur aus, solange der Port ausschließlich an localhost gebunden ist, und vergeben Sie sofort ein neues Passwort.

Weitere Diagnosewege: docker compose logs backrest zeigt Scheduler und Fehler, in der Oberfläche liefert jede Operation über View Logs die vollständige restic-Ausgabe. Snapshots, die mit restic direkt oder von einer anderen Instanz erstellt wurden, erscheinen erst nach Index Snapshots.

Saubere Deinstallation

Achtung, Datenverlust: Die folgenden Befehle löschen Konfiguration, Historie und, wenn Sie auch das Repository-Verzeichnis entfernen, alle Backups unwiderruflich. Prüfen Sie vorher, ob noch eine andere Kopie existiert und ob Sie Konfiguration und Repository-Passwort noch benötigen.

# Container und Netz entfernen
cd /opt/backrest
docker compose down -v --remove-orphans
# Konfiguration, Historie und Cache löschen (root-Dateien, daher sudo)
sudo rm -rf /opt/backrest/backrest /opt/backrest/restore
# Nur wenn die Backups wirklich weg sollen: lokales Repository löschen
# sudo rm -rf /mnt/backup/restic
# Image gezielt entfernen
docker rmi ghcr.io/garethgeorge/backrest:v1.14.1

Entfernen Sie das Image namentlich statt pauschal alle unbenutzten Images zu löschen; sonst verschwinden auf einem Host mit weiteren Diensten auch Images, die noch gebraucht werden.

Testumfang

Getestet mit Backrest 1.14.1 und restic 0.19.1: Start mit Healthcheck, Einrichtung des Logins per API mit 401 und 200, lokales Repository, Plan mit Cron und Aufbewahrung samt Einplanung im Scheduler, Backup, Snapshot-Liste, Check, Restore einer gelöschten Datei und des ganzen Ordners mit identischen sha256-Summen, Sicherung und Wiederherstellung von Backrest selbst sowie die in der Fehlertabelle genannten Meldungen. Nur aus der Dokumentation übernommen sind die Bedienung der Weboberfläche im Browser, Remote-Backends wie S3, B2, SFTP und rclone, Benachrichtigungs-Hooks, der Reverse Proxy mit TLS, Updates von älteren Versionen und die tatsächliche nächtliche Ausführung zum geplanten Zeitpunkt.

Passende Anleitungen auf S-EDV

restic-Backups unter Linux und Windows mit Cron automatisieren: Die Kommandozeilen-Variante ohne Oberfläche, hilfreich zum Verständnis der restic-Befehle, die Backrest im Hintergrund ausführt.
Immutable Backups gegen Ransomware nach 3-2-1-1-0 mit restic: Wie die Kopie außer Haus unveränderlich wird, damit ein kompromittierter Server die Backups nicht mitlöschen kann.
Caddy als Reverse Proxy mit automatischem HTTPS: Der Weg, die HTTP-Oberfläche von Backrest per TLS abzusichern.

Quellen

garethgeorge/backrest auf GitHub: offizielles Repository mit README und Compose-Beispiel, Projektdaten per GitHub-API abgerufen am 27.09.2026.
Backrest Releases: belegt Release v1.14.1 vom 12.07.2026.
Backrest Getting Started: Erstkonfiguration, Repository- und Plan-Einstellungen, Zurücksetzen der Zugangsdaten.
Backrest Operations Guide: Zeitpläne, Uhren, Cron-Erweiterungen und Ablauf der Operationen.
Backrest API: stabile Endpunkte für Backup und Operationshistorie.
config.proto: Feldnamen der Konfiguration, verwendet für die Einrichtung per API.
restic-Dokumentation: Repository-Formate, Backends, Restore und Check.