restic REST-Server als zentrales Backup-Target

Backups sind in vielen kleinen und mittleren Unternehmen ein Flickenteppich: Ein NAS sichert die Fileserver, eine Cloud-Lösung schützt die Notebooks, ein Skript kopiert die Datenbank irgendwohin. Wer Konsistenz und Wiederherstellbarkeit ernst nimmt, braucht ein einheitliches Backup-Target. Der restic REST-Server ist genau dafür gebaut — ein leichtgewichtiger Go-Daemon, der restic-Repositories über HTTPS bereitstellt. Kombiniert mit Per-User-Authentifizierung und Append-Only-Mode wird daraus eine ransomwareresistente Backup-Plattform, die auf jedem Linux-Server läuft.

Dieser Artikel zeigt, wie Sie den restic REST-Server (Version 0.13.x, Stand 2026) in TLS-Mode aufsetzen, mehrere Clients sauber trennen, Storage realistisch planen und die Schlüsselverwaltung in den Griff bekommen.

Architektur: Ein Host, viele Repositories

Der REST-Server ist ein einzelner Prozess, der pro Pfad ein Repository bedient. Im Mehrbenutzermodus (--private-repos) liest und schreibt jeder authentifizierte Client ausschließlich in sein eigenes Verzeichnis — der Pfad wird aus dem Benutzernamen abgeleitet:

/srv/restic/
├── srv-mail/        # Repository des Mailservers
├── srv-db/          # Repository des Datenbankservers
├── nb-mueller/      # Repository des Notebooks Müller
└── nb-schmidt/      # Repository des Notebooks Schmidt

Auf der gleichen Maschine landen also Notebooks, Server und VMs — aber jeder Client sieht nur seine eigenen Daten. Das vermeidet Cross-Contamination und macht die Rechtevergabe einfach. Ein kompromittierter Notebook-Account kann weder die Server-Backups löschen noch lesen.

Empfehlung aus der Praxis: Für eine überschaubare KMU-Umgebung mit bis zu 50 Clients reicht ein Repository pro Host. Für größere Setups oder klare Mandantentrennung lohnt sich ein Repository pro Organisationseinheit — die Deduplizierung wirkt dann zwar nur innerhalb dieser Einheit, dafür ist die Trennung sauberer und Restores sind schneller.

Installation und Systemd-Service

Der REST-Server wird als statisches Binary ausgeliefert. Wir legen einen dedizierten Systemuser an und installieren das Binary nach /usr/local/bin:

# Benutzer und Datenverzeichnis anlegen
useradd --system --home /srv/restic --shell /usr/sbin/nologin restic
install -d -o restic -g restic -m 0750 /srv/restic

# Binary holen (Version 0.13.0 - 2026)
curl -L https://github.com/restic/rest-server/releases/download/v0.13.0/\
rest-server_0.13.0_linux_amd64.tar.gz | tar -xz -C /tmp
install -m 0755 /tmp/rest-server_0.13.0_linux_amd64/rest-server /usr/local/bin/

# Htpasswd für Authentifizierung
apt install -y apache2-utils
htpasswd -B -c /srv/restic/.htpasswd srv-mail
htpasswd -B    /srv/restic/.htpasswd srv-db
htpasswd -B    /srv/restic/.htpasswd nb-mueller
chown restic:restic /srv/restic/.htpasswd
chmod 0640         /srv/restic/.htpasswd

Die Systemd-Unit /etc/systemd/system/rest-server.service:

[Unit]
Description=restic REST Server
After=network.target

[Service]
User=restic
Group=restic
ExecStart=/usr/local/bin/rest-server \
  --path /srv/restic \
  --listen 0.0.0.0:8443 \
  --htpasswd-file /srv/restic/.htpasswd \
  --private-repos \
  --append-only \
  --tls \
  --tls-cert /etc/restic/fullchain.pem \
  --tls-key  /etc/restic/privkey.pem
Restart=on-failure
ProtectSystem=strict
ReadWritePaths=/srv/restic
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Mit systemctl enable --now rest-server läuft der Dienst. Die TLS-Zertifikate können von Let’s Encrypt via DNS-01-Challenge stammen — die Erneuerung sollte über einen --deploy-hook den rest-server neu starten.

Append-Only: Der entscheidende Schutz gegen Ransomware

Das wichtigste Flag in der Konfiguration ist --append-only. Damit darf jeder Client zwar neue Snapshots anlegen, aber bestehende Daten nicht löschen oder überschreiben. Selbst wenn ein Notebook mit Ransomware infiziert wird und der Angreifer den restic-Schlüssel findet — die Backups auf dem REST-Server bleiben unangetastet.

Konkret blockiert der Server die HTTP-Methoden DELETE und das Überschreiben existierender Objekte. Ein restic forget --prune schlägt fehl. Das hat eine Konsequenz: Aufräumen muss aus einem anderen Kontext geschehen.

Die saubere Lösung: Ein separater Cronjob auf dem REST-Server-Host selbst, der mit direktem Filesystem-Zugriff (also ohne den HTTP-Layer) periodisch die Aufbewahrungsrichtlinien anwendet. Damit hat der Angreifer auf dem Client niemals die Möglichkeit, das Backup zu zerstören — nur der gut abgesicherte Backup-Host kann das.

# /etc/cron.weekly/restic-prune (läuft als root auf dem Backup-Host)
#!/usr/bin/env bash
set -euo pipefail
for repo in /srv/restic/*/; do
  pw=$(cat "${repo}.password")
  RESTIC_PASSWORD="$pw" restic -r "$repo" forget \
    --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune
done

Storage-Planung und Deduplizierung

restic deduplifiziert auf Block-Ebene mit Content-Defined Chunking. Das macht die Speicherbedarfsplanung anders als bei klassischen Voll-/Inkrementell-Konzepten. Ein realistisches Bild aus produktiven KMU-Setups:

Workload	Roh-Daten	Repository	Dedup-Ratio	Tägliche Zuwachsrate
Office-Notebooks (gemischt)	250 GB	180 GB	1,4 : 1	0,3 — 0,8 GB
Fileserver mit Office-Dokumenten	2 TB	1,1 TB	1,8 : 1	3 — 8 GB
PostgreSQL-Dump (komprimiert)	80 GB	70 GB	1,1 : 1	2 — 4 GB
VM-Images (qcow2, gleiche Basis)	600 GB	95 GB	6,3 : 1	0,5 — 2 GB
Mailserver (Maildir)	400 GB	310 GB	1,3 : 1	1 — 3 GB

Faustregel: Für 12 Monate Retention bei typischen Office-Workloads planen Sie das 1,2 - 1,8-fache der Roh-Datenmenge ein. VM-Images mit gemeinsamer Basis profitieren überproportional von der Deduplizierung — hier sind Faktoren von 5:1 und mehr realistisch. Datenbank-Dumps und bereits komprimierte Archive deduplizieren kaum, hier dominiert der lineare Zuwachs.

Wer die Platte unter dem REST-Server auf ZFS legt — etwa auf einer kleinen TrueNAS-Instanz oder einem Linux-Host mit ZFSonLinux — bekommt zusätzliche Snapshots, Scrub und Checksummen geschenkt. ZFS-Komprimierung (lz4 oder zstd) bringt bei restic-Repositories typischerweise weitere 5 - 10 Prozent, weil die Chunks bereits relativ inkompressibel sind.

Schlüsselverwaltung: Wer kennt welches Passwort?

Jedes restic-Repository hat ein eigenes Passwort, das die symmetrische Verschlüsselung (AES-256) schützt. Verlieren Sie das Passwort, sind die Daten weg — restic ist ein Zero-Knowledge-System gegenüber dem Server-Betreiber. Das ist gut für die Vertraulichkeit, aber operativ anspruchsvoll.

Praxisbewährtes Vorgehen:

1. Pro Client ein eigenes Passwort. Niemals dasselbe Passwort über mehrere Repositories.
2. Master-Key zusätzlich anlegen. Mit restic key add lässt sich pro Repository ein zweiter Schlüssel hinterlegen, der zentral im Passwortmanager des Admin-Teams liegt. So bleibt die Wiederherstellung auch dann möglich, wenn der Client-Schlüssel verloren geht.
3. Schlüssel offline sichern. Die Master-Schlüssel gehören — ausgedruckt oder auf einem verschlüsselten USB-Stick — in den Tresor. Wer hier spart, hat im Ernstfall verschlüsselte Backups, aber keinen Zugriff darauf.
4. Rotation dokumentieren. Mit restic key passwd lässt sich das Client-Passwort ändern, ohne das Repository neu zu verschlüsseln. Dokumentieren Sie Rotationen im internen Wiki.

Auf der Client-Seite empfiehlt sich, das Passwort nicht in Skripten zu hinterlegen, sondern via RESTIC_PASSWORD_FILE aus einer Datei mit 0400-Rechten zu lesen, die nur root liest. Auf Notebooks ist der Systemschlüsselbund (libsecret, Keychain) die richtige Wahl.

Client-Konfiguration und Monitoring

Ein typischer Client-Backup-Job sieht so aus:

export RESTIC_REPOSITORY="rest:https://srv-mail:passwd@backup.example.de:8443/"
export RESTIC_PASSWORD_FILE="/etc/restic/repo-password"

restic backup \
  --tag daily \
  --exclude-caches \
  --exclude /var/cache \
  --exclude /tmp \
  / /home /var

# Integritäts-Check (einmal pro Woche)
restic check --read-data-subset=10%

Wichtig ist das restic check --read-data-subset — es liest tatsächlich Daten und verifiziert die Hashes. Ein Backup, das nie zurückgespielt oder geprüft wurde, ist kein Backup. Wer den Aufwand für regelmäßige Restore-Tests scheut, sollte zumindest wöchentlich einen Prozentanteil des Repositories prüfen lassen.

Für das Monitoring eignen sich die Exit Codes plus Logfile-Auswertung. Wer DATAZONE Control nutzt, integriert die Jobs als Custom-Checks und bekommt zentrale Sicht auf alle Backup-Endpunkte — inklusive Alarmierung, wenn ein Notebook drei Tage in Folge kein Backup geliefert hat.

Off-Site-Replikation des REST-Servers

Der REST-Server ist nur die erste 3-2-1-Schicht. Ein zweites Repository an einem anderen Standort lässt sich am einfachsten mit restic copy befüllen — das überträgt nur die Chunks, die im Ziel noch nicht existieren, und ist damit bandbreitenschonend. Alternativ replizieren Sie das gesamte Datenverzeichnis mit rsync oder ZFS Send/Receive in ein Disaster-Recovery-Rechenzentrum.

In KMU-Umgebungen, in denen kein zweiter Standort existiert, ist S3-kompatibler Objekt-Storage (Wasabi, Backblaze B2, Hetzner) eine gute Option für die Off-Site-Kopie — restic kann direkt dorthin schreiben oder über restic copy aus dem REST-Server-Repository übertragen.

Fazit

Der restic REST-Server ist eines der unterschätzten Werkzeuge im Open-Source-Backup-Umfeld. In wenigen Stunden aufgesetzt, läuft er auf Standard-Hardware, schützt durch Append-Only zuverlässig gegen Ransomware und skaliert dank Deduplizierung erstaunlich weit. Für viele KMU ist er die richtige Antwort zwischen “wir nehmen einfach Veeam” und “wir brauchen gar nichts”.

DATAZONE unterstützt Sie bei Planung, Aufbau und Betrieb von restic-basierten Backup-Infrastrukturen — vom Hardware-Sizing über die Härtung des Linux-Hosts und die Konzeption Ihrer Backup-Strategie bis zum Monitoring mit DATAZONE Control. Sprechen Sie uns an, wenn Sie Ihre Backup-Landschaft konsolidieren und gegen Ransomware absichern wollen.