Testing failover systems and backups has always been a touchy subject that most administrators would rather sweep under the rug. The whole idea behind a failover system is that if the primary component fails, the secondary system should automatically engage. Theoretically, this means you should be able to just pull the plug on the primary system and watch the secondary system instantly take over. Even so, we all know that things don’t always work the way they’re supposed to, and it takes a lot of nerve to pull the plug on a healthy production server in hopes that the failover system will work correctly.

If you’re an adrenaline junkie, the pull-the-plug-and-pray technique might be just what the doctor ordered. For the rest of us, I recommend taking a more controlled approach to testing failover systems. Unfortunately, I can’t give you an exact technique because everyone’s network configuration is different. But I’ll share some recommendations that should help most people.

Backup and restore capabilities

When it comes to testing failover systems, I recommend starting out by testing your backup and restore capabilities. After all, can you imagine what would happen if you accidentally trashed a server during your testing, and then found out that your backup was invalid and therefore couldn’t be restored? The idea sounds farfetched, but I’ve seen it happen on more than one occasion.

The easiest way to test your backups is to get your hands on a spare server that isn’t connected to the network. Install a tape drive into the server, and you’ll be able to experiment with restoring backups without having to worry about putting duplicate server names or duplicate IP addresses onto the network.

As you experiment with restoring backups, there are a few things you need to keep in mind. First, if you’re restoring the operating system as part of your test, Windows may not boot if the hardware on your test server is different from the hardware on the corresponding production server. It might be necessary to restore the backup and then manually install Windows on top of the restored copy just to get the server to boot. [Continue…] [Brien M. Posey, MCSE]