SQL Server Magazine

I've always believed that maintaining up-to-date Emergency Repair Disks (ERDs) is a vital part of a comprehensive disaster-recovery plan. However, regularly creating or updating ERDs on each server and workstation was tedious and time-consuming. Inevitably, keeping my ERD library current fell by the wayside in favor of more urgent tasks. Most administrators are familiar with this story and its unfortunate ending: Eventually, a critical server went down with a corrupted Registry, and I was stuck without an ERD. Reinstalling the OS, reapplying the correct service pack, and restoring system data from backup tapes took 2 hours of my time (not to mention the costly server downtime). If I'd had an ERD, I probably could have had the server up in fewer than 10 minutes. After that experience, I was more diligent about creating and updating ERDs, but no matter how I tried to automate the process, it was still an administrative headache.

Fortunately, several software vendors have developed ERD utilities that simplify and automate the process of keeping emergency repair information for Windows 2000 and Windows NT workstations and servers up-to-date. I tested Aelita's ERDisk 5.0 and Raxco's RepairDisk Manager and compare them here. But an examination of ERD utilities should begin with a look at the ERD capabilities Microsoft provides with Windows.

Windows' ERD Solutions
You maintain an ERD so that you have a means of quickly restoring a PC to a bootable state if critical system files are damaged or deleted. An ERD isn't a substitute for regular backups.

During the installation of Win2K or NT, the Windows Setup process copies nine files that contain Emergency Repair information to the \%system root%\repair folder. Five of these files, which Setup saves in compressed format, represent the Win2K or NT Registry hives; two files initialize the default DOS environment; and one file contains the default user profile information. The last file, setup.log, is a log of all the Win2K or NT system files copied to the disk during installation and always has the read-only, system, and hidden attributes.

If you choose to create an ERD during a manual installation of NT 4.0, Setup compresses the nine files and saves them to a disk, which you should label and store in a safe place. If you create an ERD for Win2K, only the two DOS initialization files and setup.log are copied to a disk because the default Registry information for Win2K exceeds 1.44MB. In either OS, the Emergency Repair information that the installation stored in the \%systemroot%\repair folder remains there, whether you create an ERD or not. As long as the hard disk in which the \%systemroot%\repair folder resides is accessible, the files in the repair folder can usually (but not always) help you restore the system to base functionality if you launch Windows Setup and choose the Repair option.

Microsoft recommends that you update the Emergency Repair information and your ERD after making any significant hardware, software, or configuration changes to the system. In NT 4.0, you run the Repair disk utility to update the information. Type

rdisk

at the command line to launch the utility and display options for updating the information in the \%systemroot%repair folder as well as on your ERD. Type

rdisk /s

to also back up the SECURITY and SAM Registry hives to the repair folder and ERD. On a domain controller, the SAM and SECURITY hives are usually too large to include on the ERD, which is limited to one disk.

In Win2K, you use the Backup application to access the utility for creating an ERD. By default, this utility updates the DOS initialization files and the setup log, but as Figure 1 shows, the utility can also back up Registry hives. When you select the Registry-backup check box, the utility automatically saves the hives to the \%systemroot%\ repair\regback folder but not to your ERD. If your Registry is corrupted or erased, you can use the files in this folder to restore just your Registry and avoid a lengthier restoration of the Win2K System State data, which typically occupies a minimum of 200MB of storage. To restore System State data, you need to use the Win2K Recovery Console. (For more information, see Zubair Ahmad, "The Windows 2000 Recovery Console," http://www.win2000mag.com/, InstantDoc ID 7250. For more information about System State, see Zubair Ahmad, "Backing Up and Restoring the System State," http://www.win2000mag.com/, InstantDoc ID 7664.)

Most administrators are familiar with the NT 4.0 Emergency Repair process. You run NT Setup from the CD-ROM or startup disks and choose the Repair option. Then, you can select from options that let you restore individual Registry files, repair the startup files in the system partition, repair NT 4.0 system files, or repair the partition boot sector. The repair process will ask you for your ERD. After the repair is done, you must reapply the most current service pack to bring your system back into working order.

The Win2K Emergency Repair process is similar in that you run Win2K Setup from the CD-ROM or startup disks and choose the Repair option. You then can choose Fast Repair or Manual Repair. Fast Repair tries to repair system files (using the checksum method and setup.log), the boot sector on your system disk, and your startup environment. Fast Repair also checks the Registry files. If a Registry hive has a problem, Fast Repair automatically copies the hives backed up in the \%systemroot%\repair folder.

Manual Repair, an interactive subset of Fast Repair, doesn't check the Registry hives. It does let you perform one or all of the other three Fast Repair options above: verifying system files, inspecting the boot sector, and checking the startup environment.

Assessing Windows' Solutions
Using the Win2K and NT 4.0 ERD utilities Microsoft provides is straightforward but not without certain pitfalls. First, after you restore Registry hives, you can't reverse the process unless you've saved different versions of the ERD.

A second hitch in the Windows repair process is that you can't save Emergency Repair information across disks. You can save any amount of ERD data to the \%systemroot%\repair folder, but if you can't access the repair folder, you might need to reinstall the OS and restore the entire system from tape.

A third and significant problem is that Microsoft didn't design its ERD-creation utilities to be automated or centrally managed. You can use a combination of scripts, At commands, and Win2K's or NT 4.0's scheduling service to automate most tasks, but creating and administering the scripts and following through on their success or failure can be a nightmare in large environments. Finally, although the Win2K Task Scheduler has improved security features, many organizations that run NT 4.0 disable NT 4.0 Schedule Service as a standard security measure. In addition, some IT shops don't like the idea of storing their servers' security hives on relatively insecure disks.

All in all, using Win2K's and NT 4.0's ERD utilities is easy on a machine-by-machine basis. The Emergency Repair process has worked for me on many occasions, although it has failed me in at least as many situations. Win2K's additional recovery tools, such as the Recovery Console and the enhanced startup options, somewhat overshadow the features of the Backup and Repair processes, but the ERD still has a niche in providing quick recovery of a damaged system.

   Prev. page   [1] 2 3     next page