XPLN/Lernbereiche

E10 · Betrieb · Windows / Kea

Migration und Wiederherstellung

Kapitel in dieser Lernstufe

Das lernst du

  • Konfiguration und Leases gemeinsam in eine Umstellung einbeziehen.
  • Cutover, Abnahme und Rollback zeitlich planen.

Voraussetzungen: E04 · Hochverfügbarkeit und FailoverE06 · Dynamische DNS-IntegrationE09 · Wiederholbare Automatisierung

Ein neuer Server mit identischen Poolgrenzen ist noch kein sicherer Ersatz. Wenn er alte gültige Zuordnungen nicht kennt, kann er Adressen erneut anbieten, die Clients weiterhin verwenden dürfen.

Beim Umschalten wandert auch Verantwortung

Cutover: ein klarer Wechsel der VerantwortungAlter ServerNeuer ServerCutoverKonsistenterLeasebestandNeue Leases entstehennur im neuen BestandRollback muss die inzwischen vergebenen Leases kennen.
Grafik vergrößern
Cutover: ein klarer Wechsel der VerantwortungAlter ServerNeuer ServerCutoverKonsistenterLeasebestandNeue Leases entstehennur im neuen BestandRollback muss die inzwischen vergebenen Leases kennen.
Der Cutover überträgt die Vergabeverantwortung mit einem konsistenten Leasebestand. Neue Leases nach dem Wechsel fehlen in der alten Sicherung. Ein Rollback muss diese Nutzungsrechte berücksichtigen, bevor der alte Server wieder vergibt; ein bloßer Wechsel des Relayziels genügt nicht.

Vorbereiten und umschalten

Erfasse Bereiche, Optionen, Reservierungen, Policies, Leases, Relayziele, DNS-Updatecredentials und gegebenenfalls Failoverbeziehungen. Erstelle eine überprüfbare Sicherung. Ein Konfigurationsexport ohne Leases ist für eine laufende Migration möglicherweise unzureichend.

Bereite den Zielserver isoliert oder mit deaktivierten Bereichen vor. Verhindere unkoordinierte parallele Vergabe. Plane einen kontrollierten Übergang mit eindeutigem aktiven Anbieter, aktuellen Nutzungsdaten und angepassten Relayzielen. Produktübergreifende Leaseformate lassen sich nicht beliebig direkt importieren.

Rollback ist ein eigener Ablauf

Definiere vorher, bei welchen Befunden zurückgekehrt wird. Ein Rollback darf nicht einfach den alten Server mit veralteter Lease-Datenbank neben den neuen stellen. Neue Vergaben seit dem Cutover müssen berücksichtigt oder die Umstellung unter kontrolliertem Stopp rückgeführt werden.

Eine Wiederherstellung ist erst getestet, wenn die Sicherung auf einer isolierten Instanz geladen, Konfiguration und Leases verglichen und Clientbezug geprüft wurden. Ein existierendes Backupfile ist nur ein Artefakt, noch kein Nachweis der Wiederherstellbarkeit.

Der Zeitpunkt des Leasebestands ist entscheidend

Eine Sicherung beschreibt einen vergangenen Zustand. Vergibt der alte Server nach dem Export weitere Adressen, fehlen diese Nutzungsrechte möglicherweise im neuen Bestand. Wird der neue Server mit überlappendem Pool aktiviert, kann er solche Adressen für frei halten. Eine Migration benötigt deshalb einen definierten letzten konsistenten Datenstand und einen kontrollierten Übergang der Vergabeverantwortung.

Konfiguration, Lease-Daten, Reservierungen, DNS-Zuständigkeiten und Relayziele gehören gemeinsam in den Plan, sind aber unterschiedliche Bestände. Prüfe, welche davon das verwendete Export- beziehungsweise Importverfahren tatsächlich übernimmt. Eine erfolgreich eingelesene Datei garantiert weder passende Netzwerkbindungen noch korrekte Updateberechtigungen am DNS-Server. Diese Punkte benötigen eigene Abnahmeschritte.

Rückkehr nach bereits erfolgten Vergaben

Sobald der neue Server Clients bestätigt hat, ist ein Rollback nicht mehr nur das Zurückschalten eines Relayziels. Auch der neue Leasebestand enthält nun gültige Nutzungsrechte. Der alte Server darf nicht mit einer veralteten Sicht unkoordiniert dieselben Adressen vergeben. Vor der Rückkehr muss feststehen, wie diese inzwischen entstandenen Bindungen berücksichtigt werden.

Lege deshalb vorab Abbruchkriterien und Entscheidungszeitpunkte fest. Ein Fehler vor der ersten neuen Vergabe ist anders zu behandeln als ein Fehler nach einer Stunde Betrieb. Im Labor werden beide Fälle getrennt geübt. Ein vollständiger Wiederherstellungstest endet mit geprüften Clients, konsistenten Leasebeständen und kontrollierter Abschaltung des nicht mehr verantwortlichen Anbieters, nicht bereits mit einem gestarteten Dienst.

DURCHGEARBEITETES BEISPIEL

Windows-Export mit Lease-Daten

  1. Vor Änderung Export inklusive Leases erzeugen und Zeitpunkt dokumentieren. Die Beispieldatei enthält Betriebsdaten und gehört nur ins Labor bzw. einen angemessen geschützten Speicher.
  2. Ziel mit passender Rolle vorbereiten. Import im isolierten Zustand durchführen, Scope-/Options-/Leaseanzahl vergleichen und noch nicht parallel produktiv antworten lassen.
  3. Alten Vergabeweg kontrolliert stoppen, Relayziele ändern, neue und bestehende Clients testen. DNS-Updates sowie gegebenenfalls Partnerkonfiguration separat abnehmen.
  4. Rollback nur mit abgestimmtem Lease-Stand und eindeutig aktiver Seite durchführen; Snapshot-Restore beider Seiten ohne Betrachtung des Zeitverlaufs vermeiden.
Windows PowerShell · Labor
Export-DhcpServer -ComputerName DHCP01 -File C:\Lab\dhcp.xml -Leases -Force
# Auf isoliert vorbereitetem Ziel; BackupPath muss existieren:
Import-DhcpServer -ComputerName DHCP02 -File C:\Lab\dhcp.xml -BackupPath C:\Lab\BeforeImport -Leases

Ergebnis: Migration ist eine Zustandsübertragung plus kontrollierter Verkehrswechsel. P32/P33 verlangen Nachweise vor, während und nach dem Wechsel.

Typische Fehler

  • Nur die Konfigurationsdatei zu sichern kann Leasewissen verlieren.
  • Relayänderung und Serverabschaltung brauchen eine abgestimmte Reihenfolge.
  • Ein Snapshot ist kein Freibrief, zeitabhängige Leases unkoordiniert zurückzudrehen.

Praktisch anwenden

P32 öffnen P33 öffnen

Offizielle Quellen

Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.