Die 3-2-1-Regel galt zwei Jahrzehnte als Goldstandard der Datensicherung. Sie ist nicht falsch – aber sie wurde für eine Welt entworfen, in der Backups vor allem Hardwaredefekte, versehentliches Löschen und Brände abfedern sollten. Gegen moderne Ransomware, die gezielt nach Backups sucht und sie mitverschlüsselt oder löscht, reicht sie nicht mehr.
Genau hier setzen die erweiterte 3-2-1-1-0-Regel und das Konzept der Immutabilität an. Dieser Beitrag erklärt beides technisch sauber, ordnet die Anforderungen von Cyberversicherern und NIS2 ein – und benennt ehrlich die Grenzen gängiger Plattformen, statt „immutable" als Allheilmittel zu verkaufen.
Warum 3-2-1 nicht mehr genügt
Die klassische Regel verlangt drei Datenkopien auf zwei verschiedenen Medientypen, davon eine an einem externen Standort. Das deckt Ausfälle ab – aber nicht den entscheidenden Angriffsvektor von heute: Ransomware-Gruppen bewegen sich oft Wochen unbemerkt im Netz, identifizieren die Backup-Infrastruktur und neutralisieren sie zuerst, bevor sie die Produktivsysteme verschlüsseln. Ist das Backup über dieselben Anmeldedaten erreichbar wie der Rest des Netzes, ist es kein Sicherheitsnetz, sondern Teil des Schadens.
Laut BSI-Lagebericht zählen kleine und mittlere Unternehmen zu den Hauptbetroffenen von Ransomware – ein großer Teil der gemeldeten Angriffe trifft KMU (Quelle: BSI-Lagebericht zur IT-Sicherheit in Deutschland). Die schmerzhafte Erkenntnis aus vielen Schadensfällen: Es gab ein Backup – es war nur nicht wiederherstellbar, weil es mitverschlüsselt war oder nie getestet wurde.
In der Praxis: Ransomware-Wiederherstellung scheitert selten an der Backup-Software, sondern an zwei Dingen: mitverschlüsselten Sicherungen und fehlenden Restore-Tests. Genau diese beiden Lücken schließen die zusätzliche „1" und die „0".
Die 3-2-1-1-0-Regel erklärt
Die 3-2-1-1-0-Regel erweitert den Klassiker um zwei entscheidende Komponenten. Sie ist kein Marketingbegriff, sondern eine knappe Merkformel für eine ransomware-resiliente Architektur.
| Ziffer | Bedeutung | Risiko ohne diese Komponente |
|---|---|---|
| 3 | Drei Datenkopien (Original + 2 Backups) | Einzelausfall führt zu Datenverlust |
| 2 | Zwei verschiedene Medientypen | Gemeinsamer Medienfehler trifft alle Kopien |
| 1 | Eine Kopie offsite / extern | Brand oder Standortverlust vernichtet alles |
| 1 | Eine Kopie unveränderbar (immutable / air-gapped) | Ransomware verschlüsselt auch die Backups |
| 0 | Null Fehler durch verifizierte Restore-Tests | Backup existiert, ist aber nicht wiederherstellbar |
Die zusätzliche „1" — Immutabilität / Air Gap
Die vierte Ziffer verlangt mindestens eine Kopie, die nach dem Schreiben nicht mehr verändert oder gelöscht werden kann – weder durch Angreifer noch durch fehlgeleitete Skripte oder den eigenen Administrator mit kompromittierten Zugangsdaten. Realisiert wird das entweder durch echte Unveränderbarkeit (WORM, Object Lock) oder durch physische bzw. logische Trennung (Air Gap).
Die „0" — null Fehler durch verifizierte Restores
Die „0" steht für null Überraschungen im Ernstfall. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung, kein Konzept. Regelmäßige, dokumentierte Wiederherstellungstests stellen sicher, dass die Sicherungen konsistent, vollständig und tatsächlich bootfähig sind – und dass die Wiederherstellungszeiten (RTO) realistisch eingeschätzt sind.
Was Immutabilität technisch bedeutet
„Immutable" ist zum Schlagwort geworden – und wird dadurch unscharf. Technisch gibt es deutliche Unterschiede in der Schutzwirkung, die im Audit- oder Schadensfall relevant werden.
WORM, S3 Object Lock und echte Unveränderbarkeit
WORM (Write Once Read Many) beschreibt Medien oder Speicherobjekte, die nach dem Schreiben für eine definierte Aufbewahrungsfrist nicht überschrieben oder gelöscht werden können. Bei Objektspeichern setzt S3 Object Lock dieses Prinzip auf API-Ebene um: Im Compliance-Modus kann selbst der Storage-Administrator ein gesperrtes Objekt vor Fristablauf nicht entfernen. Das ist die stärkste Garantie – sie wirkt auch gegen Innentäter und vollständig kompromittierte Konten.
| Mechanismus | Schutzwirkung | Schwäche / Grenze |
|---|---|---|
| WORM-Tape (LTO) | Physisch unveränderbar, offline lagerbar | Manueller Aufwand, langsamer Restore |
| S3 Object Lock (Compliance) | Stärkste Garantie, auch gegen Admin/Innentäter | Erfordert Object-Storage, Fehlkonfiguration möglich |
| Hardened Repo (append-only) | Verhindert Überschreiben/Löschen per Software | Software-/OS-Härtung nötig, schwächer als Hardware-WORM |
| Air Gap (physisch) | Offline = praktisch unangreifbar | Aufwand, Lücke nur im Sync-Fenster geschützt |
Air Gap vs. logisch getrennt
Ein echter Air Gap bedeutet, dass die Backup-Kopie physisch vom Netz getrennt ist – etwa ein Band im Tresor. Ein „logischer Air Gap" trennt nur über getrennte Anmeldedaten, separate Netzsegmente und definierte Sync-Fenster. Letzteres ist im laufenden Betrieb praktikabler, schützt aber nur außerhalb des Sync-Zeitfensters vollständig. Wer das offen kommuniziert, vermeidet ein böses Erwachen.
Grenzen in der Praxis — Beispiel Proxmox Backup Server
Wir setzen in vielen Mittelstandsumgebungen auf Proxmox und den Proxmox Backup Server (PBS) – und gerade weil wir die Plattform schätzen, benennen wir ihre Grenzen klar.
Ehrliche Einordnung: Der Proxmox Backup Server unterstützt kein S3 Object Lock. Immutabilität lässt sich über hardened, append-only Repositories sowie über Sync auf ein separates, nur per definierter Sync-Kennung erreichbares Ziel abbilden. Das ist ein guter, praxistauglicher Schutz – aber er ist technisch nicht gleichwertig mit hardware-basiertem WORM oder Object Lock. Wer behauptet, PBS biete „echtes Object-Lock-Immutable-Backup", überzeichnet.
In einer typischen Fertigungsumgebung lösen wir das so: PBS sichert die VMs, ein gehärtetes Repository verhindert das Überschreiben, und ein zeitgesteuerter Sync schiebt die Daten auf ein getrenntes Ziel, das aus dem Produktivnetz nicht frei erreichbar ist. Für maximale Garantien ergänzen wir bei Bedarf eine Object-Storage-Schicht mit echtem Object Lock oder WORM-Tape. Entscheidend ist, die jeweilige Schutzstufe ehrlich zu benennen, statt einen Mechanismus als etwas auszugeben, das er nicht ist.
Was Cyberversicherer 2026 konkret fordern
Cyberversicherer haben aus den Schadensjahren gelernt und ihre Obliegenheiten verschärft. Wer die geforderten Maßnahmen im Vertrag zusichert, sie aber nicht nachweisbar umsetzt, riskiert im Schadenfall Leistungskürzung oder -freiheit. Branchenschätzungen gehen davon aus, dass ein erheblicher Teil der Cyberschäden ganz oder teilweise abgelehnt wird (Branchenschätzung) – fast immer wegen verletzter Obliegenheiten.
| Maßnahme | Typische Forderung | Nachweis |
|---|---|---|
| Immutable / Offline-Backup | Mind. eine unveränderbare Kopie | Architekturdoku, Konfig-Screenshots |
| Restore-Test | Dokumentiert, i. d. R. ≤ 90 Tage | Testprotokoll mit Datum & Ergebnis |
| MFA | Für alle privilegierten Zugänge | Richtlinie + technische Erzwingung |
| EDR | Endpoint Detection & Response aktiv | Rollout-Nachweis, Alert-Auswertung |
| Incident-Response-Plan | Vorhanden und geübt | IR-Plan, Übungsdokumentation |
Restore-Tests und Dokumentationspflicht
Der häufigste Stolperstein ist nicht das fehlende Backup, sondern der fehlende Nachweis eines erfolgreichen Restores. Viele Policen verlangen Wiederherstellungstests mindestens alle 90 Tage – als gängige Versicherer-Obliegenheit, nicht als gesetzliche Pflicht. Entscheidend ist die belegbare Dokumentation: Wann wurde was zurückgespielt, mit welchem Ergebnis, in welcher Zeit?
Praxis: Eine Steuerkanzlei hatte saubere Backups – aber keinen dokumentierten Restore-Test. Der Cyberversicherer verlangte den Nachweis eines Tests innerhalb von 90 Tagen; ohne ihn drohte im Schadenfall eine Leistungskürzung. Der Test selbst war Routine – es fehlte schlicht das Protokoll.
MFA, EDR und IR-Plan als Junktim
Backups stehen nie isoliert. Versicherer betrachten sie im Verbund mit Multi-Faktor-Authentifizierung, EDR und einem geübten Incident-Response-Plan. Fehlt eine dieser Komponenten, hilft das beste Backup wenig – und die Police kann greifen, ohne zu leisten.
Was NIS2 zum Thema Backup verlangt
NIS2 bzw. das umsetzende BSIG schreibt im Risikomanagement ausdrücklich „Backup-Management und Wiederherstellung" sowie Krisenmanagement vor (§ 30 BSIG). Anders als manche Versicherer-Obliegenheit nennt das Gesetz dabei keine konkrete Technik – es fordert wirksame Konzepte. Immutabilität ist nicht gesetzlich vorgeschrieben, aber sie ist der praktische Weg, die geforderte Wirksamkeit gegen Ransomware tatsächlich herzustellen.
Für betroffene Unternehmen heißt das: Ein Backup-Konzept, das mitverschlüsselt werden kann, erfüllt die NIS2-Anforderung an ein „wirksames" Wiederherstellungskonzept im Ernstfall nicht. Wie NIS2 insgesamt einzuordnen ist und welche Pflichten dahinterstehen, lesen Sie in unserem Beitrag NIS2 ist in Kraft – Frist verpasst, was jetzt?.
Umsetzung im Mittelstand — eine pragmatische Architektur
Eine prüffeste 3-2-1-1-0-Architektur muss nicht teuer sein. Für 50 bis 250 Mitarbeiter hat sich folgender, bezahlbarer Aufbau bewährt:
- Kopie 1 – Produktivnähe: Schnelles lokales Backup (z. B. PBS) für kurze RTO bei Alltagsfehlern.
- Kopie 2 – anderes Medium / Standort: Sync auf ein zweites, getrenntes Ziel im externen Rechenzentrum.
- Kopie 3 – unveränderbar: Immutable-Schicht über append-only Repository oder – wo nötig – Object Lock / WORM-Tape mit definierter Aufbewahrungsfrist.
- Trennung: Eigene Anmeldedaten, eigenes Netzsegment, kein direkter Zugriff aus dem Produktivnetz.
- Verifikation: Automatisierte Integritätsprüfung plus regelmäßiger, protokollierter Restore-Test.
Genau diese Architektur planen und betreiben wir im Rahmen unserer Backup- und Disaster-Recovery-Lösung – inklusive der dokumentierten Restore-Tests, die Versicherer und Auditoren sehen wollen.
Checkliste: Ist Ihr Backup audit- und versicherungsfest?
Prüfen Sie Ihr aktuelles Setup gegen die folgenden Punkte. Können Sie nicht jeden mit einem klaren „Ja, und belegbar" beantworten, besteht Handlungsbedarf:
- Existieren mindestens drei Kopien auf zwei Medientypen, davon eine offsite?
- Gibt es mindestens eine unveränderbare oder air-gapped Kopie?
- Ist diese Kopie aus dem Produktivnetz nicht mit denselben Zugangsdaten löschbar?
- Wurde innerhalb der letzten 90 Tage ein vollständiger Restore getestet – und dokumentiert?
- Sind die Wiederherstellungszeiten (RTO) und Datenverlustfenster (RPO) belegt und realistisch?
- Greifen MFA, EDR und ein geübter Incident-Response-Plan flankierend?
- Lässt sich die Architektur dem Versicherer und einem NIS2-Auditor lückenlos vorlegen?
Fazit
3-2-1 war richtig für seine Zeit – 2026 ist es die Untergrenze, nicht der Standard. Die 3-2-1-1-0-Regel schließt mit der Immutabilität und dem verifizierten Restore genau die beiden Lücken, an denen Ransomware-Wiederherstellungen real scheitern. Cyberversicherer und NIS2 verlangen beides zunehmend explizit.
Wir empfehlen 3-2-1-1-0 als Mindeststandard und legen Wert darauf, Immutabilität ehrlich zu benennen: append-only ist nicht dasselbe wie hardware-WORM, und ein logischer Air Gap ist kein physischer. Als ISO/IEC 27001:2022 zertifizierter MSP (Zertifikat Nr. 202787) bauen wir die passende Architektur und betreiben die regelmäßigen, dokumentierten Restore-Tests – damit Ihr Backup im Ernstfall hält, was es verspricht.
Häufige Fragen
Was bedeutet die Regel 3-2-1-1-0?
Drei Kopien, zwei verschiedene Medien, eine Kopie offsite, eine unveränderbare (immutable/air-gapped) Kopie und null Fehler dank verifizierter Restore-Tests.
Ist append-only dasselbe wie immutable?
Nein. Append-only verhindert Überschreiben auf Repository-Ebene, echte Hardware-WORM oder S3 Object Lock bietet stärkere Garantien. Beide erhöhen den Schutz, sind aber technisch nicht gleichwertig.
Wie oft muss ich Restore-Tests durchführen?
Viele Cyberversicherer erwarten dokumentierte Wiederherstellungstests mindestens alle 90 Tage; entscheidend ist der nachweisbare Nachweis, nicht nur die bloße Sicherung.
Unterstützt Proxmox Backup Server immutable Backups mit S3 Object Lock?
Nein, S3 Object Lock wird nicht unterstützt. Immutabilität lässt sich über hardened/append-only Repositories und getrennte Sync-Ziele abbilden — das sollte man nicht überzeichnen.
Verlangt NIS2 immutable Backups?
NIS2 nennt keine konkrete Technik, fordert aber wirksame Backup- und Wiederherstellungskonzepte im Rahmen des Risikomanagements. Immutabilität ist der praktische Weg, diese Anforderung gegen Ransomware zu erfüllen.