Business Recovery, Step 7: Bare Metal Recovery
We’re nearly at the end of this series of articles covering the ways you can improve business recovery, while increasing your service revenue. I’ve covered a number of ways to recover entire machines using virtualization as both a platform for disaster recovery, for continuous recovery, and in cases where going virtual to virtual makes sense.
While virtualization plays a dominant role in the infrastructure for many of your customers, some still have specific servers still running on dedicated physical hardware. This is usually due to reasons of server or disk performance. So if one of these physical servers goes down, your customer may not be willing to take advantage of your virtualization-based recovery options. Instead, they want the physical server to be recovered as is.
A server this critical needs to be thought of not in terms of files, or an application data set, but in terms of the server as a whole. That’s where Bare Metal Recovery (BMR) starts – with the idea that you’re going to recover the entire server with only a “bare metal” system (that is, the server hardware, but no OS, applications, nothing) to begin with.
Growing Revenue from the Bare Metal.
While I’ve focused BMR on critical servers, many of you have smaller customers with just a few physical servers where BMR may be a good fit. The reason is the “disaster” may just be failed hardware. And those small clients may simply want you to buy new hardware and recover the server rather than go the route of virtualization.
To make BMR successful, you’re going to do a few things you’re used to, and backup some data you may not be used to.
- Define the Objectives – Since the goal is to get an entire server running from nothing but a fresh server out of the box, and that server likely provides multiple services and applications (each with their own recovery objectives), you need to define an overall recovery time objective and recovery point objective for the server that meets the recovery needs of the applications and services it runs.
- Backup Down to the Metal – When you use a modern-day backup system to, say, backup Exchange, it simply backs up every data set Exchange needs to be recovered, but it doesn’t necessarily backup the OS. You’re going to need to backup the entire server, including (in the case of Windows) the System State. The System State can include the registry, COM+ databases, AD, the SysVol, Certificate Services, and the IIS metabase (all depending on what you have installed on that Windows server). Remember, the data included in the System State changes daily as well, so this isn’t a “do it monthly” kind of backup. It’s as important as the applications and data running on this server.
- Hardware to Recover to - Lastly, it’s important to note that the hardware doesn’t need to be an exact match, but it does need to be similar.
What’s the benefit?
- Recurring Backup Revenue – assuming you’re offering cloud-based backups, you’re charging per GB. In order to recover an entire server, complete with System State, you’re going to need more storage space than, say, just backing up one application, raising the monthly revenue for maintaining backups. Also, keep in mind that those critical physical servers will have very restrictive RTOs and RPOs, which also increases backup frequency, which in turn increases storage needed.
- Services Revenue – you do need to test the recover periodically, to ensure you have everything in a backup needed to perform a BMR.
- Fully Functional Servers – This is huge for the customer – providing them the ability to have a server completely recovered and functional without the traditional “I restored everything, so it should work” makes you look good, and gets your customer’s operations humming again quickly.
In the next article (the last in this series), I’m going to take all the recovery methods I’ve covered over these seven articles, and discuss the methodology, frequency, and opportunities within recovery testing.