Restic: Verschlüsselte Backups, einfach erklärt

Ein gutes Backup-Tool muss zwei Dinge gleichzeitig leisten, die im Alltag selten zusammenfallen: Es muss schlank genug sein, dass man es täglich einsetzt, und gleichzeitig streng genug, dass die Daten am Ende auch wirklich wiederherstellbar sind. Restic versucht beides — mit Deduplication, Verschlüsselung und einem reduzierten Befehlssatz, der auf Linux, Windows und macOS identisch funktioniert.

Wir setzen Restic bei DATAZONE seit Jahren für gemischte Szenarien ein: Einzelne Linux-Server, die zu einem TrueNAS-Dataset sichern, Workstations, die zu Backblaze B2 oder Wasabi ausgehen, und kleine Edge-Hosts ohne dedizierten Backup-Server. Dieser Artikel beschreibt, was Restic gut macht, wo Grenzen liegen und wie ein Setup konkret aussieht.

Was Restic ist — und was nicht

Restic ist ein Backup-Tool für Dateien und Verzeichnisse, geschrieben in Go, statisch gelinkt, ein einzelnes Binary. Es kennt keinen Daemon, kein Tray-Icon, keine Web-UI. Was es kennt:

• Repositories: verschlüsselte Container, in denen alle Backups einer Quelle landen
• Snapshots: ein Snapshot pro restic backup-Aufruf, mit Zeitstempel und Host-Info
• Deduplication: identische Dateiblöcke werden über alle Snapshots hinweg nur einmal gespeichert
• Restore: Snapshot wählen, mounten oder herauskopieren — fertig

Was Restic nicht ist:

• Kein Image-Backup-Tool für VMs (dafür Proxmox Backup Server oder Veeam)
• Kein Application-Aware-Backup für Datenbanken im Hot-State (vorher Dump erzeugen)
• Kein Replikations-Tool für Datasets (dafür zfs send oder rsync)

Restic sichert Dateien. Wenn die zu sichernde Datei ein konsistentes Datenbank-Dump ist, läuft alles gut. Wenn es eine offene .mdb-Datei mitten in einem Schreibvorgang ist, bekommt man Datenbank-Inhalte, die nicht konsistent sind. Das ist keine Restic-Schwäche, sondern das Wesen dateibasierter Backups.

Wie Restic verschlüsselt

Jedes Repository hat ein Passwort. Daraus leitet Restic einen Master-Key ab, mit dem alle Daten verschlüsselt werden (AES-256 im CTR-Modus, mit Poly1305 als MAC). Ohne Passwort sind die Daten im Repo nicht wiederherstellbar — auch nicht für den Restic-Maintainer.

Konsequenzen für die Praxis:

• Verlierst du das Passwort, sind die Backups verloren. Punkt. Es gibt keine Recovery-Funktion.
• Schlüssel-Rotation ist möglich über restic key add / restic key remove — das Repo kann mehrere Keys gleichzeitig haben.
• Die Verschlüsselung gilt at-rest und in-flight. Wer auf B2 oder SFTP pusht, sendet bereits verschlüsselte Pakete — der Storage-Provider sieht nichts Lesbares.

Das Passwort sollte aus einem Passwort-Manager kommen (z.B. Vaultwarden), und es sollte auf einem zweiten Medium gesichert sein, das nicht im selben Backup-Vorgang gesichert wird. Klassischer Fehler: Das Passwort liegt in /root/.restic-pw, das per Restic mitgesichert wird — bei Verlust des Originals ist das Passwort genau dort, wo es nichts nützt.

Repository-Typen

Restic spricht von Haus aus mehrere Backends — alle mit der gleichen Datenstruktur, austauschbar pro Verzeichnis:

Backend	Typischer Use Case	Hinweis
local	Backup auf gleichen Host (Test)	Kein Disaster-Recovery — Quelle und Ziel teilen dasselbe Schicksal
sftp	Backup zu Linux-Server, TrueNAS, NAS	Performance hängt am SSH-Stack
rest	Backup zu Rest-Server (eigener oder Hosting)	Append-Only-Modus möglich — empfohlen
s3	AWS S3 oder kompatibel (Wasabi, MinIO, TrueNAS S3)	Default-Wahl für Cloud
b2	Backblaze B2	Günstig für Long-Term-Storage
azure	Azure Blob Storage	Für M365-Umfelder mit eigenem Tenant
gs	Google Cloud Storage	Selten in DE/AT — wegen Datenresidenz
swift	OpenStack Swift	OVH, Hetzner Object Storage etc.
rclone	Beliebiges rclone-Remote	Universal-Fallback

Wir bevorzugen in der Praxis drei Kombinationen:

1. sftp zu TrueNAS — für Server-Backups innerhalb einer LAN-Umgebung
2. b2 — für Workstations und Edge-Hosts, die kein internes Backup-Ziel sehen
3. rest mit Append-Only — wenn ein dedizierter Linux-Backup-Server ohnehin steht und Ransomware-Resilience gefragt ist

Setup 1: Server-Backup zu TrueNAS

Konkretes Szenario: Ein Mailserver soll seine Konfiguration und Mail-Spool täglich zu einem TrueNAS-Dataset sichern. Auf dem TrueNAS gibt es ein Dataset tank/backup/restic-mailserver, der Zugriff erfolgt über einen dedizierten User mit SSH-Key.

# Einmalig: Repository anlegen
export RESTIC_REPOSITORY="sftp:restic@truenas.lan:/mnt/tank/backup/restic-mailserver"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
restic init

# Tägliches Backup
restic backup \
  /etc \
  /var/mail \
  /var/log/mail \
  --exclude-caches \
  --tag mailserver-daily

# Aktuelle Snapshots anzeigen
restic snapshots

Das Passwort liegt in /etc/restic/password, Mode 0600, owner root. Der SSH-Key des restic-Users hat auf TrueNAS nur Zugriff auf das Dataset des Hosts — kein Schreibrecht auf andere Datasets. Damit kann ein kompromittierter Mailserver maximal seine eigenen Snapshots überschreiben, nicht die anderer Hosts.

Cron-Job mit Logging

# /etc/cron.d/restic
30 02 * * * root /usr/local/sbin/restic-daily 2>&1 | logger -t restic

Das Wrapper-Skript /usr/local/sbin/restic-daily:

#!/bin/bash
set -euo pipefail
export RESTIC_REPOSITORY="sftp:restic@truenas.lan:/mnt/tank/backup/restic-mailserver"
export RESTIC_PASSWORD_FILE="/etc/restic/password"

restic backup /etc /var/mail /var/log/mail \
  --exclude-caches --tag mailserver-daily

restic forget \
  --keep-daily 14 --keep-weekly 8 --keep-monthly 12 \
  --prune --tag mailserver-daily

restic forget --prune entfernt sowohl Snapshots als auch nicht mehr referenzierte Daten-Blöcke. Auf großen Repos läuft das nicht jeden Tag — viele setzen das wöchentlich an und lassen täglich nur restic forget (ohne Prune) laufen.

Setup 2: Workstation-Backup zu Backblaze B2

Backblaze B2 ist für Restic ein angenehmes Cloud-Ziel: keine API-Komplexität, niedriger Storage-Preis und Egress nur für tatsächliche Restores. Für eine Workstation mit ca. 200 GB Daten liegt der Monatspreis im Cent-Bereich, solange kein Restore ansteht.

# Credentials aus B2-Application-Key
export B2_ACCOUNT_ID="0021abc..."
export B2_ACCOUNT_KEY="K0021..."
export RESTIC_REPOSITORY="b2:datazone-restic-workstations:laptop-fs"
export RESTIC_PASSWORD_FILE="/Users/fs/.restic/password"

# Repo anlegen
restic init

# Backup
restic backup \
  /Users/fs/Documents \
  /Users/fs/Projects \
  /Users/fs/Library/Mail \
  --exclude "*.iso" \
  --exclude "node_modules" \
  --exclude-caches

Auf macOS lässt sich das per launchd-Job stündlich auslösen, auf Windows per Task-Scheduler. Wichtig:

• Application-Key statt Master-Key verwenden — der Application-Key kann auf einen Bucket beschränkt werden
• Keinen Master-Key in Skripte schreiben — bei Kompromittierung verliert man den kompletten B2-Account
• Lifecycle-Policy im B2-Bucket setzen — alte Versionen werden sonst kostenpflichtig kumuliert

Snapshots, Tags und der mentale Modell

Ein Restic-Snapshot ist nicht wie ein ZFS-Snapshot ein blockbasiertes Inkrement. Es ist eine Liste von Datei-Inhalten zum Zeitpunkt des Backups, wobei jeder Datei-Inhalt nur einmal physikalisch gespeichert wird. Wenn am Mittwoch eine 4-GB-VM-Datei zum Snapshot dazukommt und am Donnerstag eine identische 4-GB-Datei woanders auf dem System landet, belegt sie keinen zusätzlichen Platz — Restic erkennt das per Block-Hash.

Tags helfen, mehrere Backup-Aufgaben in einem Repo zu trennen:

restic backup /etc --tag system-config
restic backup /var/mail --tag mail-spool
restic forget --keep-daily 7 --tag system-config --prune
restic forget --keep-daily 30 --tag mail-spool --prune

So bleibt für jeden Tag ein eigener Retention-Plan. Praxis-Hinweis: Tags immer setzen — sonst greifen forget-Regeln über alle Snapshots des Repos hinweg und löschen unter Umständen Dinge, die behalten werden sollten.

Restore in drei Befehlen

Der häufigste Restore-Fall ist: “Ich brauche die nginx.conf von vor drei Tagen, sonst nichts.” Restic löst das per mount:

mkdir /mnt/restic
restic mount /mnt/restic &
ls /mnt/restic/snapshots/2026-05-08T02:30:00/etc/nginx/
cp /mnt/restic/snapshots/2026-05-08T02:30:00/etc/nginx/nginx.conf /etc/nginx/
fusermount -u /mnt/restic

Für einen vollständigen Restore eines Verzeichnisses:

restic restore latest --target /restore --include /etc

Restic kennt Snapshot-IDs (abc12345), den Alias latest, sowie Filter wie --host und --tag. Für skript-basierte Restores ist --json der Lebensretter — Restic kann JSON-strukturiert ausgeben, was sich in Wrapper-Skripte und Monitoring-Hooks gut integrieren lässt.

Integrität: restic check

Eine der wichtigsten Operationen wird oft vergessen: restic check. Sie verifiziert, dass alle Index-Einträge im Repo zu echten Daten-Blöcken zeigen und keine Korruption vorliegt. Empfehlung:

# Wöchentlich, Metadaten-Check
restic check

# Monatlich, vollständige Integritätsprüfung (lädt alle Daten)
restic check --read-data

Der --read-data-Check ist bei Cloud-Backends wie B2 mit Download-Kosten verbunden — Alternative ist --read-data-subset=10%, das einen rotierenden Anteil prüft.

Wenn check Fehler meldet, gibt es zwei sinnvolle Reaktionen:

1. restic rebuild-index — Index neu aufbauen, behebt viele Symptome
2. restic prune mit altem Snapshot, dann erneuter Vollscan — wenn echte Daten-Korruption vorliegt

Hat das Repo dauerhaft Datenverlust, hilft nur ein anderes, paralleles Backup-Ziel. Daher: Ein Repo ist kein Backup. Zwei unabhängige Repos auf unterschiedlichen Medien sind das Minimum, das wir empfehlen.

Append-Only und Ransomware-Resilience

Restic kann Repos im Append-Only-Modus schreiben — das heißt: Der schreibende Client darf hinzufügen, aber nicht löschen oder überschreiben. Damit wird das Repo gegen kompromittierte Clients geschützt: Ein Angreifer mit Root-Rechten auf dem zu sichernden Host kann die Backups nicht aus dem Repo löschen.

Die einfachste Variante ist der REST-Server mit --append-only:

# Auf dem Backup-Server
docker run -d \
  -p 8000:8000 \
  -v /backup/restic:/data \
  -e OPTIONS="--append-only --private-repos" \
  restic/rest-server:latest

Der Client pusht mit restic backup -r rest:https://backup.lan:8000/host1 — kann aber kein forget und kein prune mehr ausführen. Das macht ein separater Wartungs-Job, der ohne --append-only läuft, idealerweise auf einem isolierten Admin-Host mit eigenen Credentials.

Auf TrueNAS lässt sich Vergleichbares mit read-only Snapshots des Backup-Datasets erreichen: Die letzten 30 Snapshots stehen für Restic-Repo-Recovery zur Verfügung, auch wenn ein kompromittierter Client das Live-Repo manipuliert. Beides kombiniert (Append-Only + ZFS-Snapshots) ist das robusteste Setup, das wir kennen.

Vergleich kurz: Borg, Kopia, Duplicacy

Restic ist nicht alleine. Drei häufig genannte Alternativen:

Tool	Stärke	Schwäche
Borg	Reife, Kompression einstellbar, sehr effizient	Kein S3 nativ — braucht borgbase/rclone-Wrapper
Kopia	GUI, Block-basierte Replikation, modern	Jünger, weniger Praxis-Erfahrung im Enterprise
Duplicacy	Lock-free, parallele Backups zu einem Repo	Lizenz-Modell (kostenpflichtig für kommerzielle Nutzung)

Wir setzen Borg dort ein, wo nur Linux-Hosts und nur SSH-Targets gebraucht werden und Kompressions-Tuning eine Rolle spielt. Restic gewinnt, wenn gemischte Umgebungen (Linux + macOS + Windows) und direkte Cloud-Anbindung wichtig sind. Kopia ist ein guter Kandidat, wenn eine GUI gewünscht ist (z.B. für nicht-technische Power-User auf Workstations).

Was wir bei DATAZONE empfehlen

Für ein typisches KMU-Setup mit 5–20 Linux-Servern, einigen Workstations und einem zentralen TrueNAS sieht ein bewährtes Restic-Setup so aus:

1. TrueNAS-Dataset tank/backup/restic als primäres Ziel, pro Host eigener Sub-Pfad und eigener SFTP-User
2. REST-Server-Container im Append-Only-Modus auf einem Linux-Backup-Host vor dem TrueNAS, der den Append-Only-Schutz auch ohne TrueNAS-Snapshot bietet
3. Backblaze B2 oder Hetzner Object Storage als Offsite-Ziel, einmal täglich per restic copy aus dem primären Repo gespeist
4. Monatlicher restic check --read-data auf einer Probe von 10 % des Cloud-Repos, vollständig auf dem lokalen Repo
5. Dokumentierter Restore-Test alle drei Monate mit echtem Wiederherstellungs-Drill — sonst ist es kein Backup, sondern Hoffnung

Wer mehr zu Backup-Tests wissen will, findet die Details in unserem Folge-Artikel zum Backup-Test-Tag.

Fazit

Restic ist nicht das aufwendigste Backup-Tool — und genau das ist seine Stärke. Ein Binary, ein Befehlssatz, plattformübergreifend, verschlüsselt by default. Es löst die Datei-Backup-Aufgabe für gemischte Umgebungen so unprätentiös wie wenige andere Tools. Was es nicht ersetzt, ist die Disziplin, Restore-Tests durchzuführen und das Passwort an einem Ort zu hinterlegen, der nicht selbst Teil des Backups ist.

Für die VM- und Image-Welt empfehlen wir ergänzend Proxmox Backup Server — und für die Storage-Seite, die alles zusammenhält, lohnt ein Blick auf den TrueNAS-Konfigurator.

Quellen

• Restic offizielle Dokumentation
• Restic Repository auf GitHub
• REST-Server auf GitHub
• Backblaze B2 Application-Keys