BMR: Broken Servers, Broken Promises, Broken Hearts
Nobody was expecting a truck-shaped hole in your office when you came in to work this morning. But there it is, minus the truck that failed to negotiate a turn (but succeeded at using your primary server as a speed bump).
Fortunately you’re on point with your backups, and as Facilities gets the hole covered, you get ready to bring the server back to life. You’ve got your server images all set to go, and a spare server to put them on. It’s not quite the same as the server that’s now chunks embedded in the floor, but you’ve got a bare metal solution so it shouldn’t be a problem. You boot it up….except it doesn’t boot.
Congratulations, you’ve just hit the “*” on “Bare Metal Restore to any server*.”
Bare metal restores are a great idea. Save a server image backup, then restore it to any hardware after a disaster, even hardware dissimilar to what you had before. If it actually worked as promised, it’d be brilliant. Unfortunately, that’s not the usual experience.
The problem with trying to restore to dissimilar hardware is that it’s, well, dissimilar. If you’re trying to graft a server image onto a different machine, there are going to be different drivers, etc that can shut it down faster than a high school party next to a police station.
Traditional bare metal solutions have used their own third-party OS to try to bridge the gap – the idea being that you can load the image, the BMR solution will detect what needs to be fixed in order to get the image going, and then do it. But this is easier said than done, and despite vendors’ best efforts trying to prevent every possible issue is kind of like patching a dam built from Swiss cheese. There’s more hole than cheese.
So is there a way to do Bare Metal Restore that doesn’t end in heartbreak and recriminations? Or is the entire concept a lost cause?
Check back Monday at zetta.net for a BMR breakthrough.