You can use many methods to increase data availability for systems running Windows 2000 Server, including clustering, replication, and various RAID implementations. However, a fail-safe backup strategy is still the ultimate safety net to ensure that you can recover data after a catastrophic event. Countless books and articles outline the details of planning backup schedules, media rotation, and offsite storage for an effective backup program. But you might not know how to use your backed-up data to recover your Win2K server. With some clear direction and minor polish to your backup routine, you can make this process painless.
For the purposes of making this discussion germane to any Win2K Server installation, I'll frame the steps for recovering your backed-up data within the context of Win2K's native backup tool, Microsoft Windows Backup 5.0, also called NTBackup. Many third-party backup applications offer advanced features to enhance and simplify backup, restore, and recovery operations, but NTBackup provides the essential capabilities required for data protection. Additionally, some third-party programs can write to tape by using the Microsoft Tape Format (MTF), which facilitates recovery by using the native NTBackup program. (For a list of third-party backup solutions, see Buyer's Guide, "Backup Software," September 15, 2001, InstantDoc ID 22003, or visit the IT Buyer's Network, http://www.itbuynet.com.)
Let's document the steps to recover data from a Win2K server following a catastrophic failure. We'll assume the server acts as the only domain controller (DC), DNS server, DHCP server, and WINS server for a small company and has a hardware RAID controller hosting the system and data volumes. To prepare for disaster, you need to establish a solid backup routine and store your backup media and a record of your disk structure off site. Then, following a catastrophic failure, you'll be prepared to install a temporary OS, identify the contents of your backup media, restore the Normal and Differential backup sets, restore the System State data, restore any open files, and test your restored server and services.
Prepare for Disaster
I won't discuss in detail how to prepare for a catastrophic event, but I'd be remiss if I didn't mention some important steps you need to take before a disaster to ensure that you can safely recover your data. If you haven't developed a sound backup strategy that includes media rotation and offsite storage, put a process in place as soon as possible to ensure the safety of your data. (For information about backup strategies, see David Chernicoff, Forefront, "Stop Disaster in Its Tracks," July 2000, InstantDoc ID 8941, and Michael D. Reilly, Getting Started with NT, "Windows NT Backup Strategy," September 1999, InstantDoc ID 7111.) You'll want to follow best practices for using backup verification and execute backups using a user or system account with authority to access the appropriate data objects.
You can save yourself time and make recovery easier by maintaining a record of your server's disk structure for recovery purposes. You can easily document the disk and SCSI information with System Information (msinfo32.exe) by using the following syntax at the command prompt:
"\%ProgramFiles%\Common Files\Microsoft Shared\MSInfo\MSInfo32"
/report a:\diskcfg.txt /Categories +componentsstorage
You can keep the msinfo32-generated diskcfg.txt file on a 3.5" disk or print the file and take it to your offsite storage location. To ensure that you can quickly locate media at recovery time, be sure that the electronic media label written to the tape matches the physical media label.
For the purposes of our example scenario, let's assume that you perform weekly Normal backups and daily Differential backups. We'll also assume for this scenario that you use the default file selections identified by the Backup Wizard when backing up the Win2K server. These files include the System State selections, which are any Active Directory (AD), boot, COM+ Class Registration Database, registry, and Sysvol folder files.
Consider Your Environment
Your environment might require special procedures to handle open files at backup time. In our example, the DHCP and WINS databases are the only files that require special attention. Third-party products are available for managing open files during backup, or you can sometimes script a solution. To maintain fresh backups of the DHCP and WINS databases in our scenario, let's say you've created a small script, which Listing 1 shows, that your backup routine calls just before every backup job. To back up the DHCP database, you merely stop the DHCP service, copy the database file while it's closed, then restart the service. You then use the Net Shell tool (netsh.exe) to automate the WINS database backup procedure without needing to use the WINS console. Note that you must configure WINS with a default backup path, either through the console or Net Shell, before executing the Net Shell command in Listing 1.