IT-Notfallplanung: Business Continuity und Disaster Recovery

Warum ein Notfallplan kein Luxusprojekt ist

Stell dir vor, am Montagmorgen um 6 Uhr ruft dich der Verkaufsleiter an: Der Serverraum steht unter Wasser, weil ein Heizungsrohr im Stockwerk drueber geplatzt ist. Oder: Ransomware hat in der Nacht alle Domain Controller und das Backup-Repository gleichzeitig verschluesselt. Beide Szenarien sind in Schweizer KMU keine Theorie, sondern real vorgekommene Faelle. Der Unterschied zwischen “wir sind in vier Stunden wieder online” und “wir haben drei Wochen Produktionsausfall und verlieren den groessten Kunden” ist praktisch nie die Technik allein - es ist die Frage, ob vorher ein durchdachter, getesteter Plan existiert hat.

Business Continuity Management (BCM) und Disaster Recovery (DR) werden oft synonym verwendet, sind aber unterschiedliche Ebenen: BCM ist die uebergeordnete Disziplin, die sicherstellt, dass das gesamte Unternehmen (Prozesse, Personal, Gebaeude, Kommunikation) einen Ausfall uebersteht. Disaster Recovery ist der IT-spezifische Teil davon - die technische Wiederherstellung von Systemen und Daten nach einem Grossschadensereignis. Ein DR-Plan ohne uebergeordnetes BCM ist wie ein Rettungsboot ohne Evakuierungsplan: technisch vorhanden, aber niemand weiss, wann und wie er es einsetzen soll.

Business Impact Analysis: die Basis fuer RTO und RPO

Bevor du ueberhaupt ueber Backup-Frequenzen oder Ausweichrechenzentren nachdenkst, brauchst du eine Business Impact Analysis (BIA). Sie beantwortet die Frage: Was kostet uns der Ausfall welches Systems pro Stunde, pro Tag - finanziell, rechtlich, reputativ? Ohne BIA rätst du bei RTO/RPO nur, und du wirst entweder massiv zu teuer bauen (jedes System hochverfuegbar) oder Boeses erleben, wenn ausgerechnet das ERP-System drei Tage steht.

Recovery Time Objective (RTO) und Recovery Point Objective (RPO) korrekt definieren

Zwei Kennzahlen bilden das Fundament jeder DR-Strategie:

• RTO (Recovery Time Objective): Die maximal tolerierbare Zeitspanne, bis ein System nach einem Ausfall wieder nutzbar ist. Wird von der Businessseite vorgegeben, nicht von der IT erfunden.
• RPO (Recovery Point Objective): Der maximal tolerierbare Datenverlust, gemessen in Zeit seit dem letzten gesicherten, wiederherstellbaren Stand. Ein RPO von 15 Minuten bedeutet: Im schlimmsten Fall verlierst du die letzten 15 Minuten an Transaktionen.

Ein haeufiger Denkfehler: RTO und RPO sind unabhaengige Variablen. Ein System kann ein RPO von nahe null haben (synchrone Replikation) und trotzdem ein RTO von vier Stunden (weil das Failover manuell orchestriert werden muss). Und umgekehrt: Ein System mit taeglichem Backup (RPO 24h) kann in 20 Minuten wiederhergestellt sein, wenn die Restore-Automatisierung sauber gebaut ist.

BIA-Ablauf in der Praxis

1. Prozess-Inventar erstellen: Welche Geschaeftsprozesse gibt es (Auftragsabwicklung, Produktion, Lohnbuchhaltung, Kundensupport)?
2. Kritikalitaet bewerten: Interviews mit Fachbereichsleitern - “Was passiert, wenn Prozess X 1h/4h/1 Tag/1 Woche steht?” Finanzieller Schaden, Vertragsstrafen, Reputationsschaden, gesetzliche Pflichten (z.B. Lohnzahlungen).
3. Abhaengige Systeme zuordnen: Jeder Prozess braucht IT-Systeme, Netzwerk, ggf. Drittanbieter (Zahlungsdienstleister, Cloud-SaaS).
4. RTO/RPO pro System ableiten: Aus der Kritikalitaet des kritischsten abhaengigen Prozesses.
5. Tier-Modell bauen: Systeme in 3-4 Kritikalitaetsstufen gruppieren.

Aufbau eines DR-Plans, der im Ernstfall wirklich funktioniert

Ein DR-Plan, der nur als PDF auf dem File-Server liegt, den der Server gerade abgeschossen hat, ist wertlos. Die Struktur muss so gebaut sein, dass sie auch unter Stress, mit unvollstaendigem Team und ohne Zugriff auf die normale IT-Umgebung funktioniert.

Kernbestandteile eines DR-Plans

1. Ausloese-Kriterien: Wann genau wird “DR-Fall” erklaert, und wer darf das? (z.B. CIO oder dessen Stellvertretung, definiert mit Vertretungsregelung)
2. Kontaktliste / Alarmierungskette: Namen, Mobilnummern (privat, nicht Firmenhandy - das koennte tot sein), Eskalationsreihenfolge. Physisch UND digital verfuegbar (siehe Kommunikationsplan unten).
3. Rollen und Verantwortlichkeiten: Wer ist Incident Commander, wer macht technische Wiederherstellung, wer Kommunikation nach aussen, wer Dokumentation?
4. System-Inventar mit Abhaengigkeiten: Welche Systeme existieren, in welcher Reihenfolge muessen sie hochgefahren werden, welche Abhaengigkeiten bestehen (z.B. DNS vor allem anderen, AD vor Exchange/SQL).
5. Technische Wiederherstellungs-Runbooks: Schritt-fuer-Schritt-Anleitungen pro System, so detailliert, dass auch ein Kollege sie ausfuehren kann, der das System nicht taeglich betreut.
6. Ausweichstandort-Details: Adresse, Zugang, IT-Ausstattung, Zustaendigkeiten.
7. Kommunikationsplan: Interne und externe Kommunikationsvorlagen, Ansprechpartner Behoerden/Kunden/Presse.
8. Wiederanlauf-Kriterien: Wann gilt ein System als “wieder normal” und wann wird zurueck in den Regelbetrieb geschaltet?

Wiederanlauf-Reihenfolge kritischer Systeme

Die Reihenfolge ist keine Geschmacksfrage, sondern folgt technischen Abhaengigkeiten. Ein typischer Wiederanlaufpfad in einem klassischen On-Prem/Hybrid-KMU-Setup:

1. Netzwerk-Grundinfrastruktur (Firewall, Core-Switches, Internetanbindung)
2. Verzeichnisdienst & Namensaufloesung (Active Directory, DNS, DHCP)
   -> siehe auch: AD-Grundlagen, DNS-Grundlagen, DHCP-Grundlagen
3. Zeit-Synchronisation (NTP) - ohne korrekte Zeit schlaegt Kerberos fehl
4. Storage-Backend (SAN/NAS, auf dem VMs/Datenbanken liegen)
5. Virtualisierungs-Cluster (Hyper-V/VMware Hosts)
6. Datenbank-Server (SQL Server, ERP-Datenbank)
7. Anwendungsserver (ERP-App-Tier, Fileserver, ggf. Exchange)
8. Peripherie & Clients (Druckserver, Terminalserver, Arbeitsplaetze)
9. Externe Anbindungen (VPN, Kundenportale, EDI-Schnittstellen)

Diese Reihenfolge gehoert als Diagramm UND als Tabelle mit konkreten Verantwortlichen und geschaetzter Dauer pro Schritt in deinen Plan. Ohne Schritt 2 (AD/DNS) funktioniert praktisch nichts danach - das ist der haeufigste Fehler in improvisierten Wiederanlaeufen: Man startet den Datenbankserver, bevor DNS wieder aufloest, und verliert Zeit mit Fehlersuche bei Verbindungsproblemen, die eigentlich nur eine fehlende Namensaufloesung sind.

DR-Strategien: von Backup-Restore bis Cloud-Failover

Je nach Tier und Budget kommen unterschiedliche technische Ansaetze infrage. Die gaengigen Modelle, von kalt nach heiss:

Ausweichstandort: physisch oder Cloud?

Klassische physische Ausweichrechenzentren (zweiter Serverraum an anderem Standort) sind fuer die meisten Schweizer KMU heute nicht mehr wirtschaftlich - die laufenden Kosten fuer Hardware, Kuehlung, Wartung an einem zweiten Standort rechnen sich selten. Cloud-DR hat das in den letzten Jahren weitgehend abgeloest, weil du nur fuer den tatsaechlichen Bedarfsfall zahlst (Pilot-Light- oder Warm-Standby-Modelle).

Azure Site Recovery (ASR) ist der Standardweg fuer hybride Microsoft-Umgebungen: Es repliziert VMs (Hyper-V, VMware oder physische Server) kontinuierlich nach Azure und orchestriert das Failover inklusive Netzwerk-Mapping und Boot-Reihenfolge.

# Beispiel: Replizierten Failover-Test fuer eine geschuetzte VM in Azure Site Recovery ausloesen
# (setzt ein bestehendes Recovery Services Vault mit konfigurierter Replikation voraus)
Connect-AzAccount

$vault = Get-AzRecoveryServicesVault -Name "rsv-dr-prod-ch"
Set-AzRecoveryServicesAsrVaultContext -Vault $vault

$fabric      = Get-AzRecoveryServicesAsrFabric -Name "onprem-hyperv-site"
$container   = Get-AzRecoveryServicesAsrProtectionContainer -Fabric $fabric
$rpi         = Get-AzRecoveryServicesAsrReplicationProtectedItem `
                 -ProtectionContainer $container -FriendlyName "ERP-DB01"

# Testfailover in ein isoliertes Netzwerk starten - beeintraechtigt die Produktion NICHT
Start-AzRecoveryServicesAsrTestFailoverJob `
  -ReplicationProtectedItem $rpi `
  -Direction PrimaryToRecovery `
  -AzureVMNetworkId "/subscriptions/<sub-id>/resourceGroups/rg-dr/providers/Microsoft.Network/virtualNetworks/vnet-dr-test"

Alternativ bieten VMware Site Recovery Manager, Veeam Recovery Orchestrator (fuer bestehende Veeam-Backup&Replication-Umgebungen) und diverse Schweizer Hosting-Anbieter (z.B. Infomaniak, Green, Exoscale) DRaaS-Angebote mit Datenhaltung in der Schweiz - relevant, wenn Kundendaten aus regulatorischen Gruenden das Land nicht verlassen duerfen.

Entscheidungsbaum: Welches DR-Modell fuer welches System?

Ist ein Ausfall > 1 Tag geschaeftskritisch (Umsatzausfall, Vertragsstrafe, Compliance)?
├── NEIN → Backup & Restore reicht (Tier 2/3)
└── JA → Ist synchrone Datenaktualitaet zwingend (z.B. Zahlungsverkehr)?
    ├── JA → Hot Standby / Active-Active, ggf. mit
    │        Windows Failover Cluster oder SQL Always On
    │        (siehe windows-failover-cluster-grundlagen,
    │        sql-server-hochverfuegbarkeit-kmu)
    └── NEIN → Reicht ein Wiederanlauf in 1-4h?
        ├── JA → Warm Standby (Cloud-Replikation, VM steht bereit)
        └── NEIN, 4-24h reichen → Pilot Light
             (Kernkomponenten repliziert, Rest wird bei Bedarf
              aus Images/IaC neu aufgebaut)

DR-Tests und Tabletop-Uebungen

Ein DR-Plan, der nie getestet wurde, ist eine Hypothese, keine Faehigkeit. Erfahrungsgemaess scheitern 60-80% der ungetesteten Plaene beim ersten echten Ernstfall an Details: veraltete Kontaktdaten, vergessene Lizenzserver, fehlende Zugangsdaten, Abhaengigkeiten, die niemand mehr auf dem Radar hatte.

Testarten, von guenstig nach aufwendig

1. Tabletop-Uebung (Planbesprechung): Das Krisenteam setzt sich zusammen (2-3 Stunden) und arbeitet ein Szenario rein gedanklich durch - “Um 3 Uhr morgens meldet das Monitoring Totalausfall des Serverraums. Was tust du als Erstes?” Deckt Luecken in Rollen, Kommunikation und Entscheidungswegen auf, ohne Produktivsysteme anzufassen. Guenstigster und haeufigster Test, sollte mindestens jaehrlich stattfinden.
2. Walkthrough / Checklisten-Test: Einzelne Runbooks werden Schritt fuer Schritt durchgegangen und auf Aktualitaet geprueft (Passwoerter noch gueltig? IP-Adressen noch korrekt?), ohne tatsaechlichen Failover.
3. Funktionstest einzelner Komponenten: Ein einzelnes System wird tatsaechlich in eine isolierte Testumgebung wiederhergestellt (z.B. Restore einer SQL-Datenbank auf einen Testserver, Test-Failover in Azure Site Recovery wie oben gezeigt).
4. Simulationsuebung / Parallel-Test: Vollstaendiger Failover in die DR-Umgebung bei laufendem Produktivbetrieb, um die reale Wiederherstellungszeit zu messen, ohne die Produktion abzuschalten.
5. Vollstaendiger Failover-Test (Cutover): Die Produktion wird tatsaechlich auf die DR-Umgebung umgeschaltet. Hoechster Aufwand und Risiko, liefert aber die einzige wirklich belastbare Aussage ueber die reale RTO. Sollte ausserhalb der Geschaeftszeiten und mit Rollback-Plan durchgefuehrt werden.

Beispiel-Szenario fuer eine Tabletop-Uebung

Szenario: "Der Cyber-Vorfall"
Montag, 04:47 Uhr: Das SIEM meldet massenhafte Dateiverschluesselung
auf dem File-Server FS01. Der Nachtwaechter des Reinigungsdienstes
bemerkt, dass mehrere Bildschirme in der Verwaltung eine Erpresser-
botschaft anzeigen.

Fragen an das Krisenteam:
1. Wer wird als Erstes informiert, und ueber welchen Kanal
   (falls Mail/Teams down sind)?
2. Wird das Netzwerk sofort segmentiert/getrennt? Wer entscheidet das
   und wer fuehrt es technisch aus?
3. Ab wann wird die Geschaeftsleitung informiert, ab wann die
   Strafverfolgungsbehoerden (Kantonspolizei, NCSC)?
4. Sind die Backups vom Vorfall betroffen? Wie wird das geprueft,
   OHNE die potenziell kompromittierte Umgebung zu nutzen?
5. Wie kommunizieren wir mit Kunden, wenn E-Mail nicht verfuegbar ist?
6. Wann gilt der Vorfall als eingedaemmt, wann startet der Wiederanlauf?

Ein solches Szenario deckt zuverlaessig auf, ob dein Team wirklich weiss, wo die Offline-Kopie des Notfallplans liegt, und ob die Meldepflichten (in der Schweiz z.B. an das NCSC bei bestimmten Vorfaellen) tatsaechlich jemand auf dem Radar hat - siehe dazu auch NIS2 und die Schweiz.

Kommunikationsplan im Krisenfall

Technik ist nur die halbe Miete. Die meisten Reputationsschaeden bei grossen Ausfaellen entstehen nicht durch den Ausfall selbst, sondern durch schlechte oder fehlende Kommunikation waehrend der Krise.

Kommunikationskanaele im Voraus festlegen

Ein vollstaendiger Kommunikationsplan definiert fuer jede Zielgruppe: Kanal, Verantwortlichen, Frequenz und Freigabeprozess.

Governance: den Plan lebendig halten

Ein DR-Plan ist ein lebendes Dokument, kein einmaliges Projekt. Baue folgende Routinen ein:

• Jaehrliche BIA-Aktualisierung: Neue Systeme, geaenderte Geschaeftsprozesse, neue regulatorische Anforderungen einpflegen.
• Tabletop-Uebung mindestens jaehrlich, bei groesseren Firmen halbjaehrlich.
• Technischer DR-Test mindestens jaehrlich fuer Tier-0/1-Systeme.
• Plan-Review nach jeder Aenderung an kritischer Infrastruktur (neuer Server, neue Applikation, Providerwechsel).
• Nach jedem echten Incident: Lessons Learned zurueck in den Plan einarbeiten - siehe Problem Management und Root Cause Analyse.

Fuer Schweizer KMU, die eine ISO-22301-Zertifizierung anstreben oder aufgrund von Kundenanforderungen (z.B. als Zulieferer eines regulierten Unternehmens) nachweisen muessen, dass BCM etabliert ist, bildet der BSI-Standard 200-4 einen praxisnahen, kostenlosen Einstiegspfad, der mit ISO 22301 kompatibel ist und gestuft (reaktiv, Aufbau, Standard) implementiert werden kann.

Weiterlernen

• BSI-Standard 200-4: Business Continuity Management - offizieller Standard mit kostenlosen Hilfsmitteln und Vorlagen
• Microsoft Learn: Azure Site Recovery Dokumentation - Referenzarchitektur und Tutorials fuer Cloud-DR
• Microsoft Learn: Azure VM Disaster Recovery Test-Failover durchfuehren - Schritt-fuer-Schritt-Anleitung fuer risikofreie DR-Tests
• BSI: Massnahmenkatalog Notfallmanagement - praktische Checklisten fuer den IT-Ernstfall
• ISO 22301 Uebersicht (Advisera) - RTO/RPO im Kontext des internationalen BCM-Standards
• NCSC Schweiz: Meldestelle fuer Cybervorfaelle - fuer die Meldepflicht im Ernstfall relevant

Videos

YouTube