This is my fourth excerpt from my The 7 Deadly Sins of Backup and Recovery whitepaper. Download the full whitepaper for instant gratification.

We think of laptops, desktops and servers as nearly universal devices, and we often don’t consider the risks and complexities of moving software and data between different brands or models.  Also, we often assume that if we have a failure and need to shift to new hardware, we’ll be able to quickly acquire whatever we need.

However, those who have tried know that incompatibilities often arise when moving to a new platform—even one that’s nominally fully compatible with whatever came before.

System driver, application and patch complexities and incompatibilities can undermine the best laid plans. It is critical for IT professionals to think about these issues and plan for realistic restoration choices in the event of a disaster.

The following are three popular restoration practices:

  1. Bare metal recovery (aka dissimilar restoration); asserts that backups taken from one hardware manufacturer can be restored to a server from a different manufacturer.  This often works in the lab but fails to work in the real world.  Each component needs to be tested in your own operating environment to ensure success in the event of a disaster.
  2. Dislike to known restoration; refers to the ability to do a bare metal restoration to a pre-defined set of destination hardware devices different from the original device.  This works reliably because drivers for those devices are already embedded in the backups themselves.
  3. Use restoration software to provide chance to load drivers early in bare metal restoration process; This expands the range of destination hardware devices that can be used by allowing the IT professional to supply the necessary drivers without them having to have the drivers selected months in advance.

Without the ability to perform a successful bare metal restoration, the user must build the entire new system first by loading the operating system, applications and then data—just as in the case of a data-only tape restoration.  This is clearly not desirable.  In a true disaster, time is of the essence, and a full rebuild like this wastes precious time…in many cases, days.

Today’s careful planners will catalog all of their hardware and operating system environments in advance, including:

  • What current machines are available from their preferred manufacturers
  • How today’s generations of machines are different from the generation currently in use
  • Advanced identification of replacement sources for the servers in use and documentation of what will be ordered in the event of a disaster
  • Confirmation that their “dislike to known” hardware models are supported by their bare metal software technology
  • Duplicate CDs of all necessary drivers, both stored on-site and at an off-site disaster recovery location
  • Testing to be sure that all of their company’s software technology—and all of the hours that were spent making backups—lead to a successful restoration in the event of a disaster.