Backup & Disaster Recovery in der Cloud: Was der Mittelstand wirklich braucht

Freitagnachmittag, kurz vor Feierabend: Auf den Bildschirmen erscheint eine Lösegeldforderung, sämtliche Dateien sind verschlüsselt. Der IT-Verantwortliche greift zum Backup - und stellt fest, dass die externe Festplatte seit drei Wochen nicht mehr angeschlossen wurde, weil der zuständige Kollege im Urlaub war. Solche Momente entscheiden darüber, ob ein Cyberangriff eine unangenehme Fußnote bleibt oder den Betrieb für Wochen lahmlegt.

Backup und Disaster Recovery klingen nach IT-Kleingedrucktem. Tatsächlich sind es Geschäftsentscheidungen mit einem klaren Preisschild: Wie viel Ausfallzeit verkraftet Ihr Unternehmen, wie viel Datenverlust ist akzeptabel, und was ist Ihnen eine belastbare Antwort auf diese beiden Fragen wert? Der folgende Leitfaden ordnet die wichtigsten Begriffe, aktualisiert die klassische 3-2-1-Regel für die Cloud-Ära und liefert eine Checkliste, mit der Sie prüfen, ob Ihre Backups im Ernstfall tatsächlich funktionieren.

RTO und RPO: die zwei Zahlen, um die sich alles dreht

Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sind die wichtigsten Kennzahlen der Notfallplanung - und trotzdem können die wenigsten Geschäftsführer sie für ihre eigenen Systeme benennen.

Der RTO beantwortet eine Frage: Wie lange darf ein System ausfallen, bevor der Schaden nicht mehr vertretbar ist? Bei einem Warenwirtschaftssystem, über das Bestellungen und Auslieferungen laufen, liegt eine vertretbare Grenze häufig bei zwei bis vier Stunden. Bei einem internen Archiv für Reportings können auch drei Tage akzeptabel sein.

Der RPO beantwortet eine andere Frage: Wie viele Daten dürfen im Ernstfall verloren gehen, gemessen in Zeit seit der letzten Sicherung? Läuft die Sicherung einmal pro Nacht, liegt der RPO bei bis zu 24 Stunden - im schlimmsten Fall geht also ein ganzer Arbeitstag an Bestellungen, Rechnungen und Kundendaten verloren.

Beispielhafte Werte nach Systemtyp

System	Typischer RTO	Typischer RPO	Kritikalität
ERP / Warenwirtschaft	2-4 Stunden	15 Minuten	Umsatzkritisch
E-Mail / Kommunikation	4-8 Stunden	1 Stunde	Wichtig, Workaround möglich
Fileserver / Dokumente	24 Stunden	24 Stunden	Unangenehm, selten akut
Archiv / Reporting	3-5 Tage	7 Tage	Kein akuter Handlungsdruck

Warum diese Werte aus dem Fachbereich kommen sollten

Ein häufiger Fehler: Die IT-Abteilung legt RTO und RPO im Alleingang fest, ohne die Fachbereiche zu fragen. Das Ergebnis sind entweder überzogene Anforderungen, die unnötig teuer werden, oder zu lasche Werte, die erst im Ernstfall auffallen. Setzen Sie sich stattdessen mit Vertrieb, Produktion und Buchhaltung zusammen und fragen Sie konkret: Was passiert, wenn dieses System vier Stunden ausfällt? Was, wenn es 24 Stunden sind? Aus diesen Antworten ergeben sich belastbare Zielwerte - und ein Budget, das sich gegenüber der Geschäftsführung rechtfertigen lässt.

Die 3-2-1-Regel, aktualisiert für die Cloud

Die klassische 3-2-1-Regel ist über fünfzehn Jahre alt und trotzdem noch der richtige Ausgangspunkt: drei Kopien der Daten, auf zwei unterschiedlichen Speichermedien, davon eine Kopie extern gelagert. Für sich allein reicht das in der Cloud-Ära aber nicht mehr, denn moderne Ransomware zielt gezielt auf Backup-Systeme, bevor die eigentliche Verschlüsselung überhaupt startet.

Deshalb hat sich die Regel um zwei Punkte erweitert, meist als 3-2-1-1-0 bezeichnet: Eine der Kopien muss unveränderlich oder physisch getrennt (air-gapped) sein, und jede Kopie muss mit null offenen Fehlern verifizierbar wiederherstellbar sein. Für ein mittelständisches Unternehmen sieht das in der Praxis so aus:

• Produktionsdaten liegen auf dem primären System.
• Eine erste Kopie liegt auf einem separaten Speicherziel im eigenen Netz oder Rechenzentrum.
• Eine zweite Kopie liegt in einer Cloud-Region, idealerweise bei einem anderen Anbieter oder zumindest unter einem eigenen, getrennten Konto.
• Mindestens eine dieser Kopien ist unveränderlich gespeichert - dazu gleich mehr.

Der Punkt mit dem getrennten Konto wird oft übersehen: Verwaltet derselbe Administrator-Zugang sowohl die Produktionsumgebung als auch das Backup-System, reicht ein einziger kompromittierter Zugang, um beide Ebenen gleichzeitig zu zerstören. Trennen Sie Backup-Zugriffe technisch und organisatorisch von der übrigen IT-Administration - eigene Anmeldedaten, eigenes Rechtemodell, im Idealfall eigene Multi-Faktor-Authentifizierung.

Immutable Backups: der wirksamste Hebel gegen Ransomware

Unveränderliche Backups, häufig “Immutable Backups” oder WORM-Speicher (Write Once, Read Many) genannt, lassen sich für einen festgelegten Zeitraum weder löschen noch überschreiben oder verschlüsseln - auch nicht durch einen Administrator mit vollen Rechten. Technisch setzen die großen Cloud-Anbieter das über Objekt-Sperren um: AWS S3 Object Lock, Azure Immutable Blob Storage oder vergleichbare Funktionen bei kleineren Anbietern wie Wasabi oder Backblaze.

Der Grund, warum das inzwischen zur Pflichtübung gehört, ist einfach: Angreifer, die sich Zugang zu einem Netzwerk verschafft haben, suchen gezielt nach Backup-Repositories und versuchen, diese vor der eigentlichen Verschlüsselung zu löschen oder zu manipulieren. Ist das Backup weg, steigt der Druck, das Lösegeld zu zahlen, erheblich.

Für die Sperrfrist gilt eine einfache Faustregel: Sie sollte länger sein als die Zeit, die ein Angreifer im Schnitt unentdeckt im Netzwerk verbringt, bevor er zuschlägt - üblicherweise mehrere Wochen. Viele Unternehmen setzen deshalb auf mindestens 14 bis 30 Tage Unveränderlichkeit für laufende Backups und auf 90 Tage oder mehr für geschäftskritische Systeme.

Praktisch bedeutet das: Prüfen Sie bei Ihrer aktuellen Backup-Software, ob Immutability tatsächlich aktiv konfiguriert ist - nicht nur als Funktion verfügbar. Veeam, Acronis, Cohesity und die meisten etablierten Lösungen unterstützen das mittlerweile standardmäßig. Die Lücke zwischen vorhandener Funktion und aktivierter Funktion gehört bei Audits zu den häufigsten Befunden.

Warum ein ungetesteter Restore wertlos ist

Backup-Software meldet fast immer “Job erfolgreich”. Was sie nicht meldet: ob sich aus dieser Sicherung tatsächlich ein funktionierendes System wiederherstellen lässt. Beschädigte Datenbankdateien, fehlende Abhängigkeiten oder eine falsche Wiederherstellungsreihenfolge fallen oft erst auf, wenn es zu spät ist - mitten im Ernstfall, unter Zeitdruck, mit der Geschäftsführung am Telefon.

Ein Restore läuft in mehreren Schritten ab, und die Reihenfolge entscheidet über Erfolg oder Misserfolg. Bei den meisten Systemlandschaften muss zuerst die Netzwerk- und Identitätsinfrastruktur - etwa Active Directory und DNS - laufen, bevor sich Datenbanken zurückspielen lassen, und erst danach folgen die eigentlichen Anwendungen. Wird diese Reihenfolge nicht vorab geprobt, kostet allein das Herausfinden der richtigen Abfolge im Ernstfall wertvolle Stunden - Stunden, die direkt gegen den vereinbarten RTO laufen.

Checkliste für den Test-Restore

• Restore in einer isolierten Testumgebung durchführen, niemals direkt in der Produktion
• Mindestens einmal pro Quartal einen vollständigen Systemrestore testen, nicht nur einzelne Dateien
• Die Zeit vom Start bis zur einsatzbereiten Anwendung stoppen und mit dem definierten RTO abgleichen
• Die Abhängigkeitsreihenfolge dokumentieren und bei jedem Test überprüfen
• Nach dem Restore die Anwendung tatsächlich öffnen und eine Kernfunktion durchspielen
• Eine Vertretung einbeziehen, die den Restore auch ohne die Hauptverantwortliche Person durchführen könnte
• Ergebnis, Dauer und aufgetretene Probleme schriftlich festhalten
• Bei Abweichungen die Ursache beheben und den Test zeitnah wiederholen
• Einmal jährlich eine größere Übung ansetzen, die einen realistischen Vorfall simuliert - inklusive Kundenkommunikation
• Testprotokolle aufbewahren - Cyber-Versicherer und Wirtschaftsprüfer fragen zunehmend danach

Wenn Sie diese Liste gerade zum ersten Mal vollständig lesen: Legen Sie den nächsten Test-Restore für die kommenden vier Wochen fest, nicht für “irgendwann dieses Jahr”.

Was Backup und Disaster Recovery wirklich kosten

Die Kosten hängen stark von Datenmenge, Anzahl der Systeme und den geforderten RTO/RPO-Werten ab. Als grobe Orientierung für 2026:

Unternehmensgröße	Typisches Setup	Monatliche Kosten
Kleinbetrieb (10-30 Mitarbeitende)	Cloud-Backup für Server und Endgeräte, tägliche Sicherung, einfache Immutability	150-500 €
Mittelstand (30-150 Mitarbeitende)	Managed-Backup-Service, mehrere Standorte, stündlicher RPO für Kernsysteme, jährlich begleiteter DR-Test	800-3.000 €
Größerer Mittelstand (150-500 Mitarbeitende)	Georedundante Replikation, dediziertes DR-Failover, vierteljährliche Tests	3.000-12.000 €

Diese Zahlen wirken auf viele Geschäftsführer zunächst hoch. Ein Blick auf die Gegenrechnung relativiert das: Je nach Branche und Wertschöpfung liegen die Kosten eines ungeplanten Produktionsausfalls für mittelständische Betriebe grob zwischen 1.000 und 10.000 Euro pro Stunde. Zieht sich der Ausfall nach einem Ransomware-Vorfall über mehrere Tage, kommen schnell sechsstellige Beträge zusammen - ganz ohne ein tatsächlich gezahltes Lösegeld.

Eine sinnvolle Investitionsreihenfolge lautet deshalb: zuerst Immutability und getestete Restores absichern, danach in kürzere RTO-Werte oder zusätzliche Standorte investieren. Der erste Schritt kostet vergleichsweise wenig und schließt gleichzeitig das größte Risiko.

Fazit: Drei Fragen, die über den Ernstfall entscheiden

Ein tragfähiges Backup-Konzept beginnt nicht bei der Software, sondern bei drei Fragen: Wie lange darf ein System ausfallen? Wie viel Datenverlust ist akzeptabel? Und wann wurde zuletzt tatsächlich wiederhergestellt, statt nur gesichert? Wer diese drei Fragen ehrlich beantworten kann, ist bereits weiter als die meisten mittelständischen Unternehmen, die uns in Audits begegnen.

Wir unterstützen Mittelständler dabei, Backup- und Disaster-Recovery-Konzepte aufzusetzen, die zur tatsächlichen Risikolage passen - inklusive Immutable-Storage-Einrichtung und begleiteten Restore-Tests im Rahmen unserer Betriebsleistungen. Wenn Sie unsicher sind, ob Ihr aktuelles Setup im Ernstfall tatsächlich hält, lässt sich das in einem kurzen Gespräch schnell einordnen.