IT-Notfallnummer: was tun, wenn der Server um 3 Uhr nachts stirbt

Es ist 3:07 Uhr. Das Monitoring hat einen Ausfall gemeldet, der Bereitschaftskollege ist aus dem Bett, das VPN steht — aber der Hypervisor antwortet nicht. Der erste Reflex ist immer der gleiche: irgendetwas tun. Neu starten, Kabel prüfen, Backup einspielen. Genau in diesen ersten 30 Minuten wird der Ausfall entweder eingegrenzt und beherrscht — oder er wird schlimmer.

Dieser Artikel ist bewusst keine Marketingseite für unsere Rufbereitschaft. Er ist ein Ratgeber für alle, die im Ernstfall am Telefon sind: eigene IT, externer Dienstleister, Geschäftsführer, der die Nachricht bekommt. Er beschreibt, was in der ersten halben Stunde ohne Panik passieren sollte, wie man Backup-Reports von Backup-Realität unterscheidet, warum ein DR-Runbook mehr wert ist als jede Zertifizierung — und ab welchem Punkt der Anruf bei einer IT Notfall Hotline die günstigere Entscheidung ist als weiter selbst zu schrauben.

Warum die IT Notfall Hotline mehr ist als eine Telefonnummer

Eine echte IT Notfall Hotline ist keine 0800-Nummer, die um 3 Uhr eine Bandansage abspielt. Sie ist die Verabredung: Innerhalb von X Minuten meldet sich jemand, der Ihr System kennt. Der Unterschied liegt nicht in der Nummer, sondern in dem, was hinter ihr steht:

• Ein Team, das den Kunden vorher schon einmal in ruhigen Wasser dokumentiert hat
• Zugang zu Firewall, Hypervisor, Storage und Backup ohne “erst einmal das Passwort suchen”
• Ein hinterlegter Eskalationspfad zu Hersteller-Support — Proxmox, TrueNAS, OPNsense, Dell/HPE/Wortmann
• Klare Erwartungen zu Reaktionszeit und Wiederherstellungspfad

Wer erst im Ernstfall den ersten Anruf bei einem Dienstleister macht, kauft in dem Moment zwei Dinge gleichzeitig: Erkundung und Reparatur. Die Erkundung — was steht überhaupt beim Kunden, wo liegt was, welche Passwörter gelten? — kostet die entscheidenden Stunden. Deshalb ist eine IT Notfall Hotline immer ein Managed-Service-Baustein, nie ein spontanes Feuerwehrgeschäft.

Die ersten 30 Minuten: Bestandsaufnahme statt Panik

Der teuerste Fehler im Nachtdienst ist der Reboot, den niemand vorher aufgeschrieben hat. Ein Hypervisor mit korruptem ZFS-Pool wird durch drei blinde Reboots nicht besser — er wird möglicherweise nicht mehr importierbar. Deshalb steht am Anfang immer eine strukturierte Bestandsaufnahme.

Symptome trennen von Diagnose

Die erste Frage im Runbook ist nicht “was ist kaputt?”, sondern “was funktioniert noch?”. Das dreht die Perspektive:

• Ping auf Gateway: erreichbar?
• DNS-Auflösung intern und extern?
• Hypervisor-Web-UI erreichbar oder nur einzelne VMs betroffen?
• Storage-LUN sichtbar am Hypervisor?
• Physischer Server: Betriebs-LED, IPMI/iDRAC/iLO erreichbar?

Diese fünf Fragen dauern zusammen unter fünf Minuten, wenn die Zugänge stehen. Sie ersetzen keine Diagnose, aber sie schließen die Hälfte der möglichen Ursachen aus.

Was in den ersten 30 Minuten NICHT passieren sollte

Klare Verbote für den Nachdienst:

• Kein Reboot des Storage-Systems ohne dokumentierten Grund
• Kein Restore aus Backup, solange das Original nicht sauber isoliert ist
• Kein Password-Reset an Firewall oder Domaincontroller
• Keine Änderung an Firewall-Regeln “damit man wieder rankommt”

Jede dieser Aktionen kann aus einem 4-Stunden-Vorfall einen 2-Tage-Vorfall machen. Wer im Nachtdienst allein ist und unsicher wird, hat genau eine richtige Handlung: Hotline anrufen und dokumentieren, was bisher passiert ist.

Backup-Realität prüfen: läuft es wirklich?

Der schlimmste Moment im Nachtdienst ist nicht der Ausfall, sondern die Entdeckung, dass das Backup seit drei Wochen nicht mehr läuft und niemand es gemerkt hat, weil die Reports im Spam-Ordner gelandet sind. Deshalb gehört zur nächtlichen Bestandsaufnahme immer auch die Backup-Realität.

Backup-Realität ist nicht der grüne Haken im Dashboard. Sie besteht aus drei Fragen:

1. Ist der letzte erfolgreiche Backup-Job jünger als das RPO des Systems?
2. Ist der Backup-Speicher erreichbar und lesbar — auch, wenn das Original weg ist?
3. Wurde in den letzten 90 Tagen ein Restore-Test durchgeführt, der wirklich Daten wiederhergestellt hat?

Wer alle drei Fragen im Ernstfall mit “ja” beantworten kann, ist auf der ruhigen Seite. Wer bei Frage 2 ins Stocken kommt — typisch: Backup liegt auf demselben ESXi-Cluster, der gerade steht — hat gerade das erste harte Problem entdeckt.

Wir haben zu diesem Themenkomplex zwei ausführliche Artikel verfasst, die ins Runbook gehören:

• 3-2-1-1-0-Backup-Formel: die nächste Stufe der klassischen Regel
• Backup-Test-Tag: Restore in 30 Minuten

Wer diese beiden Ratgeber in Ruhe umgesetzt hat, ist im Ernstfall nicht mehr auf die Hoffnung angewiesen, dass “das Backup schon gehen wird”.

DR-Runbook: der Plan im Kopf des Nachtdienstes

Das Runbook ist das Herzstück jedes Notfalls. Es ist kein 80-Seiten-Konzept — es ist eine Handvoll klar strukturierter Seiten pro System, das der Kunde hat. Ein tragfähiges DR-Runbook beantwortet für jeden Kernservice sechs Fragen:

1. Was ist es? Ein Satz zur Funktion.
2. Wovon hängt es ab? Netz, DNS, AD, Storage, VPN.
3. Wie erkennt man Ausfall? Konkreter Test, den auch der Nachtdienst um 3 Uhr durchführen kann.
4. Wie stellt man wieder her? Nummerierte Schritte, keine Prosa.
5. Was ist die Eskalation? Wann rufe ich wen an?
6. Wie testet man den Erfolg? Objektiver Nachweis, dass das System wieder läuft.

Ein gut gepflegtes Runbook ist wertvoller als jeder Support-Vertrag, weil es den Ausfall in einen abarbeitbaren Prozess zerlegt. Es ersetzt keinen Menschen — aber es macht den Menschen um 3 Uhr nachts um Faktor drei schneller.

Für die große Linie — also die Frage, wie ein KMU Ausfallzeiten strukturell reduziert — lohnt sich zusätzlich der Blick in unseren Disaster-Recovery-Ratgeber für KMU und in den 4-Phasen-Notfallplan bei Server-Totalausfall.

Wann externen Server-Ausfall-24-Stunden-Support ziehen

Die schwierigste Entscheidung im Nachtdienst ist nicht “was tue ich?”, sondern “wann rufe ich Hilfe?”. Zu früh anrufen fühlt sich unprofessionell an. Zu spät anrufen kostet mehr, als wenn man von Anfang an angerufen hätte.

Es gibt drei sehr klare Signale, an denen der Anruf bei einer Server Ausfall 24 Stunden Support-Hotline die günstigste Handlung ist:

Signal 1: Sie haben die Ursache in 30 Minuten nicht eingegrenzt. Ein Vorfall, dessen Ursache nach 30 Minuten strukturierter Diagnose noch nicht mindestens grob bekannt ist — Storage? Netz? Hypervisor? Anwendung? — wird ohne zusätzliche Augen selten schneller. Zwei Techniker mit unterschiedlichem Blick finden systematisch mehr als einer, der immer müde wird.

Signal 2: Die nächste Handlung ist irreversibel. Restore überschreibt Daten. Firmware-Update kann das Storage endgültig blocken. Cluster-Neuformierung setzt Konfiguration zurück. Vor jeder irreversiblen Handlung ist ein zweites Paar Augen keine Schwäche, sondern Best Practice.

Signal 3: Der Fehler ist nicht in Ihrer Schicht. Wenn das Problem klar am Storage-Controller, an einer ZFS-Anomalie, an einem Ceph-PG-Zustand oder an einem OPNsense-HA-Split-Brain liegt — und Sie das System zwar bedienen, aber nicht bauen können — dann kauft der Anruf beim Spezialisten den entscheidenden Vorsprung. Zu diesem Punkt lohnt sich zum Nachlesen unser Artikel Storage-Cluster-Rescue: 70.000 Stunden Firmware, der zeigt, wie ein spezialisiertes Team einen Fall löst, den der Standard-Support in der Nacht nicht löst.

Was eine gute IT Notfall Hotline im Betrieb liefert

Konkret: Was leisten wir bei DATAZONE im Rahmen unseres IT-Service im Notfall? Wir sind kein anonymes Callcenter, sondern ein bayerisches Systemhaus mit klarem Fokus auf Proxmox, TrueNAS, OPNsense und Linux — und in genau diesen Umgebungen ist unser Rufbereitschaftsdienst wirksam. Konkret:

• Vorbereitete Kunden. Wir dokumentieren im ruhigen Wasser — Systeminventar, Zugänge, Passworttresor, Runbook. Wer bei uns Managed-Service-Kunde ist, telefoniert im Ernstfall nicht mit einem Fremden.
• Definierte Erreichbarkeit. Reaktionszeiten sind vertraglich geregelt, nicht “wir versuchen es”.
• Der ganze Werkzeugkasten. Wir haben Zugriff auf Hersteller-Support, auf unsere eigenen Ersatzteillager und auf Wortmann als starken Distributor — mit Ersatzhardware in überschaubaren Fristen.
• Dokumentierter Abschluss. Jeder Vorfall endet mit einem Bericht: was ist passiert, was wurde getan, was empfehlen wir strukturell.

Kein Notfalldienst ersetzt eine sauber gebaute Infrastruktur. Aber ein guter Notfalldienst verhindert, dass die weniger sauber gebaute Infrastruktur zum Existenzrisiko wird. Wer heute daran denkt, dass die eigene IT einen belastbaren Draht braucht: Kontakt aufnehmen — am besten, bevor der erste Anruf um 3 Uhr fällig wird.

Praxis: drei typische nächtliche Ausfälle

Um das Ganze konkret zu machen — drei Vorfälle, wie sie in unserer Rufbereitschaft realistisch vorkommen:

Fall 1: ZFS-Pool degraded, VM-Performance im Keller. Ein Proxmox-Node meldet nachts einen degraded Pool. Eine NVMe hat Timeouts, aber der Pool läuft weiter — langsam. Falsche Reaktion: sofort tauschen und resilvern. Richtige Reaktion: SMART lesen, Pool-Status prüfen, Backup-Zustand verifizieren, dann geplant im Wartungsfenster tauschen. Kein Nacht-Fire-Drill nötig, wenn die Bestandsaufnahme sauber ist.

Fall 2: OPNsense-HA-Split-Brain nach Stromausfall. Zwei OPNsense-Knoten übernehmen beide die virtuelle IP, Netzwerk instabil. Falsche Reaktion: einen der beiden hart abschalten und hoffen. Richtige Reaktion: Master-Rolle explizit setzen, CARP-Status prüfen, Config-Diff prüfen, dann kontrolliert re-synchen. Wer den Konfigurationsstand nicht kennt, macht mehr kaputt.

Fall 3: TrueNAS als Backup-Ziel nicht erreichbar. Der Veeam-Job schlägt fehl, das NAS pingt nicht. Falsche Reaktion: NAS neu starten. Richtige Reaktion: IPMI-Konsole, dmesg prüfen, Netzweg prüfen — oft ist es der Switch dazwischen. Wer sein Backup-Ziel neu startet, ohne die Ursache zu kennen, riskiert im schlimmsten Fall einen Import-Fehler beim Pool. Wer plant, gerade ein solches System aufzubauen, kann mit unserem TrueNAS-Konfigurator ein Setup rechnen, das im Ernstfall unabhängig vom Rest der Infrastruktur ansprechbar bleibt.

FAQ

Ab welcher Größe braucht ein KMU eine IT Notfall Hotline?

Es hängt weniger an der Mitarbeiterzahl als an der Abhängigkeit vom IT-System. Ein 12-Personen-Steuerbüro, das ohne DATEV und ohne Datenbestand nicht arbeiten kann, hat ein höheres Ausfallrisiko als ein 40-Personen-Handwerksbetrieb mit reiner Bürobelegung. Faustregel: Wer mehr als einen Arbeitstag Ausfall wirtschaftlich nicht ohne Weiteres verkraftet, sollte einen definierten Notfall-Draht haben.

Was kostet Server Ausfall 24 Stunden Support?

Der Preis ist immer abhängig vom Perimeter — also davon, was überwacht und im Ernstfall angefasst wird — und der Reaktionszeit. Managed-Service-Verträge mit 24/7-Rufbereitschaft sind günstiger als der einmalige Notfalleinsatz mit Erkundung von null. Wir machen keine Preisliste ins Blaue: Wer Rufbereitschaft plant, bekommt bei uns nach kurzer Sichtung ein individuelles Angebot mit klaren SLA-Punkten.

Wie unterscheidet sich Rufbereitschaft von normalem Support?

Normaler Support ist reaktiv innerhalb der Bürozeiten — Ticket, Antwort, Lösung. Rufbereitschaft ist proaktiv außerhalb der Bürozeiten: definierte Erreichbarkeit, definierte Reaktionszeit, definierter Zugriffsweg. Der große Unterschied ist die Vorbereitung: eine Hotline ohne vorher hinterlegten Zugriff ist nur ein Callcenter.

Wir haben einen Wartungsvertrag beim Hardware-Hersteller — reicht das nicht?

Ein Herstellervertrag deckt die Hardware — Ersatzteil vor Ort in X Stunden. Er deckt nicht die Anwendung, nicht die Konfiguration, nicht das ZFS-Pool-Layout, nicht die Backup-Kette. In der Praxis löst der Herstellervertrag typische nächtliche Ausfälle nicht, weil sie meist keine reinen Hardwarefehler sind. Beide Verträge ergänzen sich; keiner ersetzt den anderen.

Wie schnell muss die Reaktionszeit sein?

Das ergibt sich aus dem RTO — der maximal zulässigen Ausfallzeit — des kritischsten Systems. Wenn das RTO für ERP vier Stunden ist, kann die Reaktionszeit der Hotline nicht selbst schon vier Stunden sein. Wir empfehlen eine Reaktion innerhalb 60 Minuten für geschäftskritische Umgebungen und dokumentieren das im SLA.

Was passiert, wenn wir noch keinen Notfallvertrag haben und jetzt ein Problem?

Wir helfen im Rahmen unserer Kapazitäten auch ohne Bestandsvertrag — aber ohne die Vorbereitung ist der erste Einsatz teurer und langsamer, weil wir Ihr System erst kennenlernen. Der ehrliche Rat lautet: Vor dem Ernstfall abschließen. Wer heute anruft, gewinnt gegenüber dem, der erst um 3 Uhr nachts anruft, die entscheidenden Stunden.