Backup-Strategie für KMU: Warum 3-2-1 nicht mehr genug ist

Wenn ich mit kleinen und mittelständischen Unternehmen über ihre Backup-Strategie spreche, höre ich oft denselben Satz: “Wir haben eine NAS, da wird jede Nacht gesichert.” Auf die Nachfrage, ob die Sicherung auch außer Haus liegt, folgt meist ein Schulterzucken. Auf die Frage, ob ein erfolgreicher Restore-Test in den letzten zwölf Monaten stattgefunden hat, in der Regel ein Kopfschütteln.

Das ist kein Vorwurf – das ist die Realität in vielen Betrieben. Backup ist eine dieser Aufgaben, die im Tagesgeschäft untergehen, bis es zu spät ist. Und seit Ransomware zur strukturellen Bedrohung geworden ist, reicht die altbekannte 3-2-1-Regel nicht mehr aus.

Was die 3-2-1-Regel ursprünglich bedeutete

Die 3-2-1-Regel stammt aus den 2000er Jahren und ist in ihrer Einfachheit bestechend:

3 Kopien der Daten (das Original plus zwei Sicherungen)
2 verschiedene Speichermedien
1 Kopie außer Haus

Solange die Bedrohungslage primär aus Hardwaredefekten, Diebstahl und Naturereignissen bestand, war das ein robuster Schutz. Wenn die Festplatte stirbt, gibt es das Bandlaufwerk. Wenn das Büro abbrennt, gibt es die Kopie im Schließfach.

Diese Welt existiert nicht mehr.

Warum die klassische Regel an Ransomware scheitert

Moderne Ransomware-Angriffe laufen nicht in Stunden ab, sondern in Wochen. Angreifer verschaffen sich Zugriff, bewegen sich seitlich durchs Netz, eskalieren Rechte, identifizieren das Backup-System und löschen oder verschlüsseln dort gezielt zuerst, bevor die Produktivdaten attackiert werden.

Das hat eine unbequeme Konsequenz: Ein Backup, das mit denselben Anmeldedaten erreichbar ist wie der Rest des Netzes, ist im Ernstfall mit hoher Wahrscheinlichkeit ebenfalls kompromittiert. Die NAS im Serverschrank, die jede Nacht per SMB-Share angesprochen wird? Wenn der Domain-Admin-Account fällt, fällt auch sie.

Auch die Cloud-Sicherung schützt nicht automatisch: Synchronisierte Cloud-Speicher (OneDrive, Dropbox, Google Drive) replizieren verschlüsselte Dateien zuverlässig in die Cloud – und sind damit kein Backup, sondern eine Synchronisation. Selbst echte Backup-Lösungen sind angreifbar, wenn der Angreifer Zugriff auf das Verwaltungs-Konto erhält.

Die erweiterte Regel: 3-2-1-1-0

In den letzten Jahren hat sich – nicht zuletzt durch Erfahrungen aus tatsächlichen Schadensfällen – eine Erweiterung etabliert:

3 Kopien der Daten
2 verschiedene Speichermedien
1 Kopie außer Haus
1 Kopie offline oder unveränderbar (Immutable / Air-Gapped)
0 Fehler beim regelmäßigen Restore-Test

Die beiden hinzugekommenen Punkte machen den Unterschied zwischen einer Backup-Strategie auf dem Papier und einer, die im Krisenfall trägt.

Die “1”: Immutable oder Air-Gapped

Ein Backup ist erst dann gegen Ransomware geschützt, wenn es zum Zeitpunkt des Angriffs nicht mehr veränderbar ist. Dafür gibt es drei praktikable Wege:

Echte Air-Gap-Backups – physisch getrennte Medien, die nach dem Sicherungslauf vom Netz genommen werden. Klassisch das LTO-Band, das aus dem Laufwerk entnommen und im Tresor abgelegt wird. Aufwendig, aber mit Abstand am sichersten.

Immutable Backups auf S3-kompatiblem Object Storage mit Object Lock. Hier wird beim Schreiben des Backups eine Aufbewahrungsfrist gesetzt, die selbst der Administrator nicht mehr verkürzen kann. Anbieter wie Wasabi, Backblaze B2 oder Cloudian bieten das, auch lokale MinIO-Installationen unterstützen es.

Hardened Backup Repositories wie sie etwa Veeam mit dem Linux-basierten Hardened Repository umsetzt: ein dediziertes Backup-Ziel mit eigenem, lokalen Account, ohne SSH-Root-Zugriff, mit Immutable-Flag auf Dateisystemebene.

Welche Variante sinnvoll ist, hängt vom Datenvolumen und der Wiederherstellungsfrist ab. Für viele KMU ist Immutable Object Storage die wirtschaftlichste Lösung – kein Bandwechsel, keine eigene Hardware, aber harter Schutz vor Manipulation.

Die “0”: Restore-Tests ohne Fehler

Der zweite zusätzliche Punkt ist trivial in der Theorie und schwer in der Praxis: Ein Backup, das nicht regelmäßig zurückgesichert wird, ist kein Backup, sondern eine Hoffnung.

Restore-Tests sollten mindestens vierteljährlich stattfinden, idealerweise mit einem dokumentierten Protokoll: Welcher Datenbestand wurde wiederhergestellt? Wie lange hat es gedauert? Sind die Daten konsistent? Funktioniert die Anwendung danach noch? Wer einen Restore zum ersten Mal im Schadensfall durchführt, scheitert in der Regel an Details: abgelaufene Verschlüsselungs-Keys, fehlende Treiber für alte Hardware, vergessene Anwendungs-Konfigurationen.

Was das praktisch für ein KMU bedeutet

Eine 3-2-1-1-0-Strategie für ein typisches Unternehmen mit ein bis zwei Servern und 20–50 Arbeitsplätzen kann so aussehen:

Lokales Backup auf eine NAS oder ein dediziertes Backup-System (täglich, kurze Aufbewahrung). Ziel: Schnelle Wiederherstellung einzelner Dateien.
Off-Site-Backup in ein verschlüsseltes Cloud-Ziel (täglich oder wöchentlich, mittelfristige Aufbewahrung). Ziel: Schutz vor lokalem Totalverlust.
Immutable-Backup auf S3-kompatiblem Object Storage mit Object Lock (wöchentlich, lange Aufbewahrung). Ziel: Schutz vor Ransomware und Innentätern.
Quartalsweiser Restore-Test mit Protokoll, idealerweise als Übung des gesamten Recovery-Prozesses inklusive Anwendungsstart.

Wichtig: Die drei Sicherungsziele sollten unabhängige Anmeldedaten verwenden und idealerweise von unterschiedlichen Identitäten verwaltet werden. Ein Angreifer, der die Domain übernommen hat, darf weder das lokale noch das externe noch das immutable Backup direkt erreichen können.

Häufige Fehler in der Praxis

Aus typischen Beratungssituationen ein paar Punkte, die immer wieder auffallen:

Backup auf demselben Server wie die Produktivdaten. Eine VM, die ihre Sicherung auf eine Partition auf demselben Hypervisor schreibt, ist kein Backup. Das ist eine Kopie auf dem Schiff, das gerade sinkt.

Cloud-Synchronisation als “Cloud-Backup” verkauft. OneDrive, Dropbox & Co. sichern keine Versionsstände im Sinne eines Backups – sie spiegeln den aktuellen Zustand. Wenn der lokale Datenstand verschlüsselt wird, wird auch die Cloud-Kopie überschrieben. Versionierung hilft begrenzt, ersetzt aber kein echtes Backup.

Backup-Software mit Domain-Admin-Rechten. Wenn das Backup-System mit einem AD-Konto läuft, das vollen Zugriff auf alle Server hat, dann hat ein Angreifer mit denselben Rechten auch vollen Zugriff auf das Backup. Backup-Server sollten in einer eigenen Vertrauenszone laufen.

Keine Dokumentation des Restore-Prozesses. Im Schadensfall ist die Person, die das Backup eingerichtet hat, oft nicht verfügbar – krank, im Urlaub oder das Unternehmen verlassen. Ein Recovery-Runbook gehört zur Backup-Strategie dazu.

Aufbewahrungszeiten zu kurz. Ransomware-Angriffe werden oft erst Wochen nach der Erstkompromittierung aktiv. Wer nur 14 Tage Backup-Historie hat, riskiert, dass alle verfügbaren Sicherungen bereits den verschlüsselten Zustand enthalten. Mindestens 90 Tage, idealerweise 12 Monate für mindestens einen Sicherungspunkt sind sinnvoll.

Fazit

Backup ist keine Versicherung, die man einmal abschließt und vergisst. Es ist ein Prozess, der gepflegt, getestet und an die aktuelle Bedrohungslage angepasst werden muss. Die gute Nachricht: 3-2-1-1-0 lässt sich auch in kleineren Unternehmen umsetzen, ohne das IT-Budget zu sprengen. Immutable Object Storage kostet wenige Euro pro Terabyte und Monat, ein hardened Backup-Repository auf einem dedizierten Linux-Server ist eine überschaubare Investition.

Die schlechte Nachricht: Wer es nicht tut, spielt im Schadensfall russisches Roulette. Die durchschnittlichen Wiederherstellungskosten nach einem Ransomware-Angriff bewegen sich nach aktuellen Studien im sechsstelligen Bereich – ohne Lösegeld, das ohnehin keine Garantie für eine erfolgreiche Entschlüsselung bietet.

Wenn Sie unsicher sind, ob Ihre Backup-Strategie heutigen Bedrohungen standhält, ist ein nüchterner Blick von außen in der Regel günstiger als der Schadensfall. Gerne unterstütze ich Sie bei einer Bestandsaufnahme und einem realistischen Konzept für Ihren Betrieb.

Jetzt Kontakt aufnehmen