Restic GUI: Backrest und die Alternativen im Überblick

Restic GUI für den Server: die kurze Antwort

Wer eine Restic GUI für einen Linux-Server sucht, landet meistens bei Backrest, und das zu Recht. Backrest ist eine Weboberfläche und ein Orchestrator für restic: Sie legen Repositories und Backup-Pläne im Browser an, Backrest führt die Zeitpläne aus, listet die Snapshots auf und stellt Dateien wieder her. Cron-Jobs und eigene Shell-Skripte fallen damit weg.

restic selbst bleibt dabei unverändert. Backrest ruft das normale restic-Binary auf, und Ihre Daten liegen weiter in einem gewöhnlichen restic-Repository. Sie können also jederzeit zur Kommandozeile zurück, ohne etwas zu konvertieren.

Backrest steht unter der GPL-3.0. Am 8. November 2026 ist v1.14.1 vom 12. Juli 2026 die aktuelle Version. Diese Anleitung zeigt, wie Sie genau diese Version installieren, ohne die Oberfläche ins offene Internet zu stellen. Danach folgt ein ehrlicher Überblick über die Alternativen. Am Ende steht der Grund, warum keine Oberfläche einen Restore-Test ersetzt.

Alle Befehle in diesem Artikel führen Sie selbst auf Ihrem Server aus. Eine Weboberfläche lässt sich in einem automatischen Test nur schlecht prüfen. Deshalb steht bei jedem Schritt dabei, woran Sie ein gutes Ergebnis erkennen.

Welche Backrest-Version sollten Sie installieren?

Installieren Sie v1.14.1, und zwar mit genau diesem Tag. Die Release-Notes von v1.14.1 nennen drei Fehlerbehebungen. Zwei davon betreffen das Löschen alter Snapshots, also den Teil, den man bei einer GUI am wenigsten kontrolliert:

• Ein geplantes forget wurde still übersprungen und tauchte im Operation-Log gar nicht auf.
• Die Aufbewahrungsregel eines einzelnen Plans wurde still übersprungen, wenn der forget-Zeitplan des Repositorys deaktiviert war.
• Der Download einzelner Dateien aus einem Snapshot schlug fehl, nachdem sich die ID eines Repositorys geändert hatte.

Die Seite zu v1.14.1 führt das Problem mit der Plan-Aufbewahrung zusätzlich schon unter den Korrekturen von 1.14.0 auf. Welche älteren Versionen genau betroffen sind, steht dort nicht. Die praktische Folge ist trotzdem klar: Wenn Sie eine ältere Backrest-Version betreiben, aktualisieren Sie zuerst, bevor Sie sich auf die Aufbewahrung verlassen. Ein Fehler dieser Art fällt nicht auf, weil nichts abbricht. Das Repository wächst einfach weiter, bis der Speicher voll ist.

Das gebündelte restic ist übrigens schon mit v1.14.0 auf v0.19.1 gestiegen, nicht erst mit v1.14.1. Das ist auch die aktuelle restic-Version: Upstream hat v0.19.1 am 5. Juli 2026 veröffentlicht.

Warum ein fester Tag statt latest? Weil latest bei jedem docker compose pull ohne Rückfrage auf eine neue Version springt. Mit einem festen Tag entscheiden Sie selbst, wann Sie die Release-Notes lesen und aktualisieren. In der GitHub Container Registry gibt es die Tags v1.14.1 und v1.14.1-alpine für dasselbe Alpine-Image sowie v1.14.1-scratch für ein minimales Image.

Wie findet Backrest sein restic-Binary?

Backrest bringt restic nicht zwingend selbst mit. Es sucht beim Start in dieser Reihenfolge, so steht es im Quellcode für Linux und macOS:

1. Ist die Umgebungsvariable BACKREST_RESTIC_COMMAND gesetzt, nimmt Backrest genau diese Datei. Passt die Version nicht, gibt es nur eine Warnung. Fehlt die Datei, bricht Backrest mit einem Fehler ab und sucht nicht weiter.
2. Sonst prüft Backrest ein restic im $PATH. Besteht es die Versionsprüfung, wird es benutzt.
3. Sonst lädt Backrest eine passende Version in sein Datenverzeichnis herunter und hält sie aktuell. Den Download prüft es gegen eine GPG-signierte Prüfsummendatei.

Die Dokumentation nennt keine Mindestversion. Der Quellcode von v1.14.1 tut es: RequiredResticVersion = "0.19.1". Ein älteres restic lehnt Backrest ab. Ein neueres akzeptiert es mit einer Warnung im Log.

Das hat eine direkte Folge für Ubuntu 24.04. Das Paket restic aus universe hat dort die Version 0.16.4, auch in den Security-Updates (0.16.4-2ubuntu0.24.04.3). Das ist älter als 0.19.1, also benutzt Backrest es nicht. Im Log steht dann eine Zeile nach diesem Muster:

restic binary "/usr/bin/restic" in $PATH is not being used, it may not be supported by backrest: ...

Danach lädt Backrest sein eigenes restic herunter. Das ist kein Fehler. Sie haben dann nur zwei restic-Versionen auf dem System: Auf der Kommandozeile bleibt das alte 0.16.4 im Pfad, für die Oberfläche läuft 0.19.1. Wenn Sie beide gleich halten wollen, setzen Sie BACKREST_RESTIC_COMMAND auf ein restic 0.19.1, das Sie selbst installiert haben.

Im Docker-Image stellt sich die Frage nicht. Das Image lädt restic schon beim Bauen herunter und legt es unter /bin/restic ab. Der Container lädt zur Laufzeit also nichts nach. Laut README enthält das Image außerdem rclone.

Backrest mit Docker Compose sicher starten

Hier liegt die wichtigste Falle. Laut README lauscht Backrest bei der normalen Installation auf 127.0.0.1:9898, im Docker-Image aber auf 0.0.0.0:9898. Das Compose-Beispiel im README veröffentlicht den Port als "9898:9898". Docker bindet so einen Port an alle Adressen des Hosts, also auch an die öffentliche IP Ihres VPS.

Eine Firewall mit ufw hilft dabei nicht. Docker leitet veröffentlichte Ports in der nat-Tabelle um, bevor die Regeln von ufw greifen. Die Docker-Dokumentation sagt dazu selbst, dass Ihre Firewall-Konfiguration damit praktisch ignoriert wird. Die Einzelheiten stehen in warum Docker-Ports die ufw-Regeln umgehen. Für Backrest heißt das: Wer "9898:9898" schreibt, stellt die Verwaltung aller Backups ins Internet, auch wenn ufw status etwas anderes behauptet.

Die Lösung ist eine Zeile. Veröffentlichen Sie den Port nur auf 127.0.0.1. Dann kann laut Docker-Dokumentation nur noch der Docker-Host selbst den Port erreichen. Legen Sie ein Verzeichnis an, zum Beispiel /opt/backrest, und darin diese compose.yaml:

services:
  backrest:
    image: ghcr.io/garethgeorge/backrest:v1.14.1
    volumes:
      - ./backrest/data:/data
      - ./backrest/config:/config
      - ./backrest/cache:/cache
      - ./backrest/tmp:/tmp
      - /srv/daten:/userdata
    environment:
      - BACKREST_DATA=/data
      - BACKREST_CONFIG=/config/config.json
      - XDG_CACHE_HOME=/cache
      - TMPDIR=/tmp
      - TZ=Europe/Berlin
    ports:
      - "127.0.0.1:9898:9898"
    restart: unless-stopped

Gegenüber dem README ersetzt der feste Tag das latest, und vor dem Port steht 127.0.0.1. Die Zeitzone ist auf Europe/Berlin gesetzt. /srv/daten steht für das Verzeichnis, das Sie sichern wollen. Im Container erscheint es unter /userdata, und diesen Pfad tragen Sie später im Backup-Plan ein. Wenn Ihnen Compose noch neu ist, erklärt Docker Compose auf einem VPS die Grundlagen.

Starten Sie den Container und prüfen Sie sofort, wo der Port wirklich lauscht:

sudo docker compose up -d
sudo docker compose port backrest 9898
sudo ss -tlnp | grep 9898

docker compose port sollte 127.0.0.1:9898 ausgeben, und ss sollte nur eine Zeile mit 127.0.0.1:9898 zeigen. Steht dort 0.0.0.0:9898 oder [::]:9898, ist die ports-Zeile nicht angekommen. Beheben Sie das, bevor Sie irgendetwas anderes tun.

Eine Einschränkung gilt für ältere Docker-Versionen. Laut Docker-Dokumentation konnten vor Docker Engine 28.0.0 andere Rechner im selben Layer-2-Netz auch Ports erreichen, die nur auf localhost veröffentlicht waren. Prüfen Sie die Zeile Version im Abschnitt Server von sudo docker version. Liegt sie unter 28, aktualisieren Sie Docker.

Ohne Docker: das Installationsskript

Für Linux und macOS gibt es ein Installationsskript. Es legt das Binary nach /usr/local/bin und richtet den Autostart ein, unter Linux mit systemd oder OpenRC. Laden Sie es herunter und lesen Sie es, bevor Sie es ausführen:

curl -fsSL https://raw.githubusercontent.com/garethgeorge/backrest/main/install.sh -o backrest-install.sh
less backrest-install.sh
bash backrest-install.sh
sudo ss -tlnp | grep 9898

Die letzte Zeile sollte 127.0.0.1:9898 zeigen, denn das ist bei dieser Installationsart der Standard. Zwei Optionen des Skripts sollten Sie kennen. --allow-remote-access bindet Backrest an alle Schnittstellen. Auf einem VPS mit öffentlicher IP lassen Sie diese Option weg. --root installiert den Dienst für root statt für Ihren Benutzer. Standard ist Ihr Benutzer, und das reicht, solange dieser Benutzer alle Dateien lesen darf, die Sie sichern wollen. Mit --uninstall entfernt das Skript den Dienst samt Autostart und das Binary wieder.

Beachten Sie: Das Skript kommt aus dem Zweig main, nicht von einem festen Tag. Wer die Version exakt festlegen will, ist mit dem Docker-Image v1.14.1 besser bedient.

Die Adresse lässt sich bei beiden Wegen über BACKREST_PORT ändern. Das README nennt als Beispiel BACKREST_PORT=0.0.0.0:9898 für alle Schnittstellen. Auf einem Server brauchen Sie das nicht, wenn Sie einen der folgenden Zugänge nutzen.

Wie erreichen Sie die Weboberfläche von außen?

Die Oberfläche lauscht jetzt nur lokal. Sie erreichen sie trotzdem bequem, auf einem von zwei Wegen.

Über einen SSH-Tunnel

Das funktioniert ohne zusätzliche Software. Auf Ihrem eigenen Rechner:

ssh -N -L 9898:127.0.0.1:9898 benutzer@ihr-server

Solange dieser Befehl läuft, öffnen Sie im Browser http://localhost:9898. Der Verkehr läuft verschlüsselt durch die SSH-Verbindung. Meldet ssh bind [127.0.0.1]:9898: Address already in use, belegt auf Ihrem Rechner schon ein anderes Programm den Port 9898. Nehmen Sie dann lokal einen anderen, etwa -L 19898:127.0.0.1:9898.

Über Tailscale Serve

Wenn Server und Laptop schon im selben Tailnet sind, ist Tailscale Serve bequemer. Serve leitet Verkehr von anderen Geräten in Ihrem Tailnet an einen lokalen Dienst weiter. Es ist nur im Tailnet erreichbar. Öffentlich wäre erst Tailscale Funnel, und das wollen Sie hier nicht.

sudo tailscale serve --bg 9898
sudo tailscale serve status

--bg lässt Serve im Hintergrund laufen. status zeigt die Adresse, nach dem Muster https://<gerät>.<tailnet>.ts.net. Serve braucht HTTPS-Zertifikate im Tailnet. Sind sie noch nicht aktiviert, führt die CLI Sie über eine Webseite durch die Zustimmung. Abschalten können Sie Serve mit sudo tailscale serve reset. Die ACLs Ihres Tailnets gelten auch für Serve. Damit legen Sie fest, welche Geräte die Oberfläche überhaupt erreichen.

Den ersten Benutzer sofort anlegen

Beim ersten Aufruf fragt Backrest nach einem Benutzernamen und einem Passwort. Legen Sie diesen Benutzer sofort an, direkt nach dem ersten Start. Ob eine noch nicht eingerichtete Instanz jedem Besucher erlaubt, den ersten Admin anzulegen, steht nicht in der Dokumentation. Gehen Sie also davon aus, dass es so ist, und lassen Sie keine Lücke.

Haben Sie das Passwort vergessen, löschen Sie den Schlüssel "users" aus der config.json und starten Backrest neu. Bei der Docker-Variante oben liegt die Datei unter ./backrest/config/config.json, bei der normalen Installation unter ~/.config/backrest/config.json. Danach fragt Backrest wieder nach einem neuen Benutzer.

Die Dokumentation erlaubt auch, die Anmeldung ganz abzuschalten: für lokale Installationen oder hinter einem Reverse Proxy, der selbst authentifiziert. Auf einem VPS lassen Sie die Anmeldung an. Das Passwort bleibt auch hinter einem SSH-Tunnel oder Tailscale aktiv.

Vertrauen Sie der Aufbewahrung erst, wenn Sie sie gesehen haben

Legen Sie in der Oberfläche ein Repository an und dann einen Plan mit Zeitplan und Aufbewahrungsregel. Wer das Repository auf einen zweiten Server oder eine Storage-Box legen will, findet in Storage-VPS oder verwaltete Storage-Box die Abwägung.

Nach den ersten geplanten Läufen prüfen Sie zwei Dinge. Im Operation-Log sollten neben den Backups auch forget-Läufe stehen. Genau die waren vor v1.14.1 manchmal still verschwunden. Zweitens zählen Sie die Snapshots auf der Kommandozeile nach, unabhängig von der Oberfläche:

restic -r /pfad/zum/repo snapshots

Die Zahl der Snapshots sollte zu Ihrer Regel passen. Halten Sie zum Beispiel sieben tägliche Snapshots vor, sollten nach zwei Wochen nicht vierzehn tägliche in der Liste stehen. Steigt die Zahl immer weiter, läuft das Löschen nicht.

Welche Alternativen zu Backrest gibt es?

Der Überblick bei LinuxLinks vom 15. Juni 2026 nennt neun Frontends für restic. Ein Überblick sagt aber nichts darüber, ob ein Projekt noch gepflegt wird. Die Angaben unten stammen deshalb aus den Repositories der Projekte, Stand 8. November 2026.

• resticprofile ist keine GUI. Es verwaltet Konfigurationsprofile und Zeitpläne für restic, in TOML, JSON, YAML oder HCL. GPL-3.0, letzte Version v0.33.1 vom 15. April 2026. Das ist die richtige Wahl, wenn Sie Ihre Backups lieber als Datei unter Versionskontrolle halten als in einer Weboberfläche.
• Restic Browser ist ein Desktop-Programm, mit dem Sie bestehende Repositories durchsuchen und Dateien wiederherstellen. Das README sagt ausdrücklich, dass es keine vollständige Backup-GUI ist. Es braucht restic im PATH. MIT-Lizenz, letzte Version v0.3.3 vom 14. Oktober 2025, mit neueren Commits im Repository.
• Backrest unter Windows ist die Antwort für alle, die eine Restic GUI für den Desktop suchen. Der Installer Backrest-setup-[arch].exe legt Backrest und ein Tray-Programm nach %localappdata%\Programs\Backrest\. Das Tray-Programm startet bei der Anmeldung und überwacht Backrest. Laut Release-Notes von v1.11.2 bringt der Windows-Installer restic gleich mit.
• Zerobyte ist eine Weboberfläche auf Basis von restic, ausgelegt auf entfernte Speicherquellen wie NFS, SMB, WebDAV oder SFTP. AGPL-3.0, sehr aktiv, v0.44.1 vom 7. November 2026. Das README rät deutlich davon ab, Zerobyte auf einem Server zu betreiben, der aus dem Internet erreichbar ist. Lässt es sich nicht vermeiden, empfiehlt es "127.0.0.1:4096:4096" und einen authentifizierten Tunnel, also dasselbe Muster wie oben.
• Pluton kombiniert restic mit rclone und einer Weboberfläche. Apache-2.0, pluton-v0.22.0 vom 2. November 2026. Die Versionsnummer liegt noch unter 1.0.
• kubackup ist eine weitere Weboberfläche für restic. GPL-3.0, v1.4.0 vom 1. Juni 2026, davor v1.3.1 vom Mai 2025.
• resticterm ist eine Oberfläche für das Terminal, kein Browser-Programm. GPL-3.0, letzte Version V0.11.0.0 vom 13. Oktober 2024, mit einem Commit im Juli 2026.
• Restic Backup GX ist eine Desktop-GUI, die auf GitLab liegt. Letzte Version v0.17.4 vom 29. Juli 2026. Die Lizenz prüfen Sie bitte selbst im Repository.
• Déjà Dup ist das einfache Backup-Programm von GNOME für persönliche Daten und nutzt laut eigener Seite restic im Hintergrund. GPL-3.0 oder neuer, Version 50.2 vom 5. September 2026. Es gehört auf den Desktop, nicht auf den Server.
• Resticity steht noch in der Liste, ist aber archiviert. Der letzte Push war im April 2024. Nehmen Sie es nicht für neue Installationen.

Für einen Linux-Server mit lokalen Daten bleibt Backrest die naheliegende Wahl. Zerobyte lohnt einen Blick, wenn Ihre Quellen auf Netzlaufwerken liegen. resticprofile passt, wenn Sie gar keine Oberfläche wollen.

Warum ersetzt eine GUI keinen Restore-Test?

Eine grüne Statusanzeige sagt nur, dass restic ohne Fehler beendet wurde. Sie sagt nicht, dass Sie die Daten zurückbekommen. Das beweist nur ein Restore, den Sie wirklich ausprobiert haben.

Prüfen Sie das Repository zuerst mit restic check. Ohne Optionen prüft der Befehl die Struktur des Repositorys, etwa Snapshots und Pack-Dateien. Er liest die Pack-Dateien aber nicht vollständig. Er prüft also nicht, ob die Daten auf dem Speicher unverändert sind. Das macht erst --read-data. Weil dabei alles heruntergeladen wird, kostet das Zeit und Bandbreite. Ein guter Kompromiss ist eine zufällige Stichprobe bei jedem Lauf:

restic -r /pfad/zum/repo check --read-data-subset=5%

Dann stellen Sie tatsächlich etwas wieder her, und zwar in ein leeres Verzeichnis, nie über die Originaldaten:

restic -r /pfad/zum/repo restore latest --target /tmp/restore-test --dry-run
restic -r /pfad/zum/repo restore latest --target /tmp/restore-test

--dry-run zeigt vorher, was wiederhergestellt würde. Öffnen Sie danach ein paar Dateien in /tmp/restore-test, zum Beispiel eine Datenbank-Sicherung oder ein Dokument. Diesen Test wiederholen Sie regelmäßig. Mit Backrest klappt das genauso, denn das Repository ist ein normales restic-Repository.

Wie Sie restic auf der Kommandozeile mit Zeitplan und Aufbewahrung einrichten, steht in restic-Backups auf einem VPS einrichten. Wenn Sie noch zwischen den Werkzeugen schwanken, hilft restic oder BorgBackup im Vergleich.

FAQ

Welche restic-Version braucht Backrest?

Backrest v1.14.1 verlangt laut Quellcode mindestens restic 0.19.1 (RequiredResticVersion = "0.19.1"). Ein älteres restic im PATH wird übersprungen, ein neueres läuft mit einer Warnung. Das restic-Paket von Ubuntu 24.04 hat die Version 0.16.4. Backrest ignoriert es deshalb und lädt ein eigenes restic in sein Datenverzeichnis herunter. Das Docker-Image bringt restic unter /bin/restic schon mit.

Ist Backrest im Docker-Container von außen erreichbar?

Ja, wenn Sie das Compose-Beispiel aus dem README übernehmen. Das Image lauscht laut README auf 0.0.0.0:9898, und "9898:9898" veröffentlicht den Port auf allen Adressen des Hosts. ufw filtert solche Ports nicht, weil Docker sie vorher in der nat-Tabelle umleitet. Schreiben Sie "127.0.0.1:9898:9898" und prüfen Sie mit sudo ss -tlnp | grep 9898, dass nur 127.0.0.1:9898 erscheint.

Wie setze ich das Backrest-Passwort zurück?

Löschen Sie den Schlüssel "users" aus der config.json und starten Sie Backrest neu. Bei der normalen Installation liegt die Datei unter ~/.config/backrest/config.json, im Docker-Container dort, wohin BACKREST_CONFIG zeigt. Beim nächsten Aufruf fragt Backrest wieder nach Benutzername und Passwort. Legen Sie den Benutzer sofort an.

Ist resticprofile eine grafische Oberfläche für restic?

Nein. resticprofile verwaltet Profile und Zeitpläne für restic in einer Konfigurationsdatei, in TOML, JSON, YAML oder HCL. Eine grafische Oberfläche zeigt das README nicht. Wer Snapshots im Browser durchsuchen und wiederherstellen will, nimmt Backrest. Wer nur bestehende Repositories auf dem Desktop durchsuchen will, nimmt Restic Browser.