Backing Up IIS: A Primer

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:\inetpub\wwwroot, 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:\inetpub\ftproot, 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.

   Previous  1  [2]  3  Next