This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
4. - Be prepared when big trouble comes knocking: Read more in this section
- Creating a VMware disaster recovery plan
- Improving business continuity via a virtual disaster recovery strategy
- Building a remote VMware disaster recovery site
- VMware disaster recovery strategy for small environments
- What you need to know about bare-metal recovery
- VMware vSphere Replication breaks disaster recovery storage barriers
Explore other sections in this guide:
- 1. - The best approaches for virtual machine backup and virtual recovery
- 2. - Using snapshots to defend and resurrect your virtual machines
- 3. - Switch virtual recovery efforts to autopilot with vCenter Site Recovery Manager
What do you need to know about bare-metal recovery, and what are your options? Marc Staimer, founder of Dragon Slayer Consulting, speaks with SearchDisasterRecovery.com Assistant Editor John Hilliard about the differences between a bare-metal recovery and a typical restore, the variety of bare-metal recovery options today, and how to test a bare-metal restore.
Download for later:
- Internet Explorer: Right Click > Save Target As
- Firefox: Right Click > Save Link As
What’s the difference between bare-metal recovery and restoring from a local disk image?
There’s a lot of misconception about what bare-metal restore is. People tend to misuse the term. There’s a huge difference between booting an image that is on an external storage system somewhere, versus recovering and restoring a server from scratch. And so, bare-metal recovery means: “I’m going to take a machine that has no software on it whatsoever, and bring it to the state that the initial server was in before it crashed.”
The problem with bare-metal restores generally speaking is if the hardware is not identical -- and I mean, down to the manufacturer, microcode, BIOS, everything -- it will not come out cleanly. And there are some vendors that do a pretty good job at stripping out old drivers and old microcode, but injecting the right ones can take time. And troubleshooting that takes time. It’s usually better to load the OS and do a state-level restore -- it almost always takes less time than a bare metal restore -- which is why more people have gone to boot from external storage.
And the reason you do a boot from external storage is that the driver issue will still exist until a point, but not nearly as much, and you can have more dissimilar hardware. But it's not just booting up physical machines from an image of a machine that failed onto a different hardware platform. Now there is a movement toward a more physical-to-virtual kind of boot. So there are tools that are within VMware ESX that allow you to convert a physical image to a virtual image. If the physical machine the image was taken from crashes, you can bring it up as a virtual machine on a different platform almost immediately. That’s what people are really looking to do, without having to troubleshoot (drivers and network connections).
Let’s talk about some of the different forms of bare-metal restore -- physical to physical, virtual to virtual, physical to virtual and virtual to physical. What are they, and do the different forms work better with different kinds of users or kinds of data?
For physical-to-virtual, you have to convert the physical image to a virtual one. In general, once you have it in a virtual image, it’s very simple to not restore but bring it up, so you’re up and running that much faster. The other is virtual-to-virtual booting, which is also very popular. Now, the one thing to bear in mind is most virtual servers require shared storage to use any of these advanced features. So it’s built into the hypervisor to be able to do this. As far as bringing up a virtual image, if a machine running a virtual image crashes, it’s very simple to bring it up on another machine. As far as the physical-to-virtual, it’s very simple to do on the shared storage. It’s not necessarily a requirement to do this with backup software. But there are a number of backup software products that will do this as well.
Again, I want to be clear on what a bare-metal restore is. Bare-metal restore is taking a physical machine that has crashed, and bringing it up on another physical machine. By the very name -- bare-metal recovery -- it makes it clear. Anything else is a remote boot or a separate boot from a shared storage system. Whether it would be a virtual shared storage system, such as a backup device, or whether it would be a SAN or NAS storage system. So, keep that in mind. So you have the physical-to-physical bare-metal recovery, you got the physical-to-virtual remote boot, you got the virtual-to-virtual remote boot. There’s one more, called virtual-to-physical. That’s a little bit different, that’s almost always simpler than physical-to-physical, so that’s a variation of a bare-metal restore, although very few people tend to use that technology. Typically, once you go virtual, you don’t go back to physical, but there are times that you do.
Typically, physical-to-virtual and virtual-to-virtual are the best of the four. Those are the types of things that can make your life a lot easier. And those will work with shared storage, or software that runs as a backup, or backup appliance or replication appliance that will enable you to boot those images (remotely) and bring it up and be able to operate.
How can you test to see if a bare-metal restore will actually work?
You can test it easily. Basically, just boot up a physical server -- let’s say backup for the sake of argument. And then, you want to run the VM -- the virtual image of it -- from another physical machine. It’s not that hard to do. It’s a very simple test. Virtual-to-virtual is even a simpler test. And you can do it both locally and remotely... meaning over a wide area network. It’s a simple test to do. It doesn’t take a lot of effort. It takes a little time, but not a lot of effort.