Teilen
von Nathan Fouarge am 23.07.2026 08:00:03
Ein vollständiger Restore-Test, bei dem von derselben Hardware gebootet wird, von der das Backup stammt, beweist lediglich, dass die Backup-Datei intakt ist. Ob sich der Server auch auf abweichender Hardware wiederherstellen lässt, zeigt dieser Test jedoch nicht.
Dieser Unterschied ist in 2026 deutlich wichtiger als früher.
Im März 2026 erreichten die Lieferzeiten für Halbleiter 40 Wochen (Accuris, 2026). Aufgrund verlängerter Lieferzeiten bei Komponenten hat TrendForce seine Wachstumsprognose für die Serverauslieferungen 2026 von 20% auf 13% gesenkt. (The Register, citing TrendForce, April 2026)
Fällt ein Server aus, steht möglicherweise nicht das Modell zur Verfügung, das Sie sonst bestellen würden. Da sich die Lieferzeiten für Neugeräte oft über Monate hinziehen, überbrücken MSPs die Lücke zunehmend mit generalüberholter Hardware, Modellen anderer Hersteller oder anderen verfügbaren Servern, während reguläre Bestellungen über den Standardvertriebsweg zurückgestellt werden.
In diesem Beitrag erfahren Sie, welche Probleme bei der Wiederherstellung mit abweichender Hardware auftreten können und wie Sie einen Restore-Test mit abweichender Hardware durchführen können, ohne ein Lager voller Ersatzteile zu benötigen.
Inhalt
- Warum die Wiederherstellung auf neuer Hardware ein gesondertes Problem darstellt
- Wiederherstellungen von Active Directory als separater Prozess
- So testen Sie ohne Ersatzhardware
- Ein einfacher Restore-Test
- Planen Sie es als routinemäßige Wartung ein
- FAQ
Warum die Wiederherstellung auf neuer Hardware ein gesondertes Problem darstellt
Bare Metal Restore (BMR) und die meisten imagebasierten Recovery-Tools unterstützen die Wiederherstellung auf abweichender Hardware. Für die Wiederherstellung von Active Directory empfiehlt Microsoft BMR-Backups, damit diese sich auf andere Hardware oder sogar eine andere Betriebssysteminstanz wiederherstellen lassen. Auch Drittanbieter-Tools verfügen über eigene Funktionen für diese Fähigkeit, etwa die Optionen von Acronis, Veeam und NovaBACKUP für abweichende Hardware und P2V.
Damit ein Backup tatsächlich bootfähig ist, müssen die passenden Treiber eingebunden sein, der Boot-Modus muss übereinstimmen und das Ziellaufwerk muss mindestens genauso groß sein wie das Ursprungslaufwerk. Wenn eine dieser Voraussetzungen fehlt, erhalten Sie zwar ein scheinbar funktionierendes Image, der Server startet aber trotzdem nicht.
Heutzutage ist das Treiber-Matching beim Wiederherstellen des Betriebssystems auf einem anderen Server bei den meisten Standardkonfigurationen weniger riskant als früher. Es gibt jedoch weiterhin Konfigurationen und Setups, die nicht so kooperativ sind.
Selbst bei den heute weniger fehleranfälligen Systemen können beim Hardwarewechsel folgende Probleme auftreten:
- Storage-Controller und Treiber. Ein anderer RAID-Controller oder ein Wechsel von SATA auf NVMe kann dazu führen, dass Windows das Systemvolumen nicht erkennt, sofern die passenden Treiber nicht installiert oder beim Wiederherstellen bereitgestellt werden.
- Boot-Modus und Secure Boot. Wird ein UEFI-System auf Hardware im Legacy- oder CSM-Boot-Modus wiederhergestellt (oder umgekehrt), startet der Server oft erst, nachdem die Firmware-Einstellung manuell umgestellt und die Booteinträge neu erstellt wurden.
- Disklayout und -größe. Ein Restore auf ein Laufwerk mit abweichender Größe oder Partitionierung kann Partitionen verschieben und Bootfehler verursachen, die bei einem Test auf derselben Hardware nicht auftreten.
- Netzwerk, besonders bei Domänencontrollern. Neue NICs bedeuten neue Gerätenamen und möglicherweise neue Treiber. Replikation oder Konnektivität gehen häufig kaputt, wenn ein Domänencontroller auf neuer Hardware wiederhergestellt wird, ohne dem Netzwerkstack Zeit zum Einpendeln zu geben. Idealerweise starten Sie ihn zunächst im abgesicherten Modus, bevor Sie AD- und Messaging-Dienste starten.
- Anwendungslizenzierung. Manche Fachanwendungen und Datenbanken binden ihre Lizenz an eine Hardware-ID. Das Betriebssystem bootet dann zwar sauber, die Anwendung verweigert aber trotzdem den Dienst.
Bei einem dateibasierten Wiederherstellungstest treten diese Probleme nicht auf und auch bei einer Image-Wiederherstellung auf derselben Hardware bleiben die meisten dieser Probleme unsichtbar. Sie zeigen sich erst, wenn die Zielhardware abweicht. Angesichts der Hardwareknappheit und der steigenden Preise im Jahr 2026 ist aber genau dieses Szenario realistisch.
Wiederherstellungen von Active Directory als separater Prozess
Wenn es sich bei dem betroffenen Server um einen Domänencontroller handelt, ist das Booten des Betriebssystems auf neuer Hardware erst der erste Schritt. Für die Wiederherstellung des Active-Directory-Systemzustands gelten eigene strenge Voraussetzungen. So muss der Rechnername mit dem Original übereinstimmen, der Windows-Build und der Service-Pack-Stand müssen exakt passen und das Zielsystem muss bereits zum Domänencontroller hochgestuft sein, bevor Sie das Active Directory darauf wiederherstellen können. In der Regel ist dafür ein ordnungsgemäßer Directory Services Restore Mode (DSRM)-Prozess erforderlich, um den Systemzustand zu aktualisieren. Dies ist ein eigener Schritt, der vom Desaster-Recovery-Image-Restore getrennt ist.
Sie sollten den Wiederherstellungsprozess eines Domänencontrollers auf neuer Hardware deshalb als eigenen Testfall behandeln und zusätzlich zum Standard-Wiederherstellungsprozess eines File- oder Applikationsservers durchführen.
Zusätzlich gibt es eine Altersgrenze für Backups des Active Directory. Active Directory erzwingt eine sogenannte Tombstone Lifetime. Das ist das maximale Alter, das eine Systemzustandssicherung haben darf, um noch sauber wiederhergestellt werden zu können, ohne verwaiste Objekte oder Replikationsfehler zu verursachen. Bei den meisten aktuellen ADs liegt der Standardwert bei 180 Tagen. Domänen, die älter als Windows Server 2003 SP1 sind, haben einen Standardwert von 60 Tagen. Wenn das Backup eines Domänencontrollers dieses Limit überschreitet, empfiehlt Microsoft in seiner eigenen Anleitung, die Domäne von einem noch funktionierenden DC aus neu aufzubauen, statt das veraltete Backup wiederherzustellen.
So testen Sie ohne Ersatzhardware
Für den Wiederherstellungstest auf andere Hardware benötigen Sie kein Regal voller Ersatzserver. Mit NovaBACKUP können Sie beispielsweise ein Systemimage als VHDx-Datei speichern und anschließend als virtuelle Maschine in Hyper-V einbinden. Das ist eine kostengünstige Möglichkeit, einen Restore auf abweichender Hardware zu simulieren. Ein Wiederherstellen auf einer VM mit einer anderen virtuellen Hardwaregeneration als der des ursprünglichen Hosts führt in der Regel zu den gleichen Treiber-, Boot-Modus- und Firmwareproblemen, die auch bei einem Wiederherstellen auf einem unbekannten physischen Server auftreten würden.
Für diese Szenarien sind folgende NovaBACKUP-Funktionen relevant: Image-Backups, die sich auf derselben oder abweichenden Hardware wiederherstellen oder als virtuelle Maschine einbinden lassen, sowie die Möglichkeit, beim Erstellen des Images spezielle Treiber – etwa für RAID-Controller – für die Installation auf dem Zielsystem zu hinterlegen. Damit lässt sich die häufigste Ursache für einen Restore, der nur mit einem schwarzen Bildschirm endet, gezielt vermeiden. Da sich Images außerdem als VHDx exportieren lassen, gehört die Wiederherstellung von physischen Servern als virtuelle Maschine zum Standardrepertoire.
Ein einfacher Restore-Test
Das Wichtigste ist, das Systembackup regelmäßig auf abweichender Hardware zu testen, damit Sie wissen, wie es sich verhält und wie lange es dauert. Hier ist ein einfaches Testszenario:
- Kritischen Server auswählen. Am besten eignet sich dafür ein Domänencontroller oder Dateiserver mit wichtigen Daten, denn hier können Sie sich am wenigsten Fehler leisten.
- Bewusst abweichendes Ziel bereitstellen. Nutzen Sie dazu einen Ersatzserver mit einem anderen RAID-Controller oder eine Hyper-V-VM mit abweichender virtueller Hardware und Boot-Firmware.
- Vollständiges Systemimage wiederherstellen. Stellen Sie sicher, dass alle vom Zielsystem benötigten Storage- oder Chipsatztreiber während des Vorgangs verfügbar sind.
- Bootprobleme beheben, sobald sie auftreten. Dazu gehört das Umschalten zwischen UEFI- und Legacy-Modus sowie bei Bedarf das Neuanlegen der Booteinträge.
- Über den Login-Bildschirm hinaus prüfen. Prüfen Sie, ob der Speicher sichtbar ist und die Netzwerkkarten sowie die IP-Adressierung stimmen. Kontrollieren Sie außerdem, ob AD, DNS, Freigaben und Fachanwendungen normal funktionieren.
- Dokumentieren, was Sie getan haben, wie lange es im Vergleich zu Ihrer RTO gedauert hat und was noch behoben werden muss.
Planen Sie es als routinemäßige Wartung ein
Der 2025 State of Ransomware Report von Sophos zeigt, dass der Anteil der Organisationen, die für die Wiederherstellung nach einem Angriff mehr als einen Monat benötigten, im Jahresvergleich von 34% auf 18% gesunken ist. Diese positive Entwicklung ist auf Organisationen zurückzuführen, die regelmäßig Recovery-Tests durchführen und die Ergebnisse dokumentieren.
Führen Sie einen Restore-Test mit abweichender Hardware als festen Bestandteil Ihres regulären Testplans durch. Für kritische Systeme sollte dieser mindestens einmal jährlich sowie unmittelbar nach jeder größeren Plattformänderung, wie einem Hardware-Refresh oder einer Hypervisor-Migration, erfolgen. Die Dokumentation dient als Nachweis gegenüber Cyber-Versicherern und Auditoren. Außerdem liefert sie Kunden, die noch nie ein Backup-Dashboard gesehen haben, den konkreten Beweis, dass ihr Recovery-Plan funktioniert.
Besuchen Sie unsere Seite zum Thema Desaster Recovery, um zu erfahren, wie NovaBACKUP Wiederherstellungen nach einem Desaster auf derselben oder abweichenden Hardware unterstützt. Mehr dazu lesen Sie in unserem Blogbeitrag So testen Sie Ihren Desaster-Recovery-Plan: Der vollständige Leitfaden zur Wiederherstellung Ihrer Backups.
Häufig gestellte Fragen
FAQ
Bedeutet ein erfolgreicher Backup-Restore-Test, dass das Backup auch auf neuer Hardware funktioniert?
Nein, denn ein solcher Test beweist nur, dass die Backup-Datei intakt ist, da er auf derselben Hardware bootet, von der das Backup stammt. Er beweist jedoch nicht, dass sich das Backup auf abweichender Hardware wiederherstellen lässt. Denn Treiber-, Boot-Modus- und Disklayout-Probleme treten erst auf, wenn sich die Zielhardware ändert.
FAQ
Warum ist ein Test mit abweichender Hardware im Jahr 2026 wichtiger als früher?
Im März 2026 erreichten die Lieferzeiten für Halbleiter 40 Wochen und TrendForce senkte seine Wachstumsprognose für die Serverauslieferungen des laufenden Jahres aufgrund der verlängerten Lieferzeiten bei Komponenten von 20% auf 13%. Fällt ein Server aus, wird er zunehmend durch ein generalüberholtes Gerät, ein Modell eines anderen Herstellers oder ein gerade verfügbares Gerät ersetzt, statt durch ein exaktes Gegenstück. Ein Restore-Test auf derselben Hardware spiegelt daher nicht wider, was bei einer echten Wiederherstellung passiert.
FAQ
Lassen sich BMR-Images auf abweichender Hardware wiederherstellen?
Ja. BMR und die meisten anderen imagebasierten Recovery-Tools unterstützen die Wiederherstellung auf abweichender Hardware. Microsoft empfiehlt BMR-Backups explizit für die Wiederherstellung von Active Directory, da sie sich auf andere Hardware oder sogar eine andere OS-Instanz nutzen lassen. NovaBACKUP, Acronis und Veeam bieten alle Optionen für Wiederherstellungen auf abweichender Hardware sowie für P2V (Physikalisch zu Virtuell).
FAQ
Was kann selbst bei einem gültigen Backup dazu führen, dass ein Restore auf abweichender Hardware fehlschlägt?
Die meisten Fehler entstehen in fünf Bereichen:
- Storage-Controller und Treiber: Ein anderer RAID-Controller oder ein Wechsel von SATA auf NVMe kann verhindern, dass Windows das Systemvolume ohne die passenden Treiber erkennt.
- Boot-Modus und Secure Boot: Wird ein UEFI-System auf Legacy-/CSM-Hardware wiederhergestellt (oder umgekehrt), muss oft die Firmware manuell umgestellt und die Booteinträge müssen neu erstellt werden.
- Disklayout und -größe: Ein abweichend großes oder partitioniertes Ziellaufwerk kann Partitionen verschieben und Bootfehler verursachen.
- Netzwerk: Neue NICs bedeuten neue Gerätenamen und Treiber, was die Replikation eines Domänencontrollers beeinträchtigen kann, wenn der Netzwerkstack keine Zeit zum Einpendeln bekommt.
- Anwendungslizenzierung: Manche Fachanwendungen binden ihre Lizenz an eine Hardware-ID. Das bedeutet: Das Betriebssystem kann booten, die Anwendung verweigert aber trotzdem den Dienst.
FAQ
Was ist beim Wiederherstellen eines Domänencontrollers auf neuer Hardware anders?
Das Booten des Betriebssystems ist erst die halbe Miete. Um den Active-Directory-Systemzustand wiederherzustellen, müssen der Rechnername mit dem Original übereinstimmen, der Windows-Build und der Service-Pack-Stand müssen exakt passen und das Zielsystem muss bereits vor dem AD-Restore zum Domänencontroller hochgestuft worden sein. In der Regel ist dafür ein Directory Services Restore Mode (DSRM)-Prozess nötig, der getrennt vom eigentlichen Disaster-Recovery-Image-Restore läuft.
FAQ
Gibt es eine Altersgrenze für Active-Directory-Backups?
Ja. Active Directory erzwingt eine sogenannte Tombstone Lifetime. Das ist das maximale Alter, das eine Systemzustandssicherung haben darf, um noch sauber wiederhergestellt werden zu können, ohne verwaiste Objekte oder Replikationsfehler zu verursachen. Der Standardwert liegt bei 180 Tagen für die meisten aktuellen Active-Directory-Umgebungen und bei 60 Tagen für Domänen, die älter als Windows Server 2003 SP1 sind. Wenn das einzige verfügbare Backup älter als dieses Limit ist, empfiehlt Microsoft, die Domäne von einem noch funktionierenden Domänencontroller aus neu aufzubauen, statt das veraltete Backup wiederherzustellen.
FAQ
Wie lässt sich ein Restore auf abweichender Hardware testen, ohne zusätzliche Server kaufen zu müssen?
Speichern Sie ein Systemimage als VHDx-Datei und binden Sie es als virtuelle Maschine in Hyper-V ein. NovaBACKUP unterstützt diese Vorgehensweise. Ein Restore auf einer VM mit abweichender virtueller Hardware im Vergleich zum ursprünglichen Host deckt die meisten Treiber-, Boot-Modus- und Firmwareprobleme auf, die auch bei einem Restore auf einem unbekannten physischen Server auftreten würden – allerdings ohne die Kosten für Ersatzhardware.
FAQ
Wie oft sollten MSPs einen Restore-Test mit abweichender Hardware durchführen?
Mindestens einmal jährlich für kritische Systeme sowie unmittelbar nach jeder größeren Plattformänderung, etwa einem Hardware-Refresh oder einer Hypervisor-Migration. Laut dem „2025 State of Ransomware Report" von Sophos ist der Anteil der Organisationen, die für die Wiederherstellung nach einem Angriff mehr als einen Monat brauchten, im Jahresvergleich von 34% auf 18% gesunken. Dieser Trend geht einher mit Organisationen, die ihren Recovery-Prozess regelmäßig testen und dokumentieren.
Quellen
- The Register, citing TrendForce. "AI now gobbling up power and management chips for servers." April 2026
- Accuris. The Slow Burn Becomes a Flash Point. 2026
- Microsoft. AD Forest Recovery: Backing Up a Full Server
- Microsoft. Shelf Life of a System State Backup for Active Directory
- Sophos. State of Ransomware 2025 Press Release
Lesenwert
Warum ein vollständiger Restore-Test auf abweichender Hardware wichtig ist
Wie Sie einen Ein-Personen-MSP ohne Burnout führen
Teilen
