Laut Veeam/Sophos-Daten aus 2024/2025 greifen Angreifer in 96 % aller Ransomware-Attacken zuerst die Backup-Infrastruktur an und löschen oder verschlüsseln in 76 % der Fälle die Backups, bevor sie Produktivdaten anfassen. Die 3-2-1-1-0-Regel ergänzt 3-2-1 deshalb um eine immutable Kopie (vierte Ziffer) und null verifikationsfreie Backups (fünfte Ziffer). Diese Anleitung richtet auf einer Hetzner Storage Box ein append-only-Repository ein, das selbst ein kompromittierter Backup-Client nicht löschen kann.

Voraussetzungen

Linux-Server oder NAS als Backup-Client (x86_64 oder ARM64) mit restic ab 0.18 (aktuell 0.19.1); rclone läuft auf der Storage Box und ist dort vorhanden
Client: 1 CPU-Kern und 1 GB freies RAM für kleine bis mittlere Datenmengen (bei Millionen Dateien mehr), einige GB für den restic-Cache
Hetzner Storage Box in passender Größe (BX11: 1 TB, BX21: 5 TB, BX31: 10 TB, BX41: 20 TB)
SSH-Zugang zur Storage Box über Port 23 (nicht 22)
Ein separates, offline gesichertes System für den Admin-Key (prune-Berechtigung)
Passwortmanager oder gesichertes Medium für das restic-Repository-Passwort (AES-256, ohne Passwort keine Wiederherstellung)
Optional: zweite Storage Box in anderem Rechenzentrum (FSN1 vs. HEL1) für echtes Air-Gap

Schritt 1: Die 3-2-1-1-0-Regel verstehen

Die beiden neuen Ziffern im Überblick:

Ziffer	Bedeutung	Umsetzung in dieser Anleitung
3	3 Kopien der Daten	Produktiv + lokales NAS/Backup-Server + Hetzner Storage Box
2	2 verschiedene Medientypen	z.B. lokale SSD/HDD + Cloud-Objekt-Storage
1	1 Kopie Offsite	Hetzner Storage Box (externes Rechenzentrum)
1	1 immutable/air-gapped Kopie	append-only-Repository: Client kann nicht löschen
0	0 verifikationsfreie Backups	`restic check --read-data` + Probe-Restore

Die vierte Ziffer schützt vor Ransomware: Auch mit vollem Zugriff auf den Backup-Server löscht ein Angreifer mit dem append-only-Key keine Snapshots. Die fünfte Ziffer verhindert, dass Sie korrupte Backups erst im Ernstfall bemerken, typisch ohne regelmäßige Restore-Tests.

Verifizieren: Sie können für jede der fünf Ziffern benennen, welches System oder welcher Prozess sie in Ihrer Umgebung abdeckt; fehlt eine Zuordnung, ist die Regel noch nicht erfüllt.

Schritt 2: SSH-Key erzeugen und auf die Storage Box hochladen

Sie benötigen zwei SSH-Keys: einen append-only-Key für den Backup-Client (nur schreiben) und einen Admin-Key für forget/prune, der nicht auf dem Backup-Client liegt.

# Append-only-Key fuer den Backup-Client erzeugen:
ssh-keygen -t ed25519 -C "restic-backup-appendonly" -f ~/.ssh/id_restic_hetzner

# Oeffentlichen Key auf die Storage Box hochladen (Port 23, ergaenzt vorhandene Keys):
cat ~/.ssh/id_restic_hetzner.pub | ssh -p 23 uXXXXX@uXXXXX.your-storagebox.de install-ssh-key

# Admin-Key (auf einem SEPARATEN, offline gesicherten System erzeugen):
ssh-keygen -t ed25519 -C "restic-admin-prune" -f ~/.ssh/id_restic_admin

Wichtig: Hetzner erwartet OpenSSH-Format in authorized_keys. PuTTY-Keys vorher mit ssh-keygen -i -f key.pub konvertieren; falsch formatierte Zeilen ignoriert der Server still, der Forced-Command greift dann nicht. install-ssh-key ist der dokumentierte Weg und überschreibt keine bestehenden Einträge.

Verifizieren: ssh -p 23 -i ~/.ssh/id_restic_hetzner uXXXXX@uXXXXX.your-storagebox.de ls listet das Home-Verzeichnis der Storage Box ohne Passwortabfrage.

Schritt 3: Forced Command in authorized_keys setzen (der Kern des Schutzes)

Der Forced-Command sorgt dafür, dass jede SSH-Verbindung mit dem append-only-Key nur rclone serve restic --stdio --append-only ausführt. Die Storage Box hat keinen Editor: Laden Sie .ssh/authorized_keys mit scp -P 23 uXXXXX@uXXXXX.your-storagebox.de:.ssh/authorized_keys . herunter, ändern Sie die Zeile des Backup-Keys lokal und laden Sie die Datei auf demselben Weg hoch. Die Zeile muss exakt so aussehen:

restrict,command="rclone serve restic --stdio --append-only ./restic-repo" ssh-ed25519 AAAA...

restrict deaktiviert Port-Forwarding, PTY-Allocation und X11-Forwarding. ./restic-repo ist relativ zum Home-Verzeichnis. Den Admin-Key tragen Sie mit demselben Forced-Command ohne --append-only ein; sein privater Schlüssel liegt nie auf dem Backup-Client.

restrict,command="rclone serve restic --stdio ./restic-repo" ssh-ed25519 AAAA...(Admin-Key)

Sub-Accounts: Bis zu 100 je Storage Box. Richten Sie je Server einen ein; jeder ist im Home-Verzeichnis gechrootet, mit eigenen SSH-Schlüsseln und eigenem 10-Connection-Limit.

Verifizieren: ssh -p 23 -i ~/.ssh/id_restic_hetzner uXXXXX@uXXXXX.your-storagebox.de öffnet keine Shell mehr, sondern die Verbindung bleibt stumm (rclone wartet auf Eingaben) und lässt sich mit Strg+C beenden.

Schritt 4: Repository initialisieren

Die einmalige Initialisierung läuft über den Forced-Command aus Schritt 3: append-only erlaubt das Anlegen neuer Dateien und Verzeichnisse, also init; verboten sind nur Überschreiben und Löschen.

# Repository-Passwort in Datei speichern (mindestens 32 zufaellige Zeichen):
# openssl rand -base64 32 > /etc/restic/password.txt
# chmod 600 /etc/restic/password.txt

export RESTIC_PASSWORD_FILE=/etc/restic/password.txt

# Repository initialisieren (einmalig, ueber den Forced-Command):
restic \
  -o rclone.program='ssh -p 23 -i /root/.ssh/id_restic_hetzner \
    -o StrictHostKeyChecking=yes uXXXXX@uXXXXX.your-storagebox.de' \
  -r rclone: \
  init

-r rclone: ohne Pfad ist gewollt: Den Pfad legt der Forced-Command fest.

Verifizieren: Die Ausgabe endet mit created restic repository … at rclone:, und ein anschließendes restic … snapshots (Befehl siehe Schritt 6) läuft ohne Fehler und listet noch keine Snapshots.

Schritt 5: SSH-Config einrichten

Ein ~/.ssh/config-Eintrag vereinfacht alle folgenden Befehle:

Host hetzner-storagebox
  Hostname uXXXXX.your-storagebox.de
  User uXXXXX
  Port 23
  IdentityFile /root/.ssh/id_restic_hetzner
  StrictHostKeyChecking yes
  Compression no
  ServerAliveInterval 60
  ServerAliveCountMax 240

Achtung: Compression no explizit setzen. restic komprimiert seit v0.14 selbst; SSH-Kompression kostet zusätzlich CPU und bremst.

Verifizieren: ssh -G hetzner-storagebox | grep -E '^(port|compression|identityfile)' zeigt port 23, compression no und den Pfad zum Backup-Key.

Schritt 6: Erstes Backup durchführen und Connection-Limit beachten

Die Storage Box erlaubt maximal 10 gleichzeitige Verbindungen pro Account. Jeder restic-Aufruf über rclone.program belegt eine SSH-Verbindung; rclone.connections (Standard 5) regelt nur parallele Anfragen darin. Greifen mehrere Server oder Jobs auf denselben Account zu: Sub-Accounts, Backup-Zeiten staffeln.

restic \
  -o rclone.program='ssh hetzner-storagebox' \
  -o rclone.connections=5 \
  -r rclone: \
  --verbose \
  backup /home /etc /var/www

Prüfen Sie nach dem ersten Backup die Snapshot-Liste:

restic \
  -o rclone.program='ssh hetzner-storagebox' \
  -r rclone: \
  snapshots

Verifizieren: Die Snapshot-Liste zeigt einen Eintrag mit aktuellem Zeitstempel und den Pfaden /home /etc /var/www. Ein Test mit restic … forget latest über den Backup-Key muss mit einem Fehler (HTTP 403) scheitern.

Schritt 7: Automatisierung mit systemd-Timer

Systemd-Timer holen verpasste Ausführungen nach, anders als Cron. Details: Anleitung zu systemd-Services.

# /etc/restic/env – Umgebungsvariablen fuer den Service:
RESTIC_PASSWORD_FILE=/etc/restic/password.txt
RCLONE_PROGRAM=ssh hetzner-storagebox
RESTIC_REPOSITORY=rclone:
RESTIC_OPTS=-o rclone.connections=5

# /etc/systemd/system/restic-backup.service:
[Unit]
Description=Restic Backup to Hetzner Storage Box
After=network.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/local/bin/restic \
  -o rclone.program=${RCLONE_PROGRAM} \
  -o rclone.connections=5 \
  -r rclone: \
  backup /home /etc /var/www
ExecStartPost=/usr/local/bin/restic \
  -o rclone.program=${RCLONE_PROGRAM} \
  -r rclone: \
  check

# /etc/systemd/system/restic-backup.timer:
[Unit]
Description=Daily Restic Backup Timer

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

# Timer aktivieren:
systemctl enable --now restic-backup.timer
systemctl status restic-backup.timer

Für check --read-data (lädt alle Pack-Dateien, dauert lange) empfiehlt sich ein separater wöchentlicher Timer. Liegt restic aus dem Distributionspaket unter /usr/bin/restic, passen Sie ExecStart an.

Verifizieren: systemctl list-timers restic-backup.timer zeigt die nächste Ausführung; nach einem manuellen Lauf mit systemctl start restic-backup.service meldet journalctl -u restic-backup.service snapshot … saved und no errors were found.

Schritt 8: Integritätsprüfung – die „0“ der 3-2-1-1-0-Regel

Die fünfte Ziffer: kein Backup ohne Verifikation, auf zwei Ebenen:

# Metadaten-Check (schnell, laeuft taeglich):
restic \
  -o rclone.program='ssh hetzner-storagebox' \
  -r rclone: \
  check

# Vollstaendiger Daten-Integritaetscheck (langsam, taeglich/woechentlich):
restic \
  -o rclone.program='ssh hetzner-storagebox' \
  -r rclone: \
  check --read-data

# Fuer grosse Repositories – Stichproben-Check (10 % der Packs):
restic \
  -o rclone.program='ssh hetzner-storagebox' \
  -r rclone: \
  check --read-data-subset=10%

restic check ohne --read-data prüft nur Metadaten und Index, keine Pack-Dateien (Bitrot, stille Storage-Fehler). Für „0 Fehler“ mindestens monatlich vollständig oder als 10-%-Stichprobe prüfen.

Den Beweis der Wiederherstellbarkeit liefert nur ein Probe-Restore auf einem getrennten System:

# Probe-Restore auf ein isoliertes Verzeichnis (anderes System oder VM):
restic \
  -o rclone.program='ssh hetzner-storagebox' \
  -r rclone: \
  restore latest \
  --target /tmp/restic-restore-test \
  --include /etc/hostname

# Ergebnis pruefen:
ls -la /tmp/restic-restore-test/etc/hostname

# Danach aufraeumen:
rm -rf /tmp/restic-restore-test

Automatisieren Sie den Probe-Restore per Cron-Job oder systemd-Timer mit Meldung per Mail oder Monitoring. Erst ein erfolgreicher Restore auf einem anderen System erfüllt die fünfte Ziffer (Backup-Restore-Testroutine).

Verifizieren: restic check --read-data-subset=10% endet mit no errors were found, und die wiederhergestellte Datei ist mit dem Original identisch (diff ohne Ausgabe).

Schritt 9: Prune-Strategie über separaten Admin-Key

Im append-only-Modus läuft restic forget, prune wirkt aber nicht, da rclone DELETE-Requests verwirft; das Repository wächst unbegrenzt. Housekeeping erledigen Sie mit dem Admin-Key aus Schritt 3 ohne --append-only, gespeichert nur offline oder auf einem separaten, gehärteten System:

# Nur vom separaten Admin-System ausfuehren (NICHT auf dem Backup-Client!):
restic \
  -o rclone.program='ssh -p 23 -i /path/to/id_restic_admin \
    uXXXXX@uXXXXX.your-storagebox.de' \
  -r rclone: \
  forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 12 \
    --prune

Kritischer Stolperstein: Liegen beide Keys auf demselben kompromittierten System, kann Ransomware auch prune ausführen. Admin-Key physisch getrennt halten, etwa auf verschlüsseltem USB-Stick im Safe oder Hardware-Token.

Verifizieren: Nach dem Lauf zeigt restic … snapshots nur noch die Snapshots gemäß den --keep-Regeln, und die Belegung der Storage Box im Hetzner-Panel sinkt.

Troubleshooting / Typische Fehler

Abgelehnte Verbindungen oder hängende Transfers: Limit von 10 Verbindungen erreicht (siehe Schritt 6). Backup-Zeiten staffeln oder Sub-Accounts nutzen.
Forced-Command greift nicht: authorized_keys-Format falsch (siehe Schritt 2). Test: ssh -p 23 -i ~/.ssh/id_restic_hetzner uXXXXX@uXXXXX.your-storagebox.de; korrekt ist kein Shell-Prompt, rclone wartet stumm.
forget/prune schlägt fehl: Erwartet im append-only-Modus; rclone lehnt jedes Löschen außer bei Lock-Dateien mit HTTP 403 ab. Housekeeping mit dem Admin-Key auf separatem System.
Repository wächst unkontrolliert: Ein kompromittierter Client kann den Speicher mit neuen Backups fluten. Kontingent im Hetzner-Panel überwachen und bei unerwartetem Wachstum alarmieren.
restic check meldet keine Fehler, Restore schlägt fehl: Ohne --read-data bleiben defekte Pack-Dateien unentdeckt (siehe Schritt 8).
Repository-Passwort verloren: Ohne Passwort keine Wiederherstellung. Getrennt vom Backup-System aufbewahren (Passwortmanager, ausgedruckt im Safe).
Backup-Job meldet Exit-Code 3: Seit restic 0.19.0 endet restic backup mit 3, wenn ein Quellpfad fehlt (does not exist, skipping), früher mit 0. Der Dienst gilt dann als fehlgeschlagen, ExecStartPost läuft nicht. Nicht mehr vorhandene Verzeichnisse aus ExecStart entfernen.
Doppelte Kompression verlangsamt Transfer: Compression yes in ~/.ssh/config durch Compression no ersetzen (siehe Schritt 5).

Häufige Fragen

Warum reicht 3-2-1 gegen moderne Ransomware nicht mehr aus?

Weil Ransomware in 96 % der Fälle zuerst Backups angreift (siehe Einleitung), Backup-Prozesse beendet, Volume Shadow Copies löscht und ihr Binary danach entfernt. Die immutable Kopie bleibt auch bei kompromittiertem Backup-Client erhalten.

Kann restic nach dem Aktivieren von append-only noch alte Snapshots löschen?

Nein, nicht über den append-only-Key: rclone lehnt dann alle DELETE-Anfragen außer für Lock-Dateien ab. Housekeeping nur mit dem separaten Admin-Key (Schritt 9).

Was ist der Unterschied zwischen restic check und restic check --read-data?

restic check prüft schnell Index und Metadaten. --read-data lädt alle Pack-Dateien und verifiziert die Checksummen: langsam und traffic-intensiv, aber der einzige Weg, Storage-Korruption zu finden. Für große Repositories: --read-data-subset=10% wöchentlich.

Kann ich mehrere Server auf dieselbe Hetzner Storage Box sichern?

Ja, mit je einem Sub-Account pro Server (bis zu 100 je Storage Box, siehe Schritt 3), also bis zu 100 unabhängige append-only-Repositories.

Wie lange sind historische Snapshots sicher, wenn der Backup-Client kompromittiert wird?

Mit dem append-only-Key allein löscht er keine Snapshots, er schreibt nur neue (ggf. verschlüsselte) Backups. Die alten Snapshots bleiben von einem unabhängigen System aus wiederherstellbar, sofern das Repository-Passwort nicht kompromittiert ist; deshalb getrennt aufbewahren.

Ist WebDAV oder SFTP als rclone-Backend schneller?

WebDAV ist bei snapshots und diff deutlich schneller als SFTP, erlaubt aber kein append-only per Forced-Command. Für den immutable Offsite-Tier also SFTP mit Forced-Command; WebDAV höchstens als zweiter, schreibgeschützter Zugang für unkritische Lesezugriffe.

Fazit

Das append-only-Repository nimmt Ransomware mit überschaubarem Aufwand den Zugriff auf die Backups. Entscheidend ist der Betrieb: Admin-Key offline, regelmäßig check --read-data, echte Probe-Restores auf getrenntem System. Scheduling und Profile: restic unter Linux und Windows automatisieren.

Weiterführende Anleitungen und Quellen

Quellen: Append-only Restic backups on a Hetzner Storage Box (fluix.one) · Append-only backups with restic and rclone (ruderich.org) · rclone serve restic Dokumentation · restic: Preparing a new repository · Hetzner Storage Box SSH/rsync/BorgBackup Access · What is the 3-2-1-1-0 backup rule? (datto.com) · restic 0.18.0 Release Announcement · restic 0.19.1 Release Announcement · Restic Encrypted Offsite Backup with Ransomware Protection (helgeklein.com)