Backing Up and Restoring IIS Servers

As a consultant, I see a vast array of server setups, backup schemes, and disaster-recovery plans. Most of these plans don't include solid IIS recovery plans. When someone talks to you about disaster recovery, you usually hear the worst-case-scenario sale pitch: A fire in the building, a flood, or a bomb could easily take out your whole operation. Although such large-scale disasters do happen, chances are greater that a hard disk will die, data will be corrupted, or some configuration change will backfire on you. I show you how to develop a solid recovery plan for your IIS servers.

Building a Vision
When you build an IIS server (or any server), make sure that you build it solidly. In general, quality parts equal a quality final product. Here's a checklist for IIS installation:

Obviously, this process requires a lot of work. However, this process can also save you a lot of time if you need to perform a disaster recovery. No quick and dirty ways exist yet for getting all this information. For now, IIS documentation is up to you.

Getting Started
To begin your IIS disaster-recovery plan, start with hardware. Which server machine are you using? Which type of CPU does the server use and what's its speed? Does the server have single or dual processors? Step through every aspect of the machine and see where you stand; document everything as you move along.

The most important and overlooked item in a disaster-recovery plan is backup routines. If you have such routines in place, the next step is offsite storage. If you already have tape backups, when was the last time you tested them? Pretend that tomorrow you go into work and someone has stolen your Web server. Try to get your site back up and running by using only your backup tapes. Set up a server and restore all your data. Practicing this routine gives you a good idea about not only whether your tapes are complete but also how well you've documented all the components you need to set up on your server.

Determining which hotfixes you've applied can be tricky. Luckily, a simple way exists for tracking what has changed. As long as you opted for uninstall functionality (which most hotfixes now have), you'll see folders with names that begin with $NtuninstallQxxxxxx$ in your %systemroot% folder. Using the Q numbers, you can look up which hotfixes you've applied by accessing Microsoft's online Knowledge Base. For IIS 5.0 administrators, Microsoft has a new proactive tool that checks which hotfixes you've installed. (The Windows 2000 IIS 5.0 Hotfix Checking Tool is available for download from http://www.microsoft.com/downloads/release.asp?releaseid=24168.) This tool is great for seeing what your system might be vulnerable to and assessing your risk before you install anything. You can also use the tool remotely to check other IIS servers on your network.

A Simple Plan
Three items on my list can save you in the case of a true failure. First, the metabase is the key to IIS's configuration. If you don't back up your metabase, you'll have to recreate your IIS configuration. In "Getting to Know the Metabase," January 2001, William Sheldon detailed backing up the IIS metabase. I highly recommend that you read this article to get an idea about what's in your metabase and why you need to protect it.

Second, developers sometimes specifically choose ODBC drivers for particular features or for compatibility with the databases they're using. If your site isn't database driven, you can skip this step. If your site is database driven, document which data sources you use and their drivers; either back up the drivers or have the driver installers handy and backed up to tape.

Finally, a change-management system of some sort must be in place. Think of the system as your version control. Even if all you have is a three-ring binder on the shelf next to the servers, this information should be part of your procedure: Anytime someone accesses the computer to make changes, that person must write down what he or she did.

Recovery plans can range from having another set of servers offsite to having vendors able to ship you new equipment overnight. If a server goes down and your disaster-recovery process goes as planned, you could be up and running again in a few hours. However, things don't always go as planned. You need this level of preparedness to be ready for an emergency. In other words, when your Plan A fails, you'd better have a Plan B ready to go.