Wenn der Server stirbt: Eine Notfall-Migration auf neue Hardware, Schritt für Schritt

Ein Kunde meldete sich mit dem denkbar unangenehmsten Satz, den man in der IT hören kann: "Unser Server geht nicht mehr an." Der physische Server – ein klassischer Windows-Hyper-V-Host, der eine einzelne, aber geschäftskritische virtuelle Maschine trug – war endgültig ausgefallen. Die gute Nachricht: Ein taggenaues Backup existierte. Die schlechte Nachricht: Der Ersatz-Host war neu, ungetestet, und die Wiederherstellung musste sitzen, ohne dass irgendetwas anderes im Netzwerk beschädigt wurde.

Der Ausgangspunkt

Backup-Software wie Active Backup for Business bietet für genau diesen Fall mehrere Wiederherstellungspfade. Zwei standen zur Wahl:

1. Sofortige Wiederherstellung auf den integrierten Virtualisierungs-Host des Backup-Servers selbst – schnell einsatzbereit, aber mit eingeschränkter I/O-Leistung, solange die Maschine nicht auf ihre endgültige Plattform migriert wurde. Gedacht als Notlösung, um die Ausfallzeit zu minimieren.
2. Vollständige Wiederherstellung direkt auf einen neuen, dedizierten Hyper-V-Host – aufwendiger, aber von Anfang an mit voller Leistung und am richtigen Zielort.

Der erste Weg wurde zunächst gewählt, um überhaupt wieder ein lauffähiges System zu haben. Das ist ein legitimes Vorgehen – nur darf man nicht vergessen, dass es eine Zwischenlösung ist. Sobald der eigentliche Ersatz-Server bereitstand, folgte der zweite, endgültige Schritt.

Die Grube, in die man leicht fällt: Doppelte Objekte im UI

Bevor die eigentliche Migration begann, fiel beim Blick in die Verwaltungsoberfläche etwas Verwirrendes auf: Es schien zwei unabhängige Hyper-V-Hosts zu geben – einer davon dauerhaft offline, mit exakt denselben Hardware-Spezifikationen (gleiche CPU-Kern-Anzahl, gleicher Arbeitsspeicher, identische Festplattengrößen) wie der neue, echte Server. Auf den ersten Blick sah das nach einer zweiten, unbekannten Infrastruktur aus.

Der Verdacht bestätigte sich schnell als falscher Alarm: Der vermeintliche zweite Host war schlicht ein veralteter Verbindungseintrag mit der alten IP-Adresse desselben physischen Geräts, von einer früheren Netzwerkkonfiguration übrig geblieben. Die Backup-Software hatte diese Verbindung nie automatisch bereinigt, sodass sie als eigenständiger (und dauerhaft fehlschlagender) Eintrag in der Aufgabenliste weiterlief.

Die Lehre daraus: Bevor man eine unbekannte zweite Komponente als "separate, unabhängige Infrastruktur" abtut, lohnt sich ein Soll-Ist-Abgleich mit den tatsächlich aktiven Netzwerkgeräten – zum Beispiel über die Client-Liste des Netzwerk-Controllers. Ein Host, der dort schlicht nicht auftaucht, ist offline oder existiert gar nicht mehr, unabhängig davon, was ältere Notizen oder Backup-Konfigurationen suggerieren. Nach der Bestätigung wurde die veraltete Verbindung inklusive der zugehörigen (und ohnehin nutzlosen) Backup-Aufgabe restlos entfernt.

Die eigentliche Migration

Mit einem sauberen Bild der tatsächlichen Infrastruktur ging es an die vollständige Wiederherstellung:

• Neue Verbindung zum frischen Hyper-V-Host aufbauen (WinRM war dort bereits aktiv – ein guter Hinweis, das bei jeder Neuinstallation eines Windows-Servers direkt mit einzurichten).
• Den aktuellsten erfolgreichen Wiederherstellungspunkt auswählen.
• Wichtig: Nicht "am ursprünglichen Speicherort wiederherstellen" wählen, wenn der ursprüngliche Host tot ist – das würde die Wiederherstellung schlicht gegen eine nicht erreichbare Adresse laufen lassen. Stattdessen "an einem neuen Speicherort" mit explizitem Ziel-Host, Ziel-Datenspeicher und Ziel-Netzwerk.
• Die Option zur Neugenerierung der MAC-Adresse aktivieren, wenn die ursprüngliche MAC statisch mit einem DHCP-Reservierungseintrag verknüpft war – sonst drohen Adresskonflikte, sobald beide Kopien (alte und neue) gleichzeitig im Netz hängen.

Ein Detail, das leicht übersehen wird: Auf demselben neuen Host lief bereits eine völlig andere, produktiv genutzte virtuelle Maschine für andere Zwecke. Diese durfte unter keinen Umständen berührt werden. Ein Wiederherstellungsassistent merkt sich häufig die zuletzt ausgewählte Zeile – ein zweiter Blick auf den Dialogtitel, bevor man auf "Weiter" klickt, hat hier tatsächlich einen Fehlklick auf die falsche Maschine verhindert.

Die alte Kopie sauber abschalten

Sobald die neue, vollständige Kopie auf dem richtigen Host lief, musste die vorherige Notlösungs-Instanz vom Netz. Ohne installierte Gastwerkzeuge ließ sich kein ordentliches Herunterfahren aus dem Betriebssystem heraus anstoßen – ein erzwungenes Abschalten auf Hypervisor-Ebene war hier unproblematisch, da die Kopie ohnehin verworfen werden sollte.

Die zweite Falle: Falsches VLAN

Nach dem Start der neuen virtuellen Maschine bekam sie zwar eine IP-Adresse – aber aus dem falschen Netzsegment. Die produktive Vergleichsmaschine auf demselben Host war über ein VLAN-Tag ("Access", spezifische VLAN-ID) an das interne Praxis-/Firmennetz gebunden; die frisch wiederhergestellte Maschine hingegen blieb "untagged" und landete dadurch im allgemeinen Verwaltungsnetz.

Die Diagnose ließ sich pro Maschine sauber trennen:

Get-VMNetworkAdapterVlan -VMName Server1 | Format-List OperationMode,AccessVlanId
Get-VMNetworkAdapterVlan -VMName VM1     | Format-List OperationMode,AccessVlanId

Der Vergleich zeigte den Unterschied schwarz auf weiß: Die eine Maschine im Access-Modus mit gesetzter VLAN-ID, die andere komplett ungetaggt. Die Korrektur ist eine einzige Zeile:

Set-VMNetworkAdapterVlan -VMName VM1 -Access -VlanId 2

Ein Restore-Wizard kopiert zuverlässig Festplatten, Arbeitsspeicher-Konfiguration und (bei aktivierter Option) sogar eine neue MAC-Adresse – aber VLAN-Zuordnungen auf dem virtuellen Switch sind host-spezifische Einstellungen, die nicht automatisch aus dem Backup übernommen werden. Wer nach einer Migration nur prüft "hat die Maschine überhaupt eine IP", übersieht leicht, dass es die falsche IP im falschen Netz sein kann.

Fazit

Drei Lehren aus dieser Migration, die sich auf jeden ähnlichen Fall übertragen lassen:

Erstens: Ein zweiter, unbekannter Eintrag in der Verwaltungsoberfläche ist nicht automatisch eine zweite, unabhängige Infrastruktur – oft ist es nur ein veralteter Verweis auf dieselbe Maschine unter einer alten Adresse. Ein Abgleich mit der tatsächlichen Netzwerkrealität schafft Klarheit, bevor man falsche Annahmen in weitreichende Entscheidungen einfließen lässt.

Zweitens: Bei der Wahl des Wiederherstellungsmodus zählt der Unterschied zwischen "schnell wieder online" und "richtig wieder online". Beide haben ihre Berechtigung – aber nur, wenn man bewusst weiß, in welcher Phase man gerade steckt, und die Notlösung nicht versehentlich zum Dauerzustand wird.

Drittens: Netzwerksegmentierung (VLANs) lebt auf der Ebene des virtuellen Switches, nicht im Backup selbst. Nach jeder Hypervisor-Migration lohnt sich ein expliziter Vergleich der VLAN-Konfiguration zwischen der neuen Maschine und einer bekannt funktionierenden Vergleichsmaschine auf demselben Host – eine Zeile PowerShell, die viel Sucherei erspart.

Dieser Beitrag beschreibt ein anonymisiertes, reales Fallbeispiel aus unserem IT-Support-Alltag. Konkrete Kundennamen, Gerätebezeichnungen, IP-Adressen und Uhrzeiten wurden entfernt oder verallgemeinert.