29. Oktober 2026 | Lesezeit: 9 Min | Aktualisiert: 29. Oktober 2026
3-2-1-1-0: Die Backup-Regel, die Webanwendungen wirklich schützt
Warum die 3-2-1-Regel nicht mehr reicht
Lange galt die 3-2-1-Regel als Standard für Datensicherung: drei Kopien der Daten, auf zwei verschiedenen Speichermedien, eine davon an einem externen Ort. Das schützte zuverlässig vor defekter Hardware und versehentlich gelöschten Dateien.
Ransomware hebelt diese Logik aus. Angreifer gelangen zum Beispiel über Sicherheitslücken wie Log4Shell in ein System. Bevor sie zuschlagen, suchen sie gezielt nach Backups, die sie von dort aus erreichen können, und verschlüsseln sie mit. Ist euer Backup mit denselben Zugangsdaten oder vom selben System aus erreichbar, ist es im Ernstfall genauso verloren wie die Originaldaten.
Aktuelles Beispiel
Wie schnell eine solche Lücke zum Thema wird, hat sich im Oktober 2026 gezeigt.
Am 21. Oktober wurden zwei kritische Sicherheitslücken in PHP bekannt, der Technik, auf der ein Großteil der Onlineshops läuft, darunter Shopware, Magento und WooCommerce. Angreifer hätten darüber ohne Zugangsdaten Code auf dem Webserver ausführen können. Das BSI riet, die Updates sofort einzuspielen, und erste Angriffsversuche gab es noch am selben Tag. Über genau solche Lücken beginnen viele Ransomware-Angriffe. Dann macht es einen riesigen Unterschied, ob das Backup außer Reichweite liegt oder gleich mit verschlüsselt wird.
Die Antwort darauf ist die 3-2-1-1-0-Regel. Sie ergänzt die bekannte Formel um zwei Bausteine: eine Kopie, die niemand verändern kann, und die regelmäßige Prüfung, ob sich die Backups auch wirklich einspielen lassen.
Wisst ihr, auf welchem Stand euer System ist?
Die 3-2-1-1-0-Regel auf einen Blick
Jede Ziffer steht für eine Anforderung an eure Datensicherung:
Drei Kopien
Zwei verschiedene Medientypen
Ein externer Standort
Eine unveränderliche Kopie
Null Fehler beim Restore
3 Kopien, 2 Medientypen, 1 externe Kopie
Bei einer typischen Webanwendung sind die drei Kopien das laufende Produktivsystem, ein Backup direkt beim Hoster und eine externe Kopie, die vom Produktivsystem unabhängig ist.
Die zwei Medientypen sorgen dafür, dass nicht alle Kopien von derselben Technik abhängen. In der Praxis heißt das zum Beispiel: Block Storage oder SSD-Speicher beim Hoster auf der einen Seite, ein S3-kompatibler Object Storage auf der anderen. Ein Block Storage ist ein Speicherkonzept, bei dem Daten in sogenannte Blöcke aufgeteilt werden, während ein Object Storage ein Cloud-Speicher ist, der sich besonders gut für große Datenmengen und Backups eignet.
Die externe Kopie liegt in einem physisch getrennten Rechenzentrum („offsite“). Brennt ein Standort oder fällt er aus, ist sie am anderen Ort weiterhin verfügbar.
1 unveränderliche Kopie (Immutable / Air Gap)
Dieser Baustein ist die direkte Antwort auf Ransomware. Technisch wird er meist über Object Lock umgesetzt. Diese Schutzfunktion bewahrt eine Backup-Kopie für eine festgelegte Zeit davor, gelöscht oder verändert zu werden. Man kann sich das wie einen Tresor mit Zeitschloss vorstellen: Bis die Frist abläuft, kommt niemand heran, auch kein Angreifer mit erbeuteten Zugangsdaten.
In diesem Zusammenhang fällt oft der Begriff Air Gap. Wörtlich heißt es „Luftspalt“, gemeint ist eine Kopie, die vom Netzwerk getrennt ist und deshalb von einem Angriff nicht erreicht werden kann. Klassisch war das zum Beispiel ein Band, das nach der Sicherung aus dem Laufwerk genommen wird. Ein unveränderlicher Cloud-Speicher mit Object Lock erfüllt heute denselben Zweck. Fachleute sprechen dann von einem „logischen Air Gap“.
Wichtig zu wissen:
0 Fehler bei der Verifikation
Ein Backup ist nur so gut wie seine Wiederherstellung. Deshalb wird auf zwei Ebenen geprüft.
Die Integritätsprüfung kontrolliert nach jedem Backup-Lauf per Prüfsumme (Checksum), ob die gespeicherten Daten vollständig und unverändert sind.
Der Restore-Test geht einen Schritt weiter und prüft, ob sich aus dem Backup tatsächlich ein funktionierendes System bauen lässt. Mehr dazu im nächsten Abschnitt. Als Mindestmaß gilt: einmal pro Quartal.
Der meistübersehene Baustein: der Restore-Test
Viele Systeme melden „Backup erfolgreich“, sobald die Sicherung gestartet ist. Ob sie vollständig durchgelaufen ist und ob sich daraus ein funktionierendes System wiederherstellen lässt, zeigt diese Meldung nicht. Genau hier entstehen die gefährlichsten Lücken. Eine Datenbanksicherung kann monatelang unbemerkt abbrechen. Das fällt erst auf, wenn man sie braucht.
Ein Restore-Test schließt diese Lücke in drei Schritten:
Schritt 1: Daten einspielen
Schritt 2: Anwendung starten
Schritt 3: Funktion prüfen
Entscheidend ist also nicht, ob der Prozess grün war, sondern ob das Ergebnis im Ernstfall trägt. Wir empfehlen, den Restore-Test mindestens vierteljährlich durchzuführen und jedes Ergebnis zu dokumentieren. So wisst ihr auch, wie lange eine Wiederherstellung realistisch dauert.
Der Test kostet Zeit, und solange alles läuft, wirkt er überflüssig. Genau deshalb wird er so oft ausgelassen. Mit unseren Wartungs-Paketen übernehmen wir genau diese wiederkehrende Prüfung für euch.
Administrative Trennung: wie weit müsst ihr gehen?
Ein guter Hoster kann eine externe und eine unveränderliche Kopie vollständig liefern. Eine Schwachstelle bleibt trotzdem: Liegen Produktivsystem und Backups beim selben Anbieter, werden sie über dieselbe Account- und Rechteverwaltung gesteuert. Fachleute sprechen von einem „Single Point of Control“. Wird dieser Zugang kompromittiert, kann das beide Kopien gleichzeitig treffen, egal wie weit die Rechenzentren auseinanderliegen.
Die höchste Ausbaustufe der 3-2-1-1-0-Regel sieht deshalb einen zweiten Anbieter mit eigener Zugangsverwaltung vor. Ob ihr diesen Schritt braucht, ist eine bewusste Risikoentscheidung, die davon abhängt, wie kritisch eure Daten sind, welche gesetzlichen Vorgaben gelten und welcher Schaden bei einem Totalverlust entstünde.
RTO und RPO: die zwei Zahlen, die zählen
Für die geschäftliche Entscheidung braucht ihr keine Technikdetails, sondern zwei Kennzahlen.
RPO (Recovery Point Objective) beschreibt, wie viel Datenverlust ihr maximal hinnehmen könnt, gemessen in Zeit. Wird einmal pro Nacht gesichert, können im schlimmsten Fall die Bestellungen, Vorgänge oder Dokumente eines ganzen Tages fehlen.
RTO (Recovery Time Objective) beschreibt, wie lange eure Anwendung höchstens ausfallen darf. Ein Shop, der zwei Stunden offline ist, verliert Umsatz. Einer, der drei Tage steht, verliert Kunden und Vertrauen.
Beide Werte bestimmen, wie oft gesichert und wie oft die Wiederherstellung geübt werden muss. Eine Backup-Strategie ohne definierte RTO- und RPO-Werte ist keine Strategie, sondern bloße Hoffnung.
Ihr wisst nicht, welchen RTO oder RPO eure Anwendung braucht? Wir helfen euch im kostenfreien Sicherheits-Check, die richtigen Werte festzulegen.
Die größten Irrtümer zur Backup-Strategie
„Unser Hoster macht Backups.“
„Wir haben einen anderen Server im selben Rechenzentrum.“
„Wir hatten noch nie einen Restore nötig.“
„Externer Object Storage ist teuer.“
„Unsere Cyberversicherung verlangt das nicht.“
„NIS2 betrifft uns nicht.“
Checkliste: So setzt ihr die 3-2-1-1-0-Regel um
Automatische Datenbank-Dumps
(Sicherungskopien der Datenbank) in einem Intervall, das zu eurem RPO passt
Backup des Dateisystems
mit Deduplizierung und Verschlüsselung
Übertragung auf Object Storage
mit aktiviertem Object Lock
Integritätsprüfung per Checksum
nach jedem Backup-Lauf
Regelmäßiger Restore-Test
dokumentiert und in einer isolierten Umgebung
Bewusste Entscheidung,
wie weit nicht nur die technische, sondern auch die administrative Trennung gehen soll
Häufige Fragen zur 3-2-1-1-0-Regel
Was bedeutet die 3-2-1-1-0-Regel einfach erklärt?
Ihr haltet drei Kopien eurer Daten auf zwei verschiedenen Speicherarten vor, eine davon an einem externen Ort. Zusätzlich ist eine Kopie unveränderlich, und alle Backups werden regelmäßig fehlerfrei auf ihre Wiederherstellung geprüft. Die Übersicht oben fasst alle fünf Bausteine zusammen.
Wie oft sollte ein Restore-Test durchgeführt werden?
Mindestens einmal pro Quartal, bei geschäftskritischen Systemen häufiger. Wichtig ist, jeden Test zu dokumentieren, da sich dadurch nachweisen lässt, dass die Wiederherstellung funktioniert und wie lange sie dauert.
Ist die 3-2-1-1-0-Regel durch NIS2 vorgeschrieben?
NIS2 schreibt die Regel nicht wörtlich vor. Die Richtlinie verlangt aber Maßnahmen zur Aufrechterhaltung des Betriebs, ausdrücklich auch Backup-Management und Wiederherstellung nach einem Notfall. Eine 3-2-1-1-0-Strategie deckt diese Anforderungen faktisch ab. Ob euer Unternehmen betroffen ist, solltet ihr individuell prüfen lassen.
Was kostet eine 3-2-1-1-0-konforme Backup-Strategie?
Eine Pauschale gibt es nicht, aber sie ist deutlich günstiger als ein Datenverlust oder ein längerer Ausfall. Die Kosten hängen vor allem vom Datenvolumen, der gewünschten Aufbewahrungsdauer und dem Einsatz von Deduplizierung und Kompression ab. Eine verlässliche Zahl ergibt sich erst aus einer individuellen Einschätzung eures Systems.
Eine gute Backup-Strategie ist keine reine Technikfrage. Lasst sie uns gemeinsam prüfen.
Wie viel Datenverlust und wie viel Ausfallzeit könnt ihr euch leisten, und wie stellt ihr sicher, dass die Wiederherstellung im Ernstfall funktioniert?
Genau das schauen wir uns im kostenfreien Sicherheits-Check gemeinsam mit euch an: eure Backups, euren Update-Stand und euer Hosting. Danach wisst ihr, wo ihr steht und was wirklich zu tun ist. Sachlich, unverbindlich und vertraulich.
Die Terminbuchung ist ausgeblendet, weil externe Inhalte (Meetergo) laut Ihren Cookie-Einstellungen nicht geladen werden.
Kalender wird nicht angezeigt? Termin direkt bei meetergo buchen →
