Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Dmytro Koval
What a bare metal restore rebuilds from an empty disk, how it differs from file, system state and image restores, the four hardware mismatches that stop it booting, where it fits in a DR plan and a six-gate test to run before you need it.
A server's RAID controller dies on a Tuesday, the replacement box arrives Thursday, and the backups have been green for a year. Whether that server is back by Friday depends on one restore type a green backup job tells you nothing about. This guide explains what a bare metal restore rebuilds, why it fails on different hardware, where it fits in a DR plan and how to test one before you need it.
A bare metal restore (BMR) takes a machine with nothing on its disk and puts the whole system back: partitions, boot files, Windows, drivers, applications, settings and data, in one pass. "Bare metal" is the target, not the backup. The restore starts from boot media, because there is no operating system on the box to start from.
Microsoft's bare metal recovery doc lists the sequence for Windows: identify the system disk, remove every partition on it, recreate the partition layout, format, lay down the OS, inject drivers, write the boot files, reboot. That is the shape of every BMR, whatever tool runs it.
Three other restore types sit below it, and the difference is what has to exist before each one can run. A file restore needs a running OS and brings back documents. A system state restore needs a running OS and brings back the registry, boot files and, on a domain controller, Active Directory. A volume or image restore brings back a whole disk but still assumes something can boot the machine. A bare metal restore assumes nothing.
The backup has to be built for it. Windows Server Backup only produces a BMR-capable backup when the job includes every critical volume. The switch is wbadmin start backup -allCritical -backupTarget:E:, and wbadmin get versions shows "Can recover: Bare Metal Recovery" on a backup that qualifies. Veeam Agent calls the equivalent "Entire computer" mode. A file-level backup of C:\Users cannot become a bare metal restore later, however complete it looks.
The classic BMR assumes the new box matches the old one. The moment it doesn't, four mismatches decide whether Windows boots.
Storage and network drivers. The restored image carries the drivers for the old controller and NIC. If the new machine's storage controller is not in that set, Windows reaches the boot volume and stops with INACCESSIBLE_BOOT_DEVICE or a kernel bluescreen. Quest's driver injection guidance puts it plainly: inject Ethernet, storage and network drivers into the boot image, and expect to need it when restoring to dissimilar Windows hardware. Linux restores usually skip this step because the kernel ships the drivers inline.
Firmware mode. An image captured from a UEFI machine with a GPT disk will not boot on a target set to legacy BIOS with MBR, and the reverse is also true. Check the firmware mode on the target before you boot the recovery media, not after the restore reports success.
Disk size and layout. Veeam's restore mode doc states that "Entire computer" and "System volumes only" fail when the target disks have no room for the backed-up volumes, and the wizard drops you into manual mode to map and shrink volumes yourself. A 4 TB RAID6 image onto a 2 TB RAID1 is a manual restore from the start.
The RAID controller itself. The recovery environment has to see the array before anything else matters. Veeam's disk mapping step has a Load driver option for exactly this case, where you point it at an INF file from the controller vendor.
The practitioner reports on this are consistent. In the r/Veeam thread below, a Windows 11 image from a nine-year-old NUC bluescreened on a new one with a different stop code each boot, with and without driver injection. The replies landed on the hardware gap and missing storage drivers:
Vendors sell the fix under names like "universal restore" or "hardware independent restore". It is driver injection with a catalog behind it, and it works when the catalog has your controller. When it doesn't, the fallback is older than the feature: install Windows clean on the new hardware, then do a file restore of the data. Slower, boring, and it boots.
BMR is the slowest recovery path a modern backup tool offers, and that is the point: it is the one that still works when every faster path is gone. The faster paths need something to exist first. A file restore needs the server running. Instant recovery, where Veeam, Datto or Axcient boot the backup as a VM, needs a hypervisor with spare capacity. A bare metal restore needs a box and a USB stick.
That ordering is why the r/msp answer to "how should we do bare metal backups" is usually "don't run bare metal". Make every physical server a hypervisor host, back up the VMs, and a hardware failure becomes a VM restore onto whatever host is alive. The exception is the server with physical dependencies: a license dongle, a PCIe card for a dental imaging rig, a controller the app vendor supports only on metal. Those boxes keep a BMR-capable backup because there is no VM path for them.
The numbers on recovery say the plan matters more than the tool. Sophos' State of Ransomware 2025 survey of 3,400 IT and security leaders found 53% of victims recovered within a week, up from 35% in 2024, while recovery through backups hit its lowest rate in six years. Veeam's 2025 Ransomware Trends report, across 1,300 organizations, found only 10% of those attacked recovered more than 90% of their data. Both reports point the same way: the backups existed, the restore path did not.
So the BMR line in a data backup plan is short. List the physical servers that cannot be virtualized. Confirm each one has an image backup with all critical volumes. Keep current recovery media for each, built on that machine's hardware. Record the firmware mode, disk layout and controller model next to the backup job, so the day the server dies you are not discovering them from a dead box.
A bare metal restore that has never been run is a hypothesis. The test is cheap because you do not need spare hardware: restore the image into an isolated VM on Hyper-V or Proxmox with the network disconnected, and watch what happens on first boot.
What happens on first boot is the whole test. In the r/sysadmin thread below, a technician restored a physical Server 2022 domain controller from a Veeam "entire computer" backup into an isolated Hyper-V VM. It bluescreened on CRITICAL_SERVICE_FAILED until CHKDSK from WinRE repaired the filesystem, and the production server turned out to have a dirty volume flag nobody had noticed. The restore found a problem the green backup job had been copying for months:
That thread is the normal case, not the exception. A backup job reports on the copy it made, never on whether the copy boots, so a year of green runs tells you nothing about restore day:
Run the test in six steps and write down each result:
wbadmin get versions should show "Can recover: Bare Metal Recovery"; in Veeam, the restore point should offer "Entire computer".Veeam's own walkthrough of the Agent for Windows recovery media is the fastest way to see the wizard before you run it:
Do the test once per physical server per year, and again after any hardware or firmware change. The same test, with the same checklist, is the BMR line item in a wider DR testing program. OpenFrame keeps a device inventory per client, so the model and disk details of the machine you are replacing are on record before the restore day arrives.
A bare metal restore is the recovery path for a machine with nothing on it, and it only works from an image backup that includes every critical volume. It breaks on different hardware for four predictable reasons, and driver injection fixes most of them when the catalog has your controller. Keep it for the physical servers you cannot virtualize, and run it into an isolated VM once a year so the first time you see the restore wizard is not the day the controller dies.
Next, read how disk imaging captures the image a BMR depends on, and how immutable backups keep that image safe from the ransomware that makes you need it.
Head of Product Engineering
Hi! My name is Dmytro, but everyone calls me Dima. I’m a Software Developer and together with the development team, I help bring Flamingo to life — putting it on its feet from a technical perspective. Originally from Lviv, Ukraine 🇺🇦, but currently based in Spain, where I’ve been enjoying the blend of great weather, culture, and nature. I’m passionate about the mountains and love traveling — exploring new places and cultures really inspires me. These experiences constantly recharge me and give me a fresh perspective, both personally and professionally.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.