Bare-Metal-Recovery testen: Vom Totalausfall zur laufenden Maschine

Was Bare-Metal-Recovery bedeutet

Bare-Metal-Recovery (BMR) heißt wörtlich: Wiederherstellung auf blankes Metall. Du startest mit einem leeren Server, ohne Betriebssystem, ohne Konfiguration, ohne Daten, und stellst das komplette System aus einem Backup wieder her. Am Ende hast du eine funktionsfähige Maschine, die idealerweise identisch mit dem Original ist.

Der Begriff grenzt sich von anderen Restore-Typen ab. Ein Datei-Restore stellt einzelne Dateien oder Ordner wieder her. Das Betriebssystem und die Anwendungen laufen bereits. Ein Anwendungs-Restore stellt eine komplette Anwendung wieder her, z.B. eine Datenbank inklusive aller Schemata und Daten. Das Betriebssystem läuft. Ein BMR stellt alles wieder her: Betriebssystem, Boot-Konfiguration, Treiber, Systemeinstellungen, Anwendungen und Daten.

BMR ist der umfassendste und anspruchsvollste Restore-Typ. Wenn ein BMR funktioniert, weißt du, dass dein Backup wirklich alles enthält, was du brauchst. Wenn nur Datei-Restores funktionieren, weißt du das nicht, denn es fehlen möglicherweise Systemkonfigurationen, Registry-Einträge, Dienst-Konfigurationen oder Treiber, die für den Betrieb des Systems notwendig sind.

Warum BMR-Tests unverzichtbar sind

Viele Unternehmen testen ihre Backups, indem sie gelegentlich eine Datei wiederherstellen. "Ja, der Restore funktioniert" ist dann das Ergebnis. Das ist besser als gar kein Test, aber es reicht nicht.

Was Datei-Restores nicht zeigen

Ein Datei-Restore testet, ob die Backup-Daten lesbar und intakt sind. Er testet nicht, ob das Betriebssystem aus dem Backup bootfähig wiederhergestellt werden kann, ob alle Treiber im Backup enthalten sind (insbesondere Storage- und Netzwerktreiber), ob die Boot-Konfiguration (BCD bei Windows, GRUB bei Linux) korrekt wiederhergestellt wird, ob die Anwendungen nach dem Restore starten und korrekt funktionieren, ob die Lizenzen nach dem Restore gültig sind (manche Software erkennt einen Hardware-Wechsel und verlangt eine Reaktivierung), ob die Netzwerkkonfiguration stimmt (IP-Adressen, DNS, Routen) und ob die Abhängigkeiten zu anderen Systemen (Active Directory, Datenbankserver, Lizenzserver) nach dem Restore funktionieren.

All diese Punkte können einen BMR scheitern lassen, selbst wenn das Backup technisch intakt ist. Und du erfährst davon erst im Ernstfall, also dann, wenn du es dir am wenigsten leisten kannst.

Regulatorische Anforderungen

BSI IT-Grundschutz Baustein CON.3 (Datensicherungskonzept) fordert regelmäßige Wiederherstellungstests, und zwar nicht nur auf Dateiebene. Der Baustein OPS.1.2.5 (Fernwartung) enthält die Anforderung, dass auch die Wiederherstellung von Systemen nach einem Totalausfall getestet werden soll.

ISO 27001 Annex A, Kontrolle A.8.13 (Information backup), fordert, dass Backup-Prozeduren regelmäßig getestet werden, um sicherzustellen, dass die gesicherten Informationen im Bedarfsfall wiederhergestellt werden können.

NIS2 fordert in Artikel 21 Maßnahmen zur Aufrechterhaltung des Betriebs einschließlich Backup-Management und Wiederherstellung nach einem Notfall. Ein Nachweis, dass du das tatsächlich getestet hast, ist bei einer Prüfung erheblich überzeugender als ein Dokument, das beschreibt, wie du es theoretisch machen würdest.

Vorbereitung: Was du vor dem Test brauchst

Ein BMR-Test erfordert Vorbereitung. Wenn du am Tag des Tests feststellst, dass dir ein Recovery-Medium fehlt oder die Hardware nicht kompatibel ist, verlierst du Stunden mit Troubleshooting.

Recovery-Medium erstellen und aktuell halten

Das Recovery-Medium ist die Boot-Umgebung, von der aus du den Restore startest. Je nach Backup-Software gibt es unterschiedliche Varianten.

Veeam: Der Veeam Recovery Media Creator erstellt eine bootfähige ISO-Datei, die du auf einen USB-Stick oder eine CD brennst. Die ISO enthält eine Mini-Linux-Umgebung (für Linux-Restores) oder eine WinPE-Umgebung (für Windows-Restores) mit dem Veeam-Restore-Agenten. Aktualisiere die ISO nach jedem Veeam-Update, damit die Version des Restore-Agenten zum Backup kompatibel ist.

Windows Server Backup: Windows Server erstellt ein Systemabbild, das über die Windows-Installationsmedien mit der Option "Computerreparaturoptionen > Problembehandlung > Systemimage-Wiederherstellung" wiederhergestellt werden kann. Du brauchst also die Windows-Server-Installations-ISO in der passenden Version.

Acronis: Acronis erstellt eine bootfähige Rescue-Media-ISO über das Acronis Media Builder Tool. Auch hier gilt: Die Version muss zum erstellten Backup passen.

Linux (Restic, BorgBackup): Für Linux-basierte Backup-Tools gibt es kein integriertes BMR. Du musst das Betriebssystem manuell installieren, die Backup-Software installieren und dann die Daten wiederherstellen. Alternativ nutzt du Tools wie Relax-and-Recover (ReaR), das speziell für Linux-BMR entwickelt wurde und bootfähige Recovery-Medien erstellt.

Zielhardware bereitstellen

Du brauchst Hardware, auf der du den Restore durchführst. Das muss nicht die identische Hardware des Originalsystems sein, aber es gibt Einschränkungen.

Physische Server: Wenn du auf andere Hardware wiederherstellst als auf dem Original, können Treiber-Probleme auftreten. Insbesondere Storage-Controller-Treiber und Netzwerkkarten-Treiber müssen zur Zielhardware passen. Veeam und Acronis bieten "Universal Restore"-Funktionen, die Treiber automatisch anpassen. Trotzdem solltest du die Treiber für die Zielhardware bereithalten.

Virtuelle Maschinen: Der einfachste Weg für einen BMR-Test. Erstelle eine leere VM mit den passenden Ressourcen (CPU, RAM, Disk) und stelle das Backup dort wieder her. Treiber-Probleme sind bei VMs selten, weil die virtuellen Hardware-Controller standardisiert sind.

Cloud-VMs: Du kannst einen BMR-Test auch in der Cloud durchführen (z.B. auf einer Azure-VM oder AWS-EC2-Instanz). Das ist sinnvoll, wenn du testen möchtest, ob dein Cloud-Backup auch tatsächlich in der Cloud wiederhergestellt werden kann.

Für regelmäßige BMR-Tests empfehle ich den Weg über virtuelle Maschinen. Du brauchst keine dedizierte Hardware, kannst Tests jederzeit durchführen und die Test-VM nach dem Test einfach löschen.

Zugangsdaten bereitstellen

Halte folgende Zugangsdaten bereit, bevor du den Test startest: die Zugangsdaten für die Backup-Software (Veeam-Server, Backup-Repository), die Verschlüsselungspasswörter für die Backups (falls verschlüsselt), die Zugangsdaten für den Cloud-Speicher (falls der Backup-Standort in der Cloud liegt) und die Administratorpasswörter für das System, das wiederhergestellt wird.

Im Ernstfall kann es sein, dass diese Zugangsdaten nicht verfügbar sind, weil der Passwort-Manager auf einem ausgefallenen System läuft. Ein durchdachtes Notfallhandbuch regelt diesen Fall. Halte eine Offline-Kopie an einem sicheren Ort (versiegelter Umschlag im Tresor).

Netzwerkumgebung vorbereiten

Der BMR-Test sollte in einer isolierten Netzwerkumgebung stattfinden, damit das wiederhergestellte System nicht mit dem Produktionssystem in Konflikt gerät (doppelte IP-Adressen, doppelte Computernamen im Active Directory, doppelte SPN-Einträge).

Richte ein isoliertes VLAN oder ein separates virtuelles Netzwerk ein. Wenn du auf einer lokalen VM testest, reicht ein Host-only-Netzwerk. Plane ggf. eine temporäre Netzwerkverbindung zum Backup-Speicher, falls der Restore über das Netzwerk erfolgt.

Durchführung: BMR-Test Schritt für Schritt

Phase 1: Restore starten

Boote die Zielhardware oder VM vom Recovery-Medium. Bei Veeam startest du den "Bare Metal Recovery Wizard", wählst den Backup-Standort (lokal, Netzwerk oder Cloud) und den gewünschten Wiederherstellungspunkt.

Stoppuhr starten: Ab jetzt läuft die Zeit. Notiere den Startzeitpunkt und messe die Dauer jeder Phase. Die Gesamtdauer ist deine Recovery Time Actual (RTA), die du später mit dem RTO vergleichst.

Backup-Standort verbinden: Konfiguriere die Netzwerkverbindung (IP-Adresse, ggf. Proxy) und verbinde dich mit dem Backup-Repository. Wenn der Restore aus der Cloud erfolgt, messe die Download-Geschwindigkeit. Sie ist der Flaschenhals für die Restore-Dauer.

Wiederherstellungspunkt wählen: Wähle den Wiederherstellungspunkt, der dem Testszenario entspricht. Für einen realistischen Test nimm nicht den neuesten, sondern einen, der einige Tage alt ist. Im Ernstfall ist der neueste Wiederherstellungspunkt möglicherweise kompromittiert.

Phase 2: Restore ausführen

Der eigentliche Restore-Vorgang ist weitgehend automatisiert. Veeam schreibt das Disk-Image auf die Zielfestplatte, stellt die Partitionsstruktur wieder her und spielt die Daten zurück.

Beobachte den Fortschritt und notiere die Geschwindigkeit (MB/s oder GB/h). Typische Werte: Lokaler Restore vom NAS: 500 MB/s bis 2 GB/s (je nach Storage und Netzwerk). Restore aus der Cloud bei 100 Mbit/s Leitung: ca. 40 GB/h (also 1 TB in ca. 25 Stunden). Restore aus der Cloud bei 1 Gbit/s Leitung: ca. 400 GB/h.

Wenn der Restore-Vorgang signifikant langsamer ist als erwartet, prüfe die Netzwerkverbindung, die Storage-Performance und ob die Backup-Software die Daten während des Restores dekomprimiert.

Phase 3: System starten und verifizieren

Nach Abschluss des Restores startest du das System neu und überprüfst, ob es korrekt bootet.

Boot-Prüfung: Startet das Betriebssystem ohne Fehler? Gibt es Blue Screens (Windows) oder Kernel-Panics (Linux)? Häufige Probleme hier sind fehlende oder inkompatible Storage-Treiber.

Netzwerk-Prüfung: Ist die Netzwerkkarte erkannt? Hat das System eine IP-Adresse (ggf. manuell konfigurieren, da der DHCP-Server in der Testumgebung möglicherweise fehlt)? Kann das System den DNS-Server erreichen?

Dienste-Prüfung: Laufen alle Dienste, die auf dem System konfiguriert sind? Prüfe insbesondere Datenbankdienste, Webserver, Anwendungsdienste und Backup-Agenten.

Anwendungs-Prüfung: Starten die Anwendungen und funktionieren sie? Für ein ERP-System: Kannst du dich anmelden? Werden Daten korrekt angezeigt? Funktionieren Berichte? Für einen Datenbankserver: Ist die Datenbank konsistent? Laufen Integritätsprüfungen fehlerfrei?

Daten-Prüfung: Sind die erwarteten Daten vorhanden? Entspricht der Datenstand dem gewählten Wiederherstellungspunkt? Stichprobenartig Dateien, Datenbankeinträge oder Konfigurationen prüfen.

Phase 4: Ergebnis dokumentieren

Dokumentiere den Test ausführlich. Ein gutes Testprotokoll enthält Datum und Uhrzeit des Tests, den Namen des getesteten Systems und den Wiederherstellungspunkt, die verwendete Hardware (Ziel), das Recovery-Medium und dessen Version, die Dauer jeder Phase (Vorbereitung, Restore, Boot, Verifikation), die Gesamtdauer (RTA), das Ergebnis (erfolgreich, teilweise erfolgreich oder fehlgeschlagen), aufgetretene Probleme und deren Lösung sowie offene Punkte und Maßnahmen.

Typische Probleme und ihre Lösungen

Treiber-Inkompatibilität

Das häufigste Problem bei BMR auf physischer Hardware. Das Betriebssystem startet nicht, weil der Storage-Controller-Treiber fehlt und das System die Festplatte nicht findet.

Lösung bei Veeam: Aktiviere "Universal Restore" und stelle die Treiber für die Zielhardware bereit (als Ordner mit INF-Dateien). Veeam injiziert die Treiber automatisch in das wiederhergestellte System.

Lösung bei Windows: Starte in den Reparaturmodus und lade den fehlenden Treiber manuell über die Kommandozeile mit dism /image:C:\ /add-driver /driver:D:\drivers\.

Prävention: Für jede potenzielle Zielhardware die Treiber bereithalten und regelmäßig aktualisieren.

UEFI/BIOS-Mismatch

Das Backup wurde auf einem UEFI-System erstellt, aber die Zielhardware bootet im Legacy-BIOS-Modus (oder umgekehrt). Das System findet den Bootloader nicht.

Lösung: Stelle sicher, dass die BIOS/UEFI-Einstellung der Zielhardware zum Backup passt. Bei Veeam wird der Boot-Modus im Backup-Metadaten gespeichert und kann im Restore-Wizard angezeigt werden.

Festplatte zu klein

Die Zielfestplatte ist kleiner als die Quellfestplatte. Der Restore schlägt fehl, weil das Disk-Image nicht passt.

Lösung: Verwende die Disk-Mapping-Funktion deiner Backup-Software, um Partitionen auf die kleinere Festplatte zu mappen. Alternativ: Zielfestplatte vergrößern. Bei VMs ist das trivial.

Lizenzen und Aktivierung

Windows erkennt nach dem BMR auf anderer Hardware einen "Hardware-Wechsel" und verlangt eine Reaktivierung. Manche Anwendungen (z.B. mit Dongles oder Hardware-gebundenen Lizenzen) funktionieren auf anderer Hardware nicht.

Lösung für Windows: OEM-Lizenzen sind an die Hardware gebunden und können nicht übertragen werden. Volume-Lizenzen (KMS, MAK) funktionieren unabhängig von der Hardware. Stelle sicher, dass deine Server Volume-Lizenzen verwenden.

Lösung für Anwendungen: Dokumentiere, welche Anwendungen Hardware-gebundene Lizenzen verwenden und welche Schritte im Ernstfall nötig sind (z.B. beim Hersteller anrufen und die Lizenz auf neue Hardware übertragen lassen).

Active-Directory-Konflikte

Wenn du einen Domain-Controller wiederherstellst und das AD noch auf anderen Domain-Controllern aktiv ist, kann es zu Replikationskonflikten kommen. USN-Rollbacks sind besonders gefährlich und können die gesamte AD-Replikation beschädigen.

Lösung: Stelle Domain-Controller nie blind aus einem alten Backup wieder her, wenn andere DCs noch laufen. Beachte die Hinweise zur Active-Directory-Absicherung und nutze stattdessen die AD-Replikation, um einen neuen DC hochzuziehen, oder führe eine autoritative Restore-Prozedur durch.

BMR-Testplan: Frequenz und Umfang

Nicht jedes System muss monatlich einem vollständigen BMR-Test unterzogen werden. Ein gestufter Ansatz ist pragmatischer.

Monatlich: Datei-Restores für alle gesicherten Systeme. Schnell durchführbar, testet die grundlegende Backup-Integrität.

Quartalsweise: BMR-Test für ein bis zwei geschäftskritische Systeme (z.B. ERP-Server im Q1, Active Directory im Q2, Fileserver im Q3, Datenbankserver im Q4). Rotierendes Schema, sodass jedes kritische System mindestens einmal jährlich einen BMR-Test durchläuft.

Halbjährlich: Vollständiger DR-Test, bei dem die gesamte Wiederherstellungskette getestet wird (nicht nur ein einzelnes System, sondern die Wiederherstellung mehrerer Systeme in der korrekten Reihenfolge).

Nach wesentlichen Änderungen: Immer dann, wenn sich die Backup-Infrastruktur ändert (neue Backup-Software, neues Repository, Migration in die Cloud), wenn sich die Zielhardware ändert (neuer Server, neue Storage-Controller) oder wenn sich das gesicherte System wesentlich ändert (Betriebssystem-Upgrade, neue Anwendungen).

BMR in virtuellen Umgebungen

In virtualisierten Umgebungen (VMware, Hyper-V, Proxmox) ist BMR einfacher und zuverlässiger als auf physischer Hardware, weil die Hardware-Abstraktionsschicht der Virtualisierung Treiber-Probleme eliminiert.

Veeam Instant VM Recovery

Veeam bietet eine besonders elegante Lösung: Instant VM Recovery. Dabei wird die VM direkt aus dem Backup gestartet, ohne die Daten vorher auf ein Storage zu kopieren. Das spart enorm Zeit: Statt Stunden für den Restore dauert es Minuten, bis die VM läuft. Die Performance ist eingeschränkt (die VM liest direkt aus dem Backup), aber für einen Test oder eine Notfallüberbrückung reicht es.

Anschließend kannst du die VM im Hintergrund auf das Produktions-Storage migrieren (Storage vMotion bei VMware oder Live Migration bei Hyper-V), ohne Downtime.

Proxmox Backup Server

Proxmox Backup Server unterstützt ebenfalls BMR von Proxmox-VMs. Der Restore erfolgt über die Proxmox-Weboberfläche: VM auswählen, Wiederherstellungspunkt wählen, Restore starten. Die VM wird auf dem Proxmox-Cluster wiederhergestellt und kann gestartet werden.

BMR-Test dokumentieren: Vorlage

Ein strukturiertes Testprotokoll könnte folgende Abschnitte enthalten:

Kopfdaten: Testdatum, Testnummer, Tester, System, Backup-Zeitpunkt, Backup-Standort.

Vorbereitung: Recovery-Medium geprüft (ja/nein, Version), Zielhardware vorbereitet (Beschreibung), Zugangsdaten verfügbar (ja/nein), Netzwerkumgebung isoliert (ja/nein).

Durchführung: Startzeit, Restore-Dauer, Boot-Ergebnis, Dienste-Status, Anwendungs-Test, Daten-Verifikation.

Ergebnis: RTA (gemessen), RTO (definiert), Abweichung, Gesamtbewertung (bestanden/nicht bestanden).

Feststellungen: Aufgetretene Probleme, Ursachen, durchgeführte Korrekturen.

Maßnahmen: Offene Punkte, Verantwortliche, Fristen.

Diese Dokumentation ist dein Nachweis für Audits und das Rohmaterial für die kontinuierliche Verbesserung deiner Wiederherstellungsprozesse. In ISMS Lite lassen sich BMR-Testprotokolle strukturiert erfassen und Abweichungen zwischen RTO und RTA systematisch nachverfolgen.

Vom Test zur Routine

BMR-Tests fühlen sich am Anfang aufwändig an. Der erste Test dauert einen ganzen Tag, weil du Probleme findest und löst, die du nicht erwartet hast. Der zweite Test geht schneller, weil du die bekannten Fallstricke bereits adressiert hast. Ab dem dritten oder vierten Test wird es Routine: Recovery-Medium bereitstellen, VM vorbereiten, Restore starten, verifizieren, dokumentieren. Zwei bis vier Stunden pro System.

Diesen Aufwand zu scheuen ist verständlich, ihn zu tragen ist überlebenswichtig. Ein BMR-Test pro Quartal für deine kritischsten Systeme ist eine Investition von wenigen Arbeitstagen pro Jahr, die im Ernstfall den Unterschied zwischen einem kontrollierten Wiederanlauf und einem chaotischen Totalausfall macht.

Weiterführende Artikel

• Disaster Recovery Plan erstellen: Vom Notfall zurück zum Normalbetrieb
• RPO und RTO richtig definieren: So findest du die passenden Werte
• Datensicherung nach BSI: Das 3-2-1-1-0-Prinzip in der Praxis
• Backup-Strategie und Restore-Tests: So sicherst du deine Daten richtig
• IT-Notfallkarte: Der Aushang für den Ernstfall