Hardwareumzug mit Backup und Restore

  • Article

Schon oft habe ich in den Newsgroups die folgende Frage in verschiedenen Ausprägungen gelesen: Mal angenommen, ein Kunde hat sich von $Verkäufer vor einiger Zeit einen Small Business Server verkaufen lassen. Die Zeit vergeht schnell und die Hardware ist jetzt zu alt, zu langsam, zu klein... Gibt es einen empfohlenen Weg, das Active Directory und vor allem den Exchange Server auf einen neuen Server umzuziehen?

Den meisten fällt in diesem Zusammenhang eine sanfte Migration mittels Aufbau eines zweiten Servers, Replikation des ADs, Installation eines zweiten Exchange Servers und Nutzung der Move Mailbox-Methode ein.

Ich stelle dann oft ketzerisch eine Gegenfrage. Wenn es um die Umstellung von alter auf neue Hardware geht und man mit der Serverinstallation an sich zufrieden ist: Was spricht eigentlich gegen ein Backup und Restore? Man schlägt sogar zwei Fliegen mit einer Klappe - kann man doch dabei gleich ein Disaster Recovery Szenario schön testen.

Die Kritikpunkte an der Vorgehensweise sind zu erwartende Probleme durch beispielsweise eine andere HAL (Standard PC vs. MPS/ACPI Multiprozessor), Hyperthreading CPUs (PIC vs. APIC), ein anderer Speicherkontroller (IDE vs. SCSI) oder auch der Wechsel von non-RAID auf RAID.

Neben den Lösungen von Drittanbietern aus dem Bereich Imaging, die von Seiten Microsofts nicht supported werden können, gibt es auch Wege, mit dem klassischen NtBackup zum Ziel zu kommen. Da ich gerade wieder per Email nach Informationen dazu gefragt wurde, hier die passenden Links:

Wenn man sich voher noch Gedanken um einen eventuell neuen Speicher-Controller macht und dessen Treiber vorher im laufenden System installiert, sollte dem Wechsel nichts mehr im Wege stehen:

Bei IDE-Controllern kann man auch den "Standard Dual-Channel PCI IDE Controller" von
Windows laden. Nach dem Restore installiert man dann den gewünschten Spezialtreiber nach. Bei RAID-Controllern reicht es aus, vorher den Treiber des neuen RAID-Controllers zu laden. Einfach als Hardware hinzufügen, so dass er im Gerätemanager als (fehlendes) Gerät auftaucht. Beim nächsten Neustart wird der alte und der neue Controller-Treiber geladen. Der fehlende Controller wird dann einfach ignoriert.

Neben diesem direkten Weg kann auch Windows eine Menge unterschiedlicher Controllertreiber "injizieren", die dann beim nächsten Neustart nacheinander geladen werden, bis der richtige passt. Die genaue Vorgehensweise findet sich zum Beispiel in der Dokumentation zu dem Tool Sysprep.

Mit Backuptools wie z.B. Symantec BackupExec kann man auch beim Restore die Registry mergen lassen. Beim Restore installiert man ja als erstes ein normales Windows mit dem richtigen Storagetreiber und darauf dann BackupExec. Danach erfolgt der Restore. Beim nächsten Reboot wird dann automatisch der alte und der neue Treiber geladen. Damit hatte ich bisher keine Probleme beim Hardwaretausch mit Hilfe von Backup und Restore.

Ich denke, daß man mit ein bißchen Planung besser fährt als mit der oft empfohlenen Swing-Methode. Vor allem kann man das ganze im Testlab komplett durchziehen und hat keinerlei Auswirkungen auf das Livesystem. Wenn etwas wider Erwarten nicht so funktioniert, wie man sich das vorstellte, kann man jederzeit das alte System wieder anschalten und alles läuft wie vorher. Dagegen habe ich bei einem Ex-Kollegen schon ein Swing-Disaster gesehen, als während der Umstellung die temporäre Hardware den Geist aufgab. Da mußte auf einmal ganz schnell ein Disaster Recovery her.

Ausserdem bringt die Umstellung mittels Backup & Recovery gleich das notwendige Rüstzeug für ein Disaster Recovery Szenario mit sich. Wieviele Admins haben schon einmal ernsthaft ihre Umgebung testweise auf andere Hardware (z.B. in eine virtuelle Maschine) zurückgesichert? Ich wette, viele wissen oft noch nicht einmal, wie das genau geht und das ist im Ernstfall oft das größte Problem.