Geschäftskontinuität

Disaster Recovery für KMU:
vom Notfallplan zur Wiederherstellung

·Disaster RecoveryBusiness ContinuityBackupRPO/RTOKMU

Kurz gesagt: Disaster Recovery (DR) ist die Fähigkeit, Systeme und Prozesse nach einem schwerwiegenden Ereignis wieder in Betrieb zu bringen — einem Ausfall, einem menschlichen Fehler, einem Ransomware-Angriff. Es ist nicht dasselbe wie Backup: Kopien sind nur ein Teil. Den Unterschied macht ein Plan, gemessen an zwei Zahlen — RPO (wie viele Daten du verlieren kannst) und RTO (wie schnell du wieder läufst) — und vor allem getestet. Und Achtung: der RTO, den Sie angeben, ist nicht der, den Sie wirklich erleben. Hier, was ein KMU braucht, ohne unnötigen Fachjargon.

RPOWie viele Daten du verlierst
RTOWie schnell du wieder läufst
Unveränderbares BackupRansomware-sicher

Backup, Disaster Recovery und Hochverfügbarkeit sind nicht dasselbe

Diese drei Konzepte werden oft verwechselt, und die Verwechslung wird teuer, wenn es wirklich darauf ankommt. Das Backup ist die Kopie der Daten, mit der man sie nach einer Löschung, einem Ausfall oder einem Angriff wiederherstellen kann. Disaster Recovery ist die Gesamtheit aus Plan, Verfahren und Ressourcen, die Systeme und Prozesse nach einem schwerwiegenden Ereignis wieder in Betrieb bringt. Hochverfügbarkeit (HA) dient dagegen dazu, Ausfälle durch Redundanz zu vermeiden — eine ganz andere Sache.

Die wichtigste Unterscheidung ist diese: Hochverfügbarkeit schützt weder vor Ransomware noch vor logischer Löschung. Wird ein System verschlüsselt oder ein Datum versehentlich gelöscht, gibt die synchrone Redundanz das Problem sofort an die Kopie weiter. Deshalb bleiben Backup und Disaster Recovery auch bei redundanter Infrastruktur unverzichtbar: Sie beantworten unterschiedliche Fragen.

Die zwei Zahlen, die alles bestimmen: RPO und RTO

Ein Disaster-Recovery-Plan wird an zwei Kennzahlen gemessen. Der RPO (Recovery Point Objective) ist die maximale Datenmenge, deren Verlust du dir leisten kannst, ausgedrückt in Zeit: bei einem Backup alle 24 Stunden verlierst du im schlimmsten Fall einen Arbeitstag. Der RTO (Recovery Time Objective) ist die maximale Zeit, innerhalb derer du nach dem Vorfall wieder betriebsbereit sein musst.

Der entscheidende Punkt: RPO und RTO werden pro System festgelegt, je nach Kritikalität. Die Branchenanwendung, die die Produktion stoppt, hat einen RPO und RTO von wenigen Stunden; ein historisches Dokumentenarchiv verträgt einen Tag oder mehr. Diese beiden Zahlen sagen, wie viel man in Backup und Redundanz investiert — nicht umgekehrt. Sie festzulegen ist eine Geschäftsentscheidung vor einer technischen: Sie beziffern, was jeder Prozess in Zeit und Daten wert ist.

Der RTO auf dem Papier lügt fast immer

Es gibt eine systematische Lücke zwischen dem im Plan festgehaltenen RTO und der realen Wiederherstellungszeit. Zwei Gründe, fast nie schriftlich festgehalten, lassen ihn platzen.

Der erste ist arithmetisch. Ein RTO von 4 Stunden geht oft mit Backups von Dutzenden Terabyte und einer Leitung von wenigen Hundert Mbit/s einher: 20 TB über eine 200-Mbps-Verbindung wiederherzustellen dauert Tage, nicht Stunden— reine Physik der Übertragung. Die Zahl im Plan bleibt 4; die Stoppuhr sagt neun Tage. Es ist die Rechnung, die in der Planung niemand macht — und sie ändert alles: niedrige RTOs erfordern schnelle lokale Kopien, bereitstehende Replikate oder physisches Seeding, nicht nur ein Backup „in der Cloud“.

Der zweite ist forensisch. Bei einem Ransomware-Angriff bleiben die Angreifer Wochen im Netzwerk, bevor sie verschlüsseln. Das jüngste „saubere“ Backup enthält bereits ihre Backdoor: es wiederherzustellen heißt, auch den Angreifer wieder in Produktion zu bringen. Die eigentliche Frage lautet nicht „habe ich das Backup?“, sondern „wie weit muss ich zurück, um ein sauberes zu finden?“. Diesen Punkt zu finden erfordert Analyse, und während man sucht, entfernt sich der reale RTO von den versprochenen Stunden. Deshalb zählen eine lange Historie von Wiederherstellungspunkten und die Fähigkeit, ein Backup vor dem Vertrauen darauf zu prüfen.

Was ein DR-Plan wirklich enthält

Ein Disaster-Recovery-Plan ist kein Dokument für die Schublade: Er ermöglicht es Menschen unter Stress, koordiniert zu handeln. Die Elemente, die nicht fehlen dürfen:

  • 1Inventar und Prioritäten— welche Systeme und Prozesse kritisch sind, in welcher Reihenfolge sie wiederhergestellt werden, mit welchem RPO und RTO.
  • 2Risikoszenarien— Hardwareausfall, menschlicher Fehler, Ransomware, Standortkatastrophe: jedes erfordert eine andere Reaktion.
  • 3Rollen und Verantwortlichkeiten— wer entscheidet, wer ausführt, wer kommuniziert. Ohne klare Rollen bleibt der Plan beim ersten Zwischenfall stehen.
  • 4Operative Runbooks— die Schritt-für-Schritt-Wiederherstellungsverfahren, so geschrieben, dass auch jemand sie ausführen kann, der sie nicht verfasst hat.
  • 5Wiederherstellungsressourcen und Kommunikation— wo wiederhergestellt wird (Ausweichstandort, Rechenzentrum oder Cloud) und wie Kunden, Lieferanten und gegebenenfalls die Behörden informiert werden.
  • 6Regelmäßiger Test— das am meisten vernachlässigte und wichtigste Element: ein nie geübter Plan ist eine Hypothese, keine Garantie.

Wiederherstellung nach Ransomware: die Feuerprobe

Ransomware ist das Szenario, das einen DR-Plan wie kein anderes auf die Probe stellt, weil es genau die Kopien angreift. Die Angreifer suchen und verschlüsseln die aus dem Netzwerk erreichbaren Backups, bevor sie die Systeme treffen: Sind deine Kopien online und mit denselben Anmeldedaten wie die Infrastruktur zugänglich, sind sie keine Garantie.

Die Gegenmaßnahmen, die das Ergebnis verändern: unveränderbare Backups (für einen festgelegten Zeitraum weder änderbar noch löschbar, auch nicht durch einen Administrator), Offline- oder Air-Gapped-Kopien, von der Produktionsdomäne getrennte Anmeldedaten und eine definierte Wiederherstellungsreihenfolge (zuerst Identität und Domain Controller, dann die kritischen Systeme). Auch die operative Geschwindigkeit zählt: In der Cloud bringen Werkzeuge wie die Massenwiederherstellung (Bulk Restore) von virtuellen Maschinen Dutzende Server parallel statt einzeln zurück. Und vor allem: prüfen, dass die Backups nicht bereits kompromittiert sind. An dieser Front macht ein verwalteter Incident-Response-Dienst den Unterschied zwischen einem Ausfall von Stunden und einem von Wochen.

Disaster Recovery in der Cloud für KMU

Die Cloud ist ein hervorragender Disaster-Recovery-Enabler, ersetzt es aber nicht. Azure Backup bietet unveränderbare Kopien und Soft-Delete; Azure Site Recovery repliziert virtuelle Maschinen in eine andere Region und ermöglicht Failover; und die Daten in Microsoft 365 bleiben Ihre und müssen mit einem dedizierten Backup geschützt werden — das Modell der geteilten Verantwortung überlässt den Datenschutz Ihnen, nicht dem Anbieter.

Für ein KMU ist die sinnvolle Wahl oft ein verwaltetes Disaster Recovery: Festlegung von RPO und RTO pro Prozess, unveränderbare Backups, Replikation der Virtualisierung in europäische Rechenzentren und dokumentierte Tests. Es ist auch der unkomplizierteste Weg, die Kontinuitätsanforderungen von NIS2 und DSGVO zu erfüllen, ohne alles intern aufzubauen und zu pflegen.

AtWorkStudio arbeitet seit dem Jahr 2000 in Piacenza. Wir sind zertifiziert nach ISO/IEC 27001, 27017, 27018 und ISO 9001, ACN-qualifiziert (Agenzia per la Cybersicurezza Nazionale, die italienische nationale Cybersicherheitsbehörde) für Cloud-Dienste, Mitglieder von Clusit (italienischer Verband für Informationssicherheit) und Confindustria Piacenza im RICT-Cluster zugeordnet.

Quellen

  • NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems
  • ISO 22301 — Managementsysteme für Business Continuity
  • ENISA — Leitlinien zu Resilienz und Geschäftskontinuität
  • Microsoft Learn — Azure Backup und Azure Site Recovery (offizielle Dokumentation)

Häufige Fragen

Antworten auf die häufigsten Fragen zu Disaster Recovery, RPO/RTO und Geschäftskontinuität.

Wie lange würde Ihr Unternehmen einen Ausfall überstehen?

Wir helfen Ihnen, RPO und RTO für Ihre Prozesse zu definieren, Ihre Backups abzusichern und einen getesteten Disaster-Recovery-Plan aufzubauen — bevor er wirklich gebraucht wird. Sprechen wir darüber.