Our latest DR test cycle — see Why Every Disaster Recovery Plan Needs Regular Testing — put NetBackup BMR(Bare Metal Restore) to an actual test: restoring one of our physical production database servers as a virtual machine instead of back onto identical hardware. That’s the more realistic scenario: if that physical box fails for good, we’re not sourcing an identical replacement on short notice. We’re rebuilding it as a VM.
The actual data restore took about an hour. Getting to a system that would boot took most of a day. That gap is the whole story.
A BMR Image Isn’t the Same Thing as a Backup
The regular NetBackup jobs on this server had been completing successfully the entire time — but a standard backup job protects the server’s data, not its ability to come back up as a bootable system. A Bare Metal Restore image is a separate artifact that has to be generated on its own, and it hadn’t been. Nothing was wrong with the backups; the piece we actually needed for this test simply didn’t exist yet. We had to build it before the restore could even start.
The VM Wouldn’t Boot
Once the image existed and the restore ran onto a new VM, the restore itself completed without errors. The VM just wouldn’t come up afterward.
The likely cause was the gap between the physical server’s original hardware and driver context — carried over in the BMR image — and the VM’s default virtual hardware, particularly around the network adapter. Windows wasn’t initializing cleanly during boot, and the system never got past that point.
Fixing it wasn’t a single change. It took a few rounds of adjusting the VM’s virtual hardware configuration, restoring again, and checking whether it booted, before we landed on a configuration that worked.
Where the Time Actually Went
- BMR recovery image: didn’t exist, had to be generated first
- First boot attempt: failed
- Diagnosing the hardware/driver mismatch and reconfiguring the VM: most of a day
- Data restore once the VM booted: about an hour
If we’d only measured “how long did the restore take,” we’d have called this a fast, clean test. The restore step was never the problem. Getting to a bootable system was.
What This Means for RTO
An RTO built only around “how long does the data restore take” would have badly undersold this recovery. The image-generation gap and the boot troubleshooting are exactly the kind of work that happens in the middle of a real incident if nobody’s caught it beforehand — and neither one shows up if you only time the restore step.
What We Changed
- BMR image generation is now its own checklist item, tracked separately from confirming the regular backup job succeeded. A healthy backup job doesn’t tell you whether a bootable recovery image exists.
- We’re documenting the virtual hardware configuration that gets this server’s BMR image to boot cleanly as a VM, so the next person isn’t rediscovering it from scratch.
- Physical-to-virtual boot testing now happens ahead of the scheduled DR window, not live during it — the goal is to find this kind of problem on our own schedule, not the DR test’s.
- We’re defining what “recovered” means beyond “it booted and the data’s there” — for a database server specifically, that should include confirming the service starts cleanly and the data is actually usable, not just that Windows comes up.
The Lesson
Backup and recovery aren’t the same problem. The data on this server was never at risk — NetBackup had it the whole time. What wasn’t ready was the path from “we have the data” to “this server is usable again,” and for a physical server being rebuilt as a VM, that path runs through image generation and hardware compatibility before it ever gets to the actual data.
Frequently Asked Questions
Why wouldn’t a NetBackup BMR restore boot as a VM?
A likely cause is a mismatch between the driver and hardware context carried over from the original physical server and the VM’s default virtual hardware — the network adapter is a common culprit. Adjusting the VM’s virtual hardware configuration before boot, or making sure the correct drivers are available to the restored system, is usually what resolves it.
Do you need a separate BMR image if your regular backups are already working?
Yes. A standard backup job protects the server’s data. A bootable Bare Metal Restore image is a distinct artifact that has to be generated separately, and its existence isn’t implied by a healthy backup job.
Related reading:
- This restore was one test within the same DR testing cadence covered in Why Every Disaster Recovery Plan Needs Regular Testing.
- This turned out to be one of three backup mistakes I keep seeing — I rounded up the pattern along with two other incidents.