RepairDisk Manager
I installed Raxco's RepairDisk Manager on the same hardware platforms I used to test Aelita's ERDisk. The installation wizard guided me through a quick and simple installation of RepairDisk Manager and didn't ask me to reboot. RepairDisk Manager provides documentation online in HTML Help files.
Three main components contain RepairDisk Manager's functionality: RDM Console, RDM Agent, and RDM Scheduler. RDM Console provides an administrative GUI for centrally configuring and launching ERD tasks. The minimum requirements for running RDM Console are a modest 16MB of RAM and Win2K or NT 4.0.
The RDM Agent is similar to ERDisk Agent in that it's a service that RepairDisk Manager installs on target systems to compress ERD files and direct them to a centralized storage area on the network. Unlike ERDisk, RepairDisk Manager lets you leave the agent installed on a system rather than delete it after ERD files are collected. Leaving the agent permanently installed eliminates the need to delete the agent files and service entries in the Registry at the end of each backup, thus slightly reducing the overhead on the client system.
RDM Scheduler, which runs on the RDM Console system, is the service that actually launches scheduled ERD jobs. Raxco claims that using RDM Scheduler rather than Schedule Service provides two advantages. First, you can continue to use Schedule Service in the context of the Local System account rather than a domain account with network privileges. If you use Schedule Service to launch jobs that require a GUI, this feature is important. Second, by not forcing you to use a domain account with network access for Schedule Service, RepairDisk Manager adds an extra layer of security against misuse of Schedule Service. Both of Raxco's arguments have some merit, but security-conscious administrators who like to disable Schedule Service will be disappointed to find out that they need Schedule Service to activate RDM Scheduler.
RepairDisk Manager also provides a recovery console similar in function to the Win2K Recovery Console and ERDisk Emergency Repair Console. The main difference is that RDM Recovery Console provides only a command-line interface for full access to an NTFS drive, whereas the other two consoles provide additional features.
Like the ERDisk main console, RDM Console resembles an MMC snap-in. As Figure 4 shows, the left-hand pane lists domains, workgroups, and schedules, and the right-hand pane lists details about group members. RDM Console has all the functionality of ERDisk's GUI, but it is a little slow, taking too much time to perform tasks such as refreshing the screen, enumerating domain members, and displaying property sheets. This sluggishness became more annoying the longer I worked with the console.
Following the same procedure I used with ERDisk, I began testing RepairDisk Manager by manually launching an ERD creation task for a system on my test network. I simply selected the computer I wanted to back up and clicked the Run RDM button on the RDM Console toolbar. After I launched the task, a status window showed the progress of the operation, which was completed without any errors.
I was surprised I didn't have to configure any options on my first run, so I checked to see what settings I could manipulate. I found that if you right-click any selected computer or group of computers, you can specify a destination path and retention policy for the ERD files. Within the destination folder you specify, RepairDisk Manager creates another folder for each backup. The RepairDisk Manager-generated folder name includes the system name and the date and time when the backup was finished. Compared with ERDisk, RepairDisk Manager's retention options are limited: You can save all ERD sessions or any number of sessions from 2 to 10.
RepairDisk Manager doesn't provide an option for agentless operation. When I timed RepairDisk Manager's agent-based ERD creation and measured CPU utilization, the results were almost identical to ERDisk's agent-based operation. To summarize my performance findings for both ERDisk and RepairDisk Manager, you can expect a spike in CPU utilization on any system (workstation or server) while ERDisk or RepairDisk Manager is compressing ERD files before sending them to their destination. This spike is relatively brief (30 to 75 seconds on member servers and longer for domain controllers) but might be noticeable on heavily used mission-critical servers.
One feature specific to RepairDisk Manager is the option to retain the original SAM and SECURITY hives. The original hives are small because they contain only basic information such as the local administrator account password. If you retain the original hives and you need to perform a repair on a system, you might be able to fit all the ERD files on one disk. Although this is a valid approach, it doesn't compare favorably to ERDisk's ability to save across disks and exploit CD-R discs.
To test RepairDisk Manager's ERD scheduling, I clicked the Schedule button on the RepairDisk Manager toolbar. I provided an account that could access all the computers on the network and gave that account the rights to log on as a service and to back up and restore files and directories. After that, setting a schedule was a simple task of selecting network computers from a list and selecting scheduling options from the dialog box, as Figure 5 shows. I used all the computers in my test network to set up several test schedules. I didn't run into any problems except that a PC in another domain didn't recognize the account credentials I provided for the RDM Scheduler service. Otherwise, all scheduled jobs completed normally.
To begin testing the recovery process for RepairDisk Manager, I clicked the Apply ERD toolbar button. This button launched a wizard that gave me the option of creating an ERD from the previously saved ERD files or applying Registry hives to the remote machine. I could select a PC to repair and the version of ERD files I wanted to restore. I could create a standard Windows ERD or apply the files remotely across the network. When I chose a remote restore, the wizard let me launch the process regardless of the target machine's availability. For machines that were up on the network, the remote restore worked flawlessly. If a target machine wasn't available, I had to restart the wizard and create a standard Windows ERD. For machines requiring an ERD, RepairDisk Manager dutifully created disks that I then successfully used with the Windows Emergency Repair process.
Finally, I tested RDM Recovery Console. RepairDisk Manager provides a wizard for creating the RDM Recovery Console boot disks. The process was identical to ERDisk's and successfully generated the boot disks. I created one set of disks for Win2K and another set for NT and tested each. RDM Recovery Console provides a simple command-line interface for accessing NTFS disks. Commands let you perform tasks such as copying and deleting files and creating directories. These features compare favorably with those of ERDisk's Emergency Repair Console, but ERDisk also has an automatic repair option that supports ERD files on multiple disks and CD-R discs.
ERDisk Has the Edge
Both Aelita's ERDisk and Raxco's RepairDisk Manager are easy to use, perform well, and provide the services they advertise. But ERDisk provides extra functions and configuration options that busy administrators will appreciate. In addition, Aelita's aggressive pricing makes deploying ERDisk much easier on your budget.
A comprehensive disaster-recovery plan is imperative for all organizations, regardless of size. Having ERDs on hand is an integral part of that plan. If you don't have time to maintain ERDs, ERDisk can help—and it's definitely worth the modest cost.