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 pruefen, 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 fuer unsere Rufbereitschaft. Er ist ein Ratgeber fuer alle, die im Ernstfall am Telefon sind: eigene IT, externer Dienstleister, Geschaeftsfuehrer, der die Nachricht bekommt. Er beschreibt, was in der ersten halben Stunde ohne Panik passieren sollte, wie man Backup-Reports von Backup-Realitaet unterscheidet, warum ein DR-Runbook mehr wert ist als jede Zertifizierung — und ab welchem Punkt der Anruf bei einer IT Notfall Hotline die guenstigere 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 ueberhaupt beim Kunden, wo liegt was, welche Passwoerter gelten? — kostet die entscheidenden Stunden. Deshalb ist eine IT Notfall Hotline immer ein Managed-Service-Baustein, nie ein spontanes Feuerwehrgeschaeft.

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 moeglicherweise 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-Aufloesung 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 fuenf Fragen dauern zusammen unter fuenf Minuten, wenn die Zugaenge stehen. Sie ersetzen keine Diagnose, aber sie schliessen die Haelfte der moeglichen Ursachen aus.

Was in den ersten 30 Minuten NICHT passieren sollte

Klare Verbote fuer 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 Aenderung 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-Realitaet pruefen: laeuft es wirklich?

Der schlimmste Moment im Nachtdienst ist nicht der Ausfall, sondern die Entdeckung, dass das Backup seit drei Wochen nicht mehr laeuft und niemand es gemerkt hat, weil die Reports im Spam-Ordner gelandet sind. Deshalb gehoert zur naechtlichen Bestandsaufnahme immer auch die Backup-Realitaet.

Backup-Realitaet ist nicht der gruene Haken im Dashboard. Sie besteht aus drei Fragen:

1. Ist der letzte erfolgreiche Backup-Job juenger 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 durchgefuehrt, 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 ausfuehrliche Artikel verfasst, die ins Runbook gehoeren:

• 3-2-1-1-0-Backup-Formel: die naechste 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 Herzstueck jedes Notfalls. Es ist kein 80-Seiten-Konzept — es ist eine Handvoll klar strukturierter Seiten pro System, das der Kunde hat. Ein tragfaehiges DR-Runbook beantwortet fuer jeden Kernservice sechs Fragen:

1. Was ist es? Ein Satz zur Funktion.
2. Wovon haengt es ab? Netz, DNS, AD, Storage, VPN.
3. Wie erkennt man Ausfall? Konkreter Test, den auch der Nachtdienst um 3 Uhr durchfuehren 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 laeuft.

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.

Fuer die grosse Linie — also die Frage, wie ein KMU Ausfallzeiten strukturell reduziert — lohnt sich zusaetzlich der Blick in unseren Disaster-Recovery-Ratgeber fuer 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 frueh anrufen fuehlt sich unprofessionell an. Zu spaet anrufen kostet mehr, als wenn man von Anfang an angerufen haette.

Es gibt drei sehr klare Signale, an denen der Anruf bei einer Server Ausfall 24 Stunden Support-Hotline die guenstigste 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 zusaetzliche Augen selten schneller. Zwei Techniker mit unterschiedlichem Blick finden systematisch mehr als einer, der immer muede wird.

Signal 2: Die naechste Handlung ist irreversibel. Restore ueberschreibt Daten. Firmware-Update kann das Storage endgueltig blocken. Cluster-Neuformierung setzt Konfiguration zurueck. Vor jeder irreversiblen Handlung ist ein zweites Paar Augen keine Schwaeche, 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 koennen — 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 loest, den der Standard-Support in der Nacht nicht loest.

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, Zugaenge, 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 ueberschaubaren 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 faellig wird.

Praxis: drei typische naechtliche Ausfaelle

Um das Ganze konkret zu machen — drei Vorfaelle, 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 laeuft weiter — langsam. Falsche Reaktion: sofort tauschen und resilvern. Richtige Reaktion: SMART lesen, Pool-Status pruefen, Backup-Zustand verifizieren, dann geplant im Wartungsfenster tauschen. Kein Nacht-Fire-Drill noetig, wenn die Bestandsaufnahme sauber ist.

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

Fall 3: TrueNAS als Backup-Ziel nicht erreichbar. Der Veeam-Job schlaegt fehl, das NAS pingt nicht. Falsche Reaktion: NAS neu starten. Richtige Reaktion: IPMI-Konsole, dmesg pruefen, Netzweg pruefen — 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 unabhaengig vom Rest der Infrastruktur ansprechbar bleibt.

FAQ

Ab welcher Groesse braucht ein KMU eine IT Notfall Hotline?

Es haengt weniger an der Mitarbeiterzahl als an der Abhaengigkeit vom IT-System. Ein 12-Personen-Steuerbuero, das ohne DATEV und ohne Datenbestand nicht arbeiten kann, hat ein hoeheres Ausfallrisiko als ein 40-Personen-Handwerksbetrieb mit reiner Buerobelegung. 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 abhaengig vom Perimeter — also davon, was ueberwacht und im Ernstfall angefasst wird — und der Reaktionszeit. Managed-Service-Vertraege mit 24/7-Rufbereitschaft sind guenstiger 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 Buerozeiten — Ticket, Antwort, Loesung. Rufbereitschaft ist proaktiv ausserhalb der Buerozeiten: definierte Erreichbarkeit, definierte Reaktionszeit, definierter Zugriffsweg. Der grosse 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 loest der Herstellervertrag typische naechtliche Ausfaelle nicht, weil sie meist keine reinen Hardwarefehler sind. Beide Vertraege ergaenzen sich; keiner ersetzt den anderen.

Wie schnell muss die Reaktionszeit sein?

Das ergibt sich aus dem RTO — der maximal zulaessigen Ausfallzeit — des kritischsten Systems. Wenn das RTO fuer ERP vier Stunden ist, kann die Reaktionszeit der Hotline nicht selbst schon vier Stunden sein. Wir empfehlen eine Reaktion innerhalb 60 Minuten fuer geschaeftskritische Umgebungen und dokumentieren das im SLA.

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

Wir helfen im Rahmen unserer Kapazitaeten 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 abschliessen. Wer heute anruft, gewinnt gegenueber dem, der erst um 3 Uhr nachts anruft, die entscheidenden Stunden.