Testing Bare-Metal Recovery: From Total Failure to a Running Machine

TL;DR

A Bare-Metal Recovery (BMR) restores a complete system from scratch: operating system, drivers, configuration, applications, and data. It is the most comprehensive backup test.
BMR tests reveal problems that simple file restores do not show: missing drivers, boot issues, license activation, dependencies on other systems.
The most common pitfalls in BMR tests are incompatible hardware (drivers), missing boot media, outdated recovery ISO files, and untested network connectivity.
BMR tests should be performed at least semi-annually for business-critical systems. BSI and ISO 27001 require regular recovery tests.
Every BMR test produces a measured Recovery Time Actual (RTA) that must be compared with the defined RTO. If values diverge, action is needed.

What bare-metal recovery means

Bare-Metal Recovery (BMR) literally means: recovery onto bare metal. You start with an empty server -- no operating system, no configuration, no data -- and restore the complete system from a backup. At the end, you have a functional machine that is ideally identical to the original.

The term distinguishes itself from other restore types. A file restore recovers individual files or folders; the operating system and applications are already running. An application restore recovers a complete application, e.g., a database including all schemas and data; the operating system is running. A BMR restores everything: operating system, boot configuration, drivers, system settings, applications, and data.

BMR is the most comprehensive and demanding restore type. If a BMR works, you know your backup truly contains everything you need. If only file restores work, you do not know that -- there may be missing system configurations, registry entries, service configurations, or drivers essential for the system to operate.

Why BMR tests are indispensable

Many organizations test their backups by occasionally restoring a file. "Yes, the restore works" is then the result. That is better than no test at all, but it is not enough.

What file restores do not reveal

A file restore tests whether the backup data is readable and intact. It does not test whether the operating system can be restored bootably from the backup, whether all drivers are included in the backup (especially storage and network drivers), whether the boot configuration (BCD on Windows, GRUB on Linux) is correctly restored, whether applications start and function correctly after the restore, whether licenses are valid after the restore (some software detects a hardware change and requires reactivation), whether the network configuration is correct (IP addresses, DNS, routes), and whether dependencies on other systems (Active Directory, database server, license server) work after the restore.

All of these points can cause a BMR to fail even if the backup is technically intact. And you only find out in a real emergency -- precisely when you can least afford it.

Regulatory requirements

BSI IT-Grundschutz module CON.3 (Data Backup Concept) requires regular recovery tests, and not just at the file level. Module OPS.1.2.5 (Remote Maintenance) includes the requirement that recovery of systems after a total failure should also be tested.

ISO 27001 Annex A, Control A.8.13 (Information backup), requires that backup procedures are regularly tested to ensure that backed-up information can be restored when needed.

NIS2 requires in Article 21 measures for business continuity including backup management and disaster recovery. Evidence that you have actually tested this is significantly more convincing in an audit than a document describing how you would theoretically do it.

Preparation: what you need before the test

A BMR test requires preparation. If you discover on test day that a recovery medium is missing or the hardware is incompatible, you lose hours to troubleshooting.

Create and maintain recovery media

The recovery medium is the boot environment from which you start the restore. Depending on the backup software, there are different variants.

Veeam: The Veeam Recovery Media Creator generates a bootable ISO file that you can write to a USB drive or burn to a CD. The ISO contains a mini Linux environment (for Linux restores) or a WinPE environment (for Windows restores) with the Veeam restore agent. Update the ISO after each Veeam update to ensure the restore agent version is compatible with the backup.

Windows Server Backup: Windows Server creates a system image that can be restored via the Windows installation media using the option "Computer repair options > Troubleshoot > System Image Recovery." You therefore need the Windows Server installation ISO in the matching version.

Acronis: Acronis creates a bootable rescue media ISO via the Acronis Media Builder tool. Again: the version must match the created backup.

Linux (Restic, BorgBackup): For Linux-based backup tools, there is no integrated BMR. You must manually install the operating system, install the backup software, and then restore the data. Alternatively, use tools like Relax-and-Recover (ReaR), which is specifically designed for Linux BMR and creates bootable recovery media.

Provision target hardware

You need hardware on which to perform the restore. It does not have to be identical hardware to the original system, but there are limitations.

Physical servers: When restoring to different hardware than the original, driver issues can arise. Storage controller drivers and network card drivers in particular must match the target hardware. Veeam and Acronis offer "Universal Restore" functions that automatically adapt drivers. Still, you should have drivers for the target hardware ready.

Virtual machines: The simplest path for a BMR test. Create an empty VM with matching resources (CPU, RAM, disk) and restore the backup there. Driver problems are rare with VMs because the virtual hardware controllers are standardized.

Cloud VMs: You can also perform a BMR test in the cloud (e.g., on an Azure VM or AWS EC2 instance). This is useful if you want to verify that your cloud backup can actually be restored in the cloud.

For regular BMR tests, I recommend the virtual machine route. You do not need dedicated hardware, can run tests at any time, and simply delete the test VM afterward.

Prepare credentials

Have the following credentials ready before starting the test: credentials for the backup software (Veeam server, backup repository), encryption passwords for the backups (if encrypted), credentials for the cloud storage (if the backup target is in the cloud), and administrator passwords for the system being restored.

In a real emergency, these credentials may be unavailable because the password manager runs on a failed system. A well-thought-out emergency manual addresses this scenario. Keep an offline copy in a secure location (sealed envelope in the safe).

Prepare the network environment

The BMR test should take place in an isolated network environment to prevent the restored system from conflicting with the production system (duplicate IP addresses, duplicate computer names in Active Directory, duplicate SPN entries).

Set up an isolated VLAN or a separate virtual network. If you are testing on a local VM, a host-only network suffices. Plan a temporary network connection to the backup storage if needed, in case the restore occurs over the network.

Execution: BMR test step by step

Phase 1: Start the restore

Boot the target hardware or VM from the recovery medium. With Veeam, start the "Bare Metal Recovery Wizard," select the backup location (local, network, or cloud), and the desired recovery point.

Start the stopwatch: The clock is now running. Note the start time and measure the duration of each phase. The total duration is your Recovery Time Actual (RTA), which you will later compare with the RTO.

Connect to the backup location: Configure the network connection (IP address, proxy if needed) and connect to the backup repository. If the restore is from the cloud, measure the download speed. It is the bottleneck for restore duration.

Select the recovery point: Choose the recovery point that corresponds to the test scenario. For a realistic test, do not pick the most recent one but one that is a few days old. In a real emergency, the most recent recovery point may be compromised.

Phase 2: Execute the restore

The actual restore process is largely automated. Veeam writes the disk image to the target drive, restores the partition structure, and writes the data back.

Monitor the progress and note the speed (MB/s or GB/h). Typical values: local restore from NAS: 500 MB/s to 2 GB/s (depending on storage and network). Restore from the cloud at 100 Mbit/s connection: approx. 40 GB/h (so 1 TB in approx. 25 hours). Restore from the cloud at 1 Gbit/s connection: approx. 400 GB/h.

If the restore process is significantly slower than expected, check the network connection, storage performance, and whether the backup software is decompressing data during the restore.

Phase 3: Start and verify the system

After the restore completes, restart the system and verify that it boots correctly.

Boot check: Does the operating system start without errors? Are there blue screens (Windows) or kernel panics (Linux)? Common problems here are missing or incompatible storage drivers.

Network check: Is the network card recognized? Does the system have an IP address (you may need to configure one manually since the DHCP server may be absent in the test environment)? Can the system reach the DNS server?

Services check: Are all services configured on the system running? Check particularly database services, web servers, application services, and backup agents.

Application check: Do the applications start and function? For an ERP system: can you log in? Is data displayed correctly? Do reports work? For a database server: is the database consistent? Do integrity checks run without errors?

Data check: Is the expected data present? Does the data state match the selected recovery point? Spot-check files, database records, or configurations.

Phase 4: Document the result

Document the test thoroughly. A good test report includes the date and time of the test, the name of the tested system and the recovery point, the hardware used (target), the recovery medium and its version, the duration of each phase (preparation, restore, boot, verification), the total duration (RTA), the result (successful, partially successful, or failed), problems encountered and their solutions, and open items and actions.

Typical problems and their solutions

Driver incompatibility

The most common problem with BMR on physical hardware. The operating system does not start because the storage controller driver is missing and the system cannot find the hard drive.

Solution with Veeam: Enable "Universal Restore" and provide drivers for the target hardware (as a folder with INF files). Veeam automatically injects the drivers into the restored system.

Solution with Windows: Boot into repair mode and manually load the missing driver via the command line with dism /image:C:\ /add-driver /driver:D:\drivers\.

Prevention: Keep drivers for each potential target hardware ready and update them regularly.

UEFI/BIOS mismatch

The backup was created on a UEFI system, but the target hardware boots in legacy BIOS mode (or vice versa). The system cannot find the bootloader.

Solution: Ensure that the BIOS/UEFI setting of the target hardware matches the backup. With Veeam, the boot mode is stored in the backup metadata and can be displayed in the restore wizard.

Disk too small

The target disk is smaller than the source disk. The restore fails because the disk image does not fit.

Solution: Use the disk mapping feature of your backup software to map partitions to the smaller disk. Alternatively: enlarge the target disk. With VMs, this is trivial.

Licenses and activation

Windows detects a "hardware change" after BMR to different hardware and requires reactivation. Some applications (e.g., with dongles or hardware-bound licenses) do not work on different hardware.

Solution for Windows: OEM licenses are bound to the hardware and cannot be transferred. Volume licenses (KMS, MAK) work independently of hardware. Ensure your servers use volume licenses.

Solution for applications: Document which applications use hardware-bound licenses and what steps are required in an emergency (e.g., calling the vendor to transfer the license to new hardware).

Active Directory conflicts

When you restore a domain controller and AD is still active on other domain controllers, replication conflicts can occur. USN rollbacks are particularly dangerous and can damage the entire AD replication.

Solution: Never blindly restore a domain controller from an old backup while other DCs are still running. Follow the guidance on Active Directory hardening and instead use AD replication to promote a new DC, or perform an authoritative restore procedure.

BMR test plan: frequency and scope

Not every system needs a full BMR test every month. A tiered approach is more pragmatic.

Monthly: File restores for all backed-up systems. Quick to perform, tests basic backup integrity.

Quarterly: BMR test for one or two business-critical systems (e.g., ERP server in Q1, Active Directory in Q2, file server in Q3, database server in Q4). Rotating schedule so each critical system undergoes a BMR test at least once a year.

Semi-annually: Full DR test where the entire recovery chain is tested (not just a single system but the recovery of multiple systems in the correct sequence).

After significant changes: Whenever the backup infrastructure changes (new backup software, new repository, cloud migration), whenever the target hardware changes (new server, new storage controllers), or whenever the backed-up system changes significantly (OS upgrade, new applications).

BMR in virtual environments

In virtualized environments (VMware, Hyper-V, Proxmox), BMR is simpler and more reliable than on physical hardware because the hardware abstraction layer of virtualization eliminates driver problems.

Veeam Instant VM Recovery

Veeam offers a particularly elegant solution: Instant VM Recovery. The VM is started directly from the backup without first copying the data to storage. This saves enormous time: instead of hours for the restore, it takes minutes for the VM to be running. Performance is limited (the VM reads directly from the backup), but for a test or emergency bridge, it is sufficient.

Afterward, you can migrate the VM to production storage in the background (Storage vMotion for VMware or Live Migration for Hyper-V) without downtime.

Proxmox Backup Server

Proxmox Backup Server also supports BMR of Proxmox VMs. The restore occurs via the Proxmox web interface: select VM, choose recovery point, start restore. The VM is restored on the Proxmox cluster and can be started.

Documenting a BMR test: template

A structured test report might include the following sections:

Header data: Test date, test number, tester, system, backup timestamp, backup location.

Preparation: Recovery medium checked (yes/no, version), target hardware prepared (description), credentials available (yes/no), network environment isolated (yes/no).

Execution: Start time, restore duration, boot result, services status, application test, data verification.

Result: RTA (measured), RTO (defined), deviation, overall assessment (pass/fail).

Findings: Problems encountered, causes, corrective actions taken.

Actions: Open items, responsible persons, deadlines.

This documentation is your evidence for audits and the raw material for continuously improving your recovery processes. In ISMS Lite, BMR test reports can be captured in a structured format and deviations between RTO and RTA systematically tracked.

From test to routine

BMR tests feel labor-intensive at first. The first test takes an entire day because you find and solve problems you did not expect. The second test goes faster because you have already addressed the known pitfalls. By the third or fourth test, it becomes routine: provision recovery medium, prepare VM, start restore, verify, document. Two to four hours per system.

Shying away from this effort is understandable; bearing it is essential. One BMR test per quarter for your most critical systems is an investment of a few workdays per year that makes the difference between a controlled restart and a chaotic total failure in an emergency.

Bare-Metal-Recovery Backup Restore-Test Disaster Recovery BCM Veeam ISMS