Notfallplan für KMU: Was tun bei Server-Totalausfall?

Ein Server steht. Nicht ein Dienst, nicht eine VM — der Hypervisor selbst antwortet nicht mehr. Mitarbeiter rufen an, Telefonleitungen sind belegt, jemand hat schon die IT-Hotline alarmiert und der Geschäftsführer fragt, “wann läuft es wieder?”. In diesem Moment entscheidet sich, ob ein Unternehmen einen Notfallplan hat — oder ob es improvisiert.

Dieser Artikel ist keine Backup-Strategie und kein Disaster-Recovery-Konzept im engeren Sinne (dazu haben wir eigene Artikel). Er beantwortet eine engere Frage: Was tun in den ersten 60 Minuten und den darauf folgenden Stunden? Mit konkreten Checklisten, Rollen und einer Wiederherstellungs-Reihenfolge, die sich in der Praxis bewährt hat.

Voraussetzungen: Was muss vor dem Ernstfall existieren?

Ein Notfallplan ist wertlos, wenn er beim ersten echten Ausfall zum ersten Mal aus dem Schrank geholt wird. Diese Dinge müssen vorab existieren — und alle zwei bis drei Jahre verifiziert werden:

• Aktuelles Backup, getestet (nicht nur “läuft täglich grün”)
• RTO und RPO pro Geschäftsprozess definiert und schriftlich
• Eskalationsliste mit Erreichbarkeit ausserhalb der Bürozeiten
• Hardware-Inventar mit Seriennummern, Service-Tags, Garantielaufzeiten
• Lizenzschlüssel-Verzeichnis an einem zugriffsicheren, aber im Notfall erreichbaren Ort
• Notfall-Kommunikationsweg unabhängig vom Firmen-Mail-Server (Signal-Gruppe, externe Mail, Telefonliste)

Wenn auch nur einer dieser Punkte fehlt, ist der Notfall im Notfall noch nicht fertig vorbereitet. Die folgenden Phasen setzen voraus, dass dieses Fundament steht.

RTO und RPO klären — bevor etwas passiert

Bevor wir zum 4-Phasen-Plan kommen, muss jedes Unternehmen die zwei Kennzahlen kennen, die jede Entscheidung im Ernstfall steuern:

Kennzahl	Bedeutung	Beispiel KMU
RTO (Recovery Time Objective)	Maximal akzeptable Ausfalldauer	4 Stunden für ERP, 24 Stunden für Fileserver
RPO (Recovery Point Objective)	Maximal akzeptabler Datenverlust	1 Stunde für Datenbanken, 24 Stunden für Dokumente

Ohne diese Zahlen wird der Notfallplan zu einer “wir machen so schnell wie möglich”-Aktion — und am Ende streiten sich Geschäftsführung und IT, ob das Ergebnis akzeptabel war. Wer die Zahlen vorab definiert, kennt die Messlatte.

Phase 1: Erkennen (Minute 0 bis 15)

Der Ausfall beginnt nicht, wenn die IT ihn merkt — er beginnt, wenn ein Mitarbeiter merkt, dass etwas nicht funktioniert. Diese Lücke muss klein bleiben.

Was muss in Phase 1 passieren:

1. Bestätigung des Ausfalls über zwei unabhängige Wege: Monitoring-Alarm UND manuelles Pingen / Web-UI-Test
2. Scope-Klärung: Welche Systeme genau? Hypervisor, einzelne VM, Storage, Netzwerk? Drei Pings auf drei verschiedene IPs reichen meist
3. Erste Eintragung im Incident-Log (Zeit, Symptom, erste Beobachtung) — auf Papier oder in einem System ausserhalb der Infrastruktur
4. Erste Benachrichtigung an den IT-Verantwortlichen oder die Bereitschaft

Tools, die helfen: Ein eigenständiges Monitoring (Zabbix, Checkmk, Uptime Kuma) das von ausserhalb der Hauptinfrastruktur läuft. Wer das Monitoring auf demselben Hypervisor laufen lässt, der ausfällt, weiss vom Ausfall — gar nichts.

Was in Phase 1 NICHT passieren darf: Keine Reparatur-Versuche. Niemand soll das Storage neu starten, weil “es früher mal geholfen hat”. Erst diagnostizieren, dann handeln.

Phase 2: Eindämmen (Minute 15 bis 60)

Ein Server-Totalausfall hat zwei mögliche Ursachen-Kategorien: Hardware/Software-Defekt oder Sicherheitsvorfall (Ransomware, kompromittierte Admin-Accounts). Die Eindämmung sieht in beiden Fällen anders aus — aber wer das im Ernstfall nicht weiss, macht alles falsch.

Bei vermutetem Sicherheitsvorfall: sofort isolieren

• Betroffene Systeme physisch oder per VLAN vom Netz trennen — Switch-Port deaktivieren oder Kabel ziehen
• WLAN für den betroffenen Standort deaktivieren
• Backup-Systeme bewusst NICHT sofort hochfahren — sie könnten kompromittierte Restores ziehen
• Forensik-Sicherung in Erwägung ziehen, bevor Reparaturen starten (Polizei, Cyber-Versicherer)

Bei vermutetem Hardware-/Software-Defekt: Datenintegrität sichern

• Geräte nicht hart ausschalten, wenn vermeidbar — laufende Caches könnten verloren gehen
• Storage-Logs sammeln (smartctl, IPMI, SEL-Log)
• Bei RAID-Verbund: erst lesen, dann Entscheidung — kein Disk-Tausch ohne Reihenfolge-Klärung
• Hardware-Support eskalieren (Dell ProSupport, HPE, Wortmann TERRA Service) mit Service-Tag

Eskalationsmatrix — wer ruft wen an?

Stufe	Rolle	Beispiel
1	IT-Verantwortlich (intern)	Admin, IT-Leitung
2	IT-Dienstleister	DATAZONE oder Haus-IT
3	Hardware-Hersteller-Support	Dell, HPE, Wortmann TERRA
4	Geschäftsführung	bei drohendem RTO-Bruch
5	Cyber-Versicherer / Polizei	bei Sicherheitsvorfall
6	Kunden, Lieferanten	wenn externe Kommunikation betroffen

Diese Liste muss mit Telefonnummern und Erreichbarkeitsfenstern vor dem Ernstfall existieren. Im Ernstfall sucht niemand mehr im LinkedIn nach der Handynummer des Dienstleisters.

Phase 3: Wiederherstellen (Stunde 1 bis RTO)

Hier wird es technisch. Die meisten Notfallpläne scheitern nicht am “ob”, sondern am “in welcher Reihenfolge”. Eine fehlerhafte Reihenfolge kostet leicht doppelt so viel Zeit wie der eigentliche Restore.

Empfohlene Wiederherstellungs-Reihenfolge:

1. Infrastruktur-Dienste zuerst: DNS, DHCP, NTP — ohne diese funktioniert nichts anderes sauber
2. Active Directory / Domain Controller: Anmeldungen, Kerberos-Tickets, Gruppenrichtlinien. Bei Mehrfach-DCs zuerst den FSMO-Halter
3. Storage / Fileserver: SMB-Shares, Heimverzeichnisse — vor dem ERP nötig, weil viele Anwendungen Pfade auf Shares haben
4. Mail-Server / Mail-Routing: Damit Kommunikation nach aussen wieder funktioniert
5. ERP / Branchen-Software: Erst wenn alle Abhängigkeiten oben laufen
6. Sekundär-Dienste: Druck, Telefonie (falls VoIP), Sharepoint, interne Webdienste
7. Arbeitsplätze: Erst wenn Backbone steht — sonst rennen alle in Login-Fehler

Diese Reihenfolge gilt für die meisten Mittelstands-Setups. Im Detail kann sie sich verschieben — z.B. wenn das ERP eine eigene Datenbank-VM hat, die vor dem ERP-Server hochkommen muss.

Restore-Methode wählen:

Methode	Wann sinnvoll	RTO-typisch
Bare-Metal-Restore	Hardware verfügbar, Komplett-Image vorhanden	4-8 Stunden
VM-Restore aus Proxmox Backup Server	Hypervisor läuft, einzelne VMs defekt	30 Min - 2 Std pro VM
Replikat-Failover	Replikation auf zweite Site existiert	15-60 Min
Cloud-Failover	Cloud-DR-Site eingerichtet	1-4 Stunden
Neuaufbau + Daten-Restore	Worst Case, alles muss neu	Tage

Wer einen funktionierenden Proxmox Backup Server und TrueNAS-Replikation im Einsatz hat, kommt typischerweise mit der mittleren Spalte aus — und liegt damit deutlich unter den meisten KMU-RTOs.

Während des Restores:

• Jede 30-60 Minuten kurzes Status-Update in den definierten Kommunikationskanal
• Restore-Logs mitschreiben — was wurde von wo wann wiederhergestellt
• Vor produktiver Freigabe mindestens einen Smoke-Test pro System: Login, ein paar typische Aktionen
• Erst dann Mitarbeiter zurück auf das System

Phase 4: Lernen (24 bis 72 Stunden nach Wiederherstellung)

Diese Phase wird in KMU am häufigsten ausgelassen — und ist die wichtigste. Ohne Post-Mortem passiert der gleiche Fehler nochmal.

Post-Mortem-Termin mit allen Beteiligten:

• IT, Geschäftsführung, betroffene Fachabteilungen, ggf. externer Dienstleister
• Zeitrahmen: 1-2 Stunden, nicht länger
• Schuldfrage hat keinen Platz — es geht um Prozessverbesserung, nicht um Bestrafung
• Ergebnisse: schriftliche Action Items mit Verantwortlichen und Deadlines

Strukturierter Ablauf — was war wann?

Zeitpunkt	Was ist passiert?	Was hätte besser laufen können?
T+0 (Ausfall)	erste Erkennung über Monitoring	Konnte Mitarbeiter zuerst erkennen — Monitoring zu spät?
T+15min	Eskalation an Bereitschaft	Hat Bereitschaft schnell reagiert?
T+45min	Diagnose abgeschlossen	War Diagnose-Tooling vorhanden?
T+2h	erste Wiederherstellung beginnt	War der Restore-Weg klar?
T+RTO	letztes System läuft	RTO eingehalten? Wenn nein: warum nicht?

Typische Erkenntnisse aus echten Post-Mortems:

• Monitoring hat den Ausfall zu spät erkannt (z.B. Heartbeat war kein End-to-End-Test)
• Restore-Reihenfolge war nicht dokumentiert — Reihenfolge wurde im Kopf entschieden
• Niemand wusste, wo die Backup-Verschlüsselungs-Passphrase liegt
• Mitarbeiter hatten keine Information, wie sie währenddessen kommunizieren sollten (Mail war ja aus)
• Hardware-Ersatz lag nicht auf Lager — Lieferzeit verlängerte RTO um Tage

Jede dieser Erkenntnisse wird zur konkreten Action: Monitoring-Erweiterung, Runbook-Update, Notfall-Mail-Verteiler, Spare-Hardware-Vorhalt.

Beispiel-Checkliste: erste 60 Minuten Server-Totalausfall

Diese Checkliste gehört in jeden Server-Schrank — laminiert, mit aktuellen Nummern:

[ ] T+0:    Symptom notiert (Zeit, was funktioniert nicht)
[ ] T+5:    Monitoring-Check, manueller Ping-Check
[ ] T+10:   Scope geklaert: Hypervisor / Storage / Netz / einzelne VM
[ ] T+15:   IT-Bereitschaft informiert
[ ] T+15:   Sicherheits- oder Hardware-Vorfall? Entscheidung treffen
[ ] T+20:   bei Sicherheit: Netz-Isolation; bei Hardware: Logs sammeln
[ ] T+30:   Geschaeftsfuehrung informiert, RTO-Status besprochen
[ ] T+45:   Dienstleister / Hersteller-Support kontaktiert
[ ] T+60:   Wiederherstellungs-Plan steht, erste Schritte beginnen

Was DATAZONE für Kunden bereithält

Im Rahmen unserer DATAZONE Control Managed-Services pflegen wir für Kunden:

• Aktuelle Notfallpläne als Living Document
• Eskalationslisten mit verifizierter Erreichbarkeit
• Restore-Tests mindestens jährlich an einer Test-VM
• Backup-Validierung, nicht nur Job-Status
• 24/7-Bereitschaft mit definierter Reaktionszeit

Wir sehen in der Praxis regelmässig Notfallpläne, die formal sauber dokumentiert sind, aber im Ernstfall scheitern — weil eine Telefonnummer veraltet ist, weil der Restore noch nie unter Zeitdruck getestet wurde, oder weil niemand die Reihenfolge der Systeme im Kopf hat. Die jährliche Übung kostet wenige Stunden — und verkürzt die echte RTO im Ernstfall um Faktoren.

Fazit

Ein Server-Totalausfall ist nicht das Ende eines Unternehmens — wenn ein Notfallplan existiert, geübt wurde und im Ernstfall aus dem Schrank kommt. Die vier Phasen Erkennen, Eindämmen, Wiederherstellen, Lernen sind keine theoretische Struktur, sondern eine Reihenfolge, die unter Stress funktioniert. Die wichtigste Investition ist nicht das nächste Backup-Tool, sondern die jährliche Übung mit echtem Restore unter Zeitdruck.

Wer prüfen will, wie belastbar der eigene Notfallplan ist, kommt mit drei Fragen weit:

1. Wo liegt die aktuelle Eskalationsliste, und wann wurden die Nummern zuletzt verifiziert?
2. In welcher Reihenfolge werden Systeme wiederhergestellt — und wer entscheidet das?
3. Wann wurde zuletzt ein echter Restore auf separate Hardware getestet?

Wenn eine dieser Fragen ein “weiss ich nicht” produziert, gibt es Hausaufgaben. Wir helfen gerne dabei — bevor der Ernstfall die Hausaufgaben fordert.

Verwandte Artikel

• Disaster Recovery für KMU: Ausfallzeiten minimieren
• 3-2-1 Backup-Regel für KMU
• Immutable Backups: Ransomware-Schutz
• Proxmox Backup Server einrichten
• TrueNAS ZFS-Replikation für Offsite-DR