Backing Up IIS: A Primer

Recover from system failures quickly and efficiently

You can find many articles about managing and configuring IIS and its metabase. However, a lot of confusion and misconceptions still exist about one of the most important aspects of managing IIS—generating a good backup. This month, I introduce you to the fundamentals of properly backing up and restoring IIS, including pitfalls, gotchas, and some tricks to remember. I show you how to back up

Backing Up the Entire System
To back up your IIS machine, you can use Windows NT backup procedures or a third-party backup program to generate a full-system backup. This type of backup will ensure that you have all the data necessary to rebuild a system from a catastrophic failure. The Microsoft Windows 2000 Server Operations Guide, which is part of the Microsoft Windows 2000 Server Resource Kit, provides excellent information about backing up your Win2K system. The Backup chapter of the Windows 2000 Resource Kits Web site (http://www.microsoft.com/windows 2000/techinfo/reskit/en-us/core/fndf_ bkp_qale.asp) also provides useful information. For information about backing up NT 4.0, read Chapter 4 of the Microsoft Windows NT Server Resource Guide, which is part of the Microsoft Windows NT Server 4.0 Resource Kit.

A full-system backup takes more time and resources than simply backing up the metabase, but it ensures that you have all the information you need. It's also the best way to guarantee that you can recover from a fatal crash. Of all the backup processes I talk about in this article, the full-system backup does the most to safeguard your Web server. Before you perform a full-system backup, be sure to stop the Web services so that all related files are released and will be successfully backed up.

Restoring the Entire System
If your Web server suffers a fatal crash or you need to rebuild a system, you can easily use the full backup you made to do so. However, here's one caveat to remember when restoring a Win2K system. Win2K restores only to the currently active registry, which means that the drive and system root must be the same as when you made the backup. In other words, you can't perform a parallel installation and be running that instance of Windows when you restore the system. If you made the backup with C:winnt as your system root, you need to rebuild the crashed system to the point at which you can boot into C:winnt before you perform the restore. This consideration isn't applicable to NT 4.0 because the registry is just a file in that OS. But I still recommend that you run restore only from the directory to which you were planning to restore.

Backing Up the Metabase
After you have a full-system backup in place, you can make periodic backups of just the IIS metabase. (For more information about the IIS metabase, see William Sheldon, "Getting to Know the Metabase," January 2001, InstantDoc ID 16179; "Getting to Edit the Metabase," February 2001, InstantDoc ID 16462; and "Getting to Script the Metabase," April 2001, InstantDoc ID 20058.) Backing up the metabase in IIS 5.0 is fairly easy, and you should back it up any time you make a change to your IIS settings.

Backing up the IIS 5.0 metabase. To back up the metabase in IIS 5.0, open Internet Services Manager (ISM). Right-click your computer name, then select Backup/Restore Configuration. In the Configuration Backup/Restore dialog box, which Figure 1 shows, click Create backup, then type a name for the backup file. (Note that the backup software prohibits any special characters in the name.) Click OK. You've now backed up the metabase for this machine. For more information about backing up the IIS 5.0 metabase, see the Microsoft article "HOW TO: Create a Metabase Backup By Using IIS 5" (http://support.microsoft.com/support/ kb/articles/q300/6/72.asp). For a Windows Script Host (WSH) script that you can use to back up the IIS 5.0 metabase as a scheduled task, see the Microsoft article "HOW TO: Schedule Metabase Backups Using WSH" (http://support.microsoft.com/support/kb/articles/q302/8/88.asp).

Backing up the IIS 4.0 metabase. In IIS 4.0, the metabase-backup process is the same as in IIS 5.0, but it's not as reliable and you might not get a good copy of the backup file. For backing up the metabase on an IIS 4.0 machine, I recommend that you use a full-system backup. If such a backup isn't an option, you might be able to make a manual copy of the metabase. To do so, stop all Web services manually on your production IIS machine by typing

net stop iisadmin /y

at a command prompt. Then, copy the metabase.bin file and rename it metabase.bak. For security purposes, you might want to store metabase .bak on another machine or medium. However, you can keep a local copy, too.

Restoring the Metabase
To restore the IIS 5.0 metabase copy that you made, open ISM, right-click your IIS machine, then select Backup/ Restore Configuration. In the Configuration Backup/Restore dialog box, highlight the configuration you want to restore, then choose Restore to stop IIS, restore the configuration, and restart IIS.

When you use the built-in metabase backup-and-restore functionality, be aware that you can't use the backup you created to restore a newly built machine or to migrate the metabase to another machine. Therefore, this type of backup isn't suitable for use in disaster recovery or replication. Its best use is to protect against administrative errors and for restoration during upgrades.

If you used the full-system backup process to back up your IIS metabase and a change corrupts the metabase .bin file on your production Web server, you can simply shut down the server and copy metabase.bak back into metabase.bin. For more information about restoring the IIS metabase from a full-system backup, see the Microsoft article "How to Manually Restore the Metabase When No Proper Backup Exists or the MMC Won't Start" (http://support.microsoft.com/support/kb/articles/q234/4/29.asp).

Backing Up the Data
A data backup can be as simple as copying to another location the files in the directories to which your Web site configuration points. For example, if you have one Web site on your machine and its root points to D:inetpubwwwroot, you can copy wwwroot and all its subdirectories to another drive or machine.

Be aware, however, that you also need to copy any other directories that might contain data. For example, the FTP root might be under D:inetpubftproot, and you might have a virtual directory in IIS that points to E:special_stuff. You'd need to make copies of these directories as well.

The benefit of generating data copies is that these copies let you access your data either for removal to another machine or for archival purposes. Usually, data backup is a good practice with Web servers that don't host many sites. However, if you have a lot of sites with data in many different locations, generating a data backup might not be easy.

Restoring data that you've copied to another location is as simple as copying the data to whatever system you want to use and configuring IIS to point to the restored data. The caveat is that you can't copy configuration information. Therefore, you need to set IIS up to point to the data, set up any ODBC connections you might have used, and possibly rebuild your permissions on parts of the data that need to be restricted.

If you're using Microsoft FrontPage Server Extensions, you can copy the proper data directories, but you'll still need to run the FrontPage Manager to have the program clean itself up and activate the server extensions. For more information about configuring server extensions to work with IIS 5.0, see the Microsoft article "HOW TO: Configure IIS with FrontPage Server Extensions" (http://support.microsoft.com/support/kb/articles/q298/1/58.asp).

Backing Up Security Information
Security information consists of IIS server certificates, client-certificate mapping information, IIS user accounts, resource permissions, IIS configuration settings, COM or Microsoft Transaction Server (MTS) package identity accounts, and Distributed COM (DCOM) configuration information. This information resides in many different locations and isn't easy to back up or restore without performing a complete system backup. For this reason, I recommend that you use complete system backups to protect your IIS servers and to prepare for disaster recovery. However, you should still keep records of how you've configured your servers so that if you want to build a new machine or something happens to your backup, you can still reconfigure your system manually. Make notes about the permissions you've set and the accounts you're using for IIS and COM identities. (Don't include any passwords in these notes. You don't want that information to be gaccessible to anyone who might get access to your log book.)

Backing up server certificates. If you have server certificates on your Web server, you can back them up manually. Note that backing up server certificates results in a private-key backup that's easy to decrypt. (The backup has a base64 encoding, which many shareware programs can easily crack.) Therefore, you must ensure that your backup storage is secure. For example, if you back up your certificates to a disk, be sure to lock the disk in a safe or another secure location. One common misconception about backing up server certificates is that you can use the certificate-request key and the certificate you received from your Certificate Authority (CA) as your backup. Unfortunately, this keyset (as it's commonly referred to) isn't complete. When you create a certificate-request key, the private portion of the key is generated and stored in the secure portion of the Windows registry. This key portion is never placed in the request file or sent to the CA. Therefore, if you use only the keyset as your backup, you're missing the private key.

To back up a full IIS server certificate, you need to export the private-key and public-key information as well as remember the password that was assigned to the certificate key when it was created. You'll need this information to restore the backup in the future. To back up a certificate in IIS 5.0, follow the steps in the Microsoft article "How to Back Up an Internet Information Services 5.0 Server Certificate" (http://support.micro soft.com/support/kb/articles/q232/ 1/36.asp). To back up a server certificate in IIS 4.0, follow these steps:

Restoring server certificates. To restore a server certificate that you previously backed up on an IIS 5.0 machine, follow the steps in the Microsoft article "How to Import a Server Certificate for Use in Internet Information Services 5.0" (http://support.microsoft.com/support/kb/articles/q232/1/37.asp). To restore a certificate in IIS 4.0, follow these steps:

Diligence Is Key
This month, I've discussed different methods for backing up your Web servers, each of which has advantages and disadvantages. You can find another useful resource for backing up your IIS 5.0 machines at http://www .microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ iis/maintain/featusability/c02iis.asp (click the Configuring IIS Backup and Recovery link). Of course, you can take other steps to protect your server. For example, I run two different hard disks in my Web server and set them up as an NT mirror set. That way, I always have a redundant copy of my Web server.

The most important steps you can take to ensure the safety of your Web server are to properly plan your strategy, design your server's hardware and maintenance according to that server's needs, and diligently make backups and keep good records of changes and updates. Next month, I'll get back to debugging IIS. I'll show you how to address high CPU utilization problems.