Klassische 3-2-1-Backups reichen gegen moderne Ransomware nicht mehr aus: Laut Veeam/Sophos-Daten aus 2024/2025 greifen Angreifer in 96 % aller Attacken zuerst die Backup-Infrastruktur an – und in 76 % der Fälle löschen oder verschlüsseln sie die Backups, bevor die Produktivdaten angefasst werden. Die Lösung ist die 3-2-1-1-0-Regel, die das klassische Prinzip um zwei entscheidende Ziffern erweitert: eine immutable Kopie (vierte Ziffer) und null verifikationsfreie Backups (fünfte Ziffer). Diese Anleitung zeigt, wie du ein append-only-Repository auf einer Hetzner Storage Box einrichtest, das selbst ein kompromittierter Backup-Client nicht löschen kann.

Voraussetzungen

Linux-Server oder NAS als Backup-Client (restic v0.18.1, rclone installiert)
Hetzner Storage Box (BX11: 1 TB, BX21: 2 TB oder BX41: 5 TB – kein Mindestvertrag, unlimitierter Traffic)
SSH-Zugang zur Storage Box; Hetzner nutzt Port 23 (nicht 22)
Ein separates, offline gesichertes System für den Admin-Key (prune-Berechtigung)
Passwortmanager oder physisch gesichertes Medium für das restic-Repository-Passwort (AES-256, ohne Passwort keine Wiederherstellung)
Optional: zweite Hetzner Storage Box in anderem Rechenzentrum (FSN1 vs. HEL1) für echtes Air-Gap

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

Bevor du mit der Konfiguration beginnst, lohnt ein Blick auf das, was die beiden neuen Ziffern bedeuten und warum sie nötig sind:

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 ist der entscheidende Ransomware-Schutz: Selbst wenn ein Angreifer vollständigen Zugriff auf deinen Backup-Server hat, kann er mit dem append-only-SSH-Key keine bestehenden Snapshots löschen. Ransomware verliert damit ihren wichtigsten Hebel. Die fünfte Ziffer stellt sicher, dass du nicht erst im Ernstfall merkst, dass deine Backups korrupt sind – ein Problem, das ohne regelmäßige Restore-Tests erschreckend häufig auftritt.

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

Du benötigst mindestens zwei SSH-Keys: einen append-only-Key für den Backup-Client (kann nur schreiben) und einen Admin-Key für Housekeeping (forget/prune), der nicht auf dem Backup-Client gespeichert wird.

# 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!):
cat ~/.ssh/id_restic_hetzner.pub | ssh -p 23 uXXXXX@uXXXXX.your-storagebox.de \
  'cat >> ~/.ssh/authorized_keys'

# 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 Standard-OpenSSH-Format in authorized_keys. PuTTY-generierte Keys müssen vorher mit ssh-keygen -i -f key.pub konvertiert werden – falsch formatierte Zeilen werden still ignoriert, der Forced-Command greift dann nicht.

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

Der Forced-Command ist das Herzstück des immutable-Schutzes. Er sorgt dafür, dass jede SSH-Verbindung mit dem append-only-Key ausschließlich rclone serve restic --stdio --append-only ausführt – und nichts anderes. Bearbeite ~/.ssh/authorized_keys auf der Storage Box so, dass der Eintrag für den Backup-Key exakt so aussieht:

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

Das Schlüsselwort restrict deaktiviert Port-Forwarding, PTY-Allocation und X11-Forwarding. Der Pfad ./restic-repo ist relativ zum Home-Verzeichnis des Storage-Box-Accounts. Für den Admin-Key trägst du denselben Public Key ohne den Forced-Command ein – aber nur auf einem getrennten System, nicht auf dem Backup-Client.

Sub-Accounts nutzen: Hetzner erlaubt bis zu 100 Sub-Accounts pro Storage Box. Richte für jeden zu sichernden Server einen eigenen Sub-Account ein. Jeder Sub-Account ist in seinem Home-Verzeichnis gechrootet, hat eigene SSH-Schlüsselverwaltung und ein eigenes 10-Connection-Limit.

Schritt 4: Repository initialisieren

Das Repository muss einmalig initialisiert werden, bevor der Forced-Command aktiv ist (oder über den Admin-Key). Nach der Aktivierung von append-only kann das Repository nicht mehr neu initialisiert werden.

# 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, Forced-Command muss noch NICHT aktiv sein):
restic \
  -o rclone.program='ssh -p 23 -i /root/.ssh/id_restic_hetzner \
    -o StrictHostKeyChecking=yes uXXXXX@uXXXXX.your-storagebox.de' \
  -r rclone: \
  init

Nach der Initialisierung aktivierst du den Forced-Command in authorized_keys (Schritt 3). Ab diesem Moment ist das Repository append-only.

Schritt 5: SSH-Config einrichten

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

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: Setze Compression no explizit. restic komprimiert Repository-Daten seit v0.14 nativ; doppelte SSH-Kompression verschwendet CPU-Ressourcen und verlangsamt den Transfer spürbar.

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

Die Hetzner Storage Box erlaubt maximal 10 gleichzeitige SSH-Verbindungen pro Account. Überschreitest du das Limit, erscheinen kryptische MD5-Checksum-Fehler oder Transfers hängen. restic nutzt intern 1–2 Kontrollverbindungen zusätzlich zu den Backend-Verbindungen – setze rclone.connections daher auf maximal 8:

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

Prüfe nach dem ersten Backup die Snapshot-Liste:

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

Schritt 7: Automatisierung mit systemd-Timer

Für die 3-2-1-1-0-Regel braucht das Backup einen zuverlässigen Rhythmus. Systemd-Timer sind robuster als Cron, weil sie verpasste Ausführungen nachholen. Mehr dazu findest du in der 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

Ergänze einen separaten wöchentlichen Timer für check --read-data, da dieser alle Pack-Dateien herunterlädt und bei großen Repositories sehr lange dauert.

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

Die fünfte Ziffer der 3-2-1-1-0-Regel ist kompromisslos: kein Backup ohne Verifikation. Es gibt 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 prueft nur Metadaten und Index-Konsistenz – es erkennt keine korrumpierten Pack-Dateien durch Bitrot oder stille Storage-Fehler. Für das Ziel „0 Fehler" ist mindestens monatlich ein vollständiger Check oder eine 10-%-Stichprobe nötig.

Der echte Beweis echter Wiederherstellbarkeit ist jedoch nur der 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 aufraaeumen:
rm -rf /tmp/restic-restore-test

Automatisiere diesen Probe-Restore als Cron-Job und lass ihn das Ergebnis per Mail oder Monitoring-Alert melden. Erst wenn der Restore auf einem anderen System erfolgreich war, ist die fünfte Ziffer erfüllt. Die Backup-Restore-Testroutine beschreibt diesen Prozess ausführlicher.

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

Im append-only-Modus kann der Backup-Client zwar restic forget ausführen, aber prune hat keine Wirkung – rclone verwirft alle DELETE-Requests. Das Repository wächst unbegrenzt. Für reguläres Housekeeping benötigst du einen Admin-Key ohne Forced-Command-Restriktion, der ausschließlich offline oder auf einem separaten, gehärteten System gespeichert ist:

# 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: Wenn Admin-Key und Backup-Key auf demselben kompromittierten System liegen, kann Ransomware auch den Admin-Key missbrauchen und prune ausführen. Der Admin-Key muss physisch getrennt bleiben – zum Beispiel auf einem verschlüsselten USB-Stick im Safe oder einem Hardware-Token.

Troubleshooting / Typische Fehler

MD5-Checksum-Fehler oder hängende Transfers: Du überschreitest das 10-Connection-Limit der Storage Box. Setze -o rclone.connections=5 (maximal 8). Prüfe, ob andere Prozesse gleichzeitig auf dieselbe Storage Box zugreifen.
Forced-Command greift nicht: Das authorized_keys-Format stimmt nicht. Hetzner erwartet Standard-OpenSSH-Format. PuTTY-Keys mit ssh-keygen -i -f key.pub konvertieren. Teste mit ssh -p 23 -i ~/.ssh/id_restic_hetzner uXXXXX@uXXXXX.your-storagebox.de – bei korrektem Forced-Command erscheint sofort eine rclone-Fehlermeldung, kein Shell-Prompt.
forget/prune hat keine Wirkung: Erwartetes Verhalten im append-only-Modus. forget aktualisiert nur Metadaten, prune kann keine Pack-Dateien löschen. Für Housekeeping den Admin-Key auf einem separaten System verwenden.
Repository wächst unkontrolliert: Ein kompromittierter Client kann neue (verschlüsselte) Backups schreiben und so den Speicher fluten. Speicherkontingente im Hetzner-Panel überwachen und bei unerwartetem Wachstum alarmieren.
restic check meldet keine Fehler, Restore schlägt fehl: restic check ohne --read-data erkennt keine korrumpierten Pack-Dateien. Mindestens monatlich --read-data oder --read-data-subset=10% ausführen.
Repository-Passwort verloren: restic-Repositories sind AES-256-verschlüsselt; ohne das korrekte Passwort ist keine Wiederherstellung möglich. Passwort getrennt vom Backup-System aufbewahren (Passwortmanager, ausgedruckt im Safe).
Doppelte Kompression verlangsamt Transfer: Wenn Compression yes in ~/.ssh/config steht, verlangsamt doppelte Kompression (restic komprimiert nativ seit v0.14) den Transfer erheblich. Explizit Compression no setzen.

Häufige Fragen

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

Weil moderne Ransomware in 96 % der Fälle zuerst Backup-Systeme angreift – und in 76 % erfolgreich löscht oder verschlüsselt, bevor Produktivdaten angefasst werden. Die Angreifer terminieren Backup-Prozesse, löschen Volume Shadow Copies und entfernen ihr eigenes Binary nach der Verschlüsselung, um Forensik zu erschweren. Die vierte Ziffer (immutable) stellt sicher, dass mindestens eine Kopie auch bei vollständig kompromittiertem Backup-Client nicht löschbar ist.

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

Nein – nicht über den append-only-SSH-Key. forget aktualisiert zwar Metadaten, aber prune kann keine Pack-Dateien löschen, weil rclone alle DELETE-Requests verwirft. Für reguläres Housekeeping wird ein separater Admin-Key benötigt, der nicht auf dem Backup-Client gespeichert ist.

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

restic check prueft nur die Konsistenz von Index-Dateien und Metadaten – schnell, erkennt aber keine korrumpierten Pack-Dateien (z.B. durch Bitrot). restic check --read-data lädt alle verschlüsselten Pack-Dateien herunter und verifiziert ihre Checksummen – langsam und traffic-intensiv, aber der einzige Weg, Storage-Korruption zu erkennen. Für große Repositories empfiehlt sich --read-data-subset=10% als wöchentliche Stichprobe.

Kann ich mehrere Server auf dieselbe Hetzner Storage Box sichern?

Ja. Empfohlen wird ein eigener Sub-Account pro Server. Jeder Sub-Account ist in seinem Unterverzeichnis gechrootet, hat eigene SSH-Schlüsselverwaltung und ein eigenes 10-Connection-Limit. Hetzner erlaubt bis zu 100 Sub-Accounts pro Storage Box – damit können 100 unabhängige Server mit je eigenem append-only-Repository verwaltet werden.

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

Solange der Angreifer nur den append-only-Key hat, kann er keine bestehenden Snapshots löschen. Er kann neue (ggf. verschlüsselte) Backups schreiben. Die historischen Snapshots bleiben intakt und sind von einem unabhängigen Wiederherstellungssystem aus zugänglich – sofern das Repository-Passwort nicht kompromittiert wurde. Genau deshalb muss das Passwort getrennt vom Backup-System gesichert sein.

Ist WebDAV oder SFTP als rclone-Backend schneller?

rclone+WebDAV ist für Metadaten-Operationen (snapshots, diff) deutlich schneller als SFTP. Der Nachteil: append-only lässt sich per WebDAV nicht über einen Forced-Command erzwingen. Für den immutable Offsite-Tier sollte SFTP mit Forced-Command verwendet werden; WebDAV kann als zweiter, schreibgeschützter Zugang für Performance-unkritische Lesezugriffe konfiguriert werden.

Fazit

Die 3-2-1-1-0-Regel ist kein Marketing-Konzept, sondern eine direkte Antwort auf reale Angriffsmuster: Ransomware greift Backups an, bevor sie Produktivdaten verschlüsselt. Ein append-only-Repository auf der Hetzner Storage Box entzieht dem Angreifer genau diesen Hebel – zu einem Preis von unter vier Euro pro Monat für 1 TB. Der entscheidende Aufwand liegt nicht in der Einrichtung, sondern in der Disziplin: Admin-Key offline halten, regelmäßig check --read-data ausführen und – am wichtigsten – echte Probe-Restores auf einem getrennten System durchführen. Erst dann sind alle fünf Ziffern der Regel wirklich erfüllt. Wer seinen restic-Workflow weiter automatisieren möchte, findet in der Anleitung restic unter Linux und Windows automatisieren weitere Details zu Scheduling und Profilen.

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 Encrypted Offsite Backup with Ransomware Protection (helgeklein.com)