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.
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:
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.
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.
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.
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:
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.
FAQ
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
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
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
Die meisten Fehler entstehen in fünf Bereichen:
FAQ
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
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
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
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.