Most Windows NT administrators devote significant effort to ensuring that their servers are backed up properly. Many, however, pay little attention to protecting what’s stored on the client hard drives. That’s a mistake, because locally stored data is often critical to the company, and is usually difficult or impossible to reconstruct. More than one company has failed as a direct result of losing data that had been stored on a client hard drive. This article examines various alternatives for backing up Windows NT Workstation clients.

The most popular approach to protecting local workstation data is server-based backup. With this method, you backup data from both the local server volumes and the remote workstation volumes in a single operation. To use server-based backup, either all workstations to be backed up must participate in domain security, or the backup user account on the server must be granted membership in the Administrators or Backup Operators local groups on each workstation to be backed up. Backing up from a central location streamlines administering backup and restore functions. More important, you’re the one doing it, so you know it’s getting done.

In a small network, you can use Windows NT Backup to implement server-based backup by creating static drive letter mappings on the server for each workstation volume, and then configuring the server backup software to backup all local and network volumes. You can map drive letters to defined shares (e.g. \\computername\sharename) on the workstation volumes, or to the administrative share (e.g. \\computername\c$) for volumes that have not been explicitly shared. Using static drive letter mappings created at the server console is feasible only in the smallest networks, however, because Windows NT can map only 25 drive letters.

One way to get around this is to create a batch file that "recycles" drive letters, using the same drive letter to map to different workstation shares in different backup passes. For example, the following batch file illustrates using Windows NT Backup running on the server kerby to backup local server drives C:, D:, and E:, and numerous volumes on remote Windows NT Workstation clients.

The first group of net use statements maps various Windows NT Workstation client volumes to the available drive letters F: through Z: on the server kerby. The first ntbackup command line backs up the local server volumes C:, D:, and E: and the local server registry, as well as the workstation volumes that are currently mapped to the available drive letters.

The middle group of net use statements deletes the current mappings for drive letters F: through Z: and then remaps drive letters F: through U: to volumes on the workstations that have not yet been backed up. The second ntbackup command line backs up the new volumes that are now mapped to those same drive letters. The final group of net use statements deletes the current mappings for drive letters F: through U:.

When this batch file runs, it makes two separate backup/verify passes to process all of the volumes in the batch file, creating a backup set for each volume. Because different backup sets use the same drive letter (e.g. both \\sherlock\d$ and \\hathor\c$ were backed up as g:), you must make certain when restoring to map the correct volume to the drive letter associated with the backup set.

If your budget is tight, Windows NT Backup at least provides the essentials necessary to implement server-based backup. It’s not fast, flexible, or convenient, but it gets the job done. If you can afford something better, consider replacing Windows NT Backup with a third-party product like Seagate BackupExec or Computer Associates’ ARCserve. Although, with street prices of $400 and up, these products are not inexpensive, they provide very useful features like built-in scheduling, software compression, the ability to save pre-defined backup sets, and the ability to backup UNC share names directly without first mapping a drive letter to them. They also add important functionality that is missing from Windows NT Backup, notably the ability to backup and restore remote registries.

Although server-based backup is often attractive from a cost and convenience viewpoint, it’s not suitable for every environment. The following factors may militate against using server-based backup:

Limited backup window – Server disk farms keep growing. At the same time, many companies have extended business hours, thereby shrinking the time available to do the backups. Adding client volumes to the list of volumes to be backed up may require more time than you have available. Almost as bad, the additional space required to store client data may exceed the amount available on a single tape, forcing you to shift from using all full backups to using a combination of full and partial backups. One solution, of course, is simply to install a second server-based backup system and dedicate it to backing up client workstations.

Network throughput limitations – Another constraint on server-based backup is the limited availability of network bandwidth. Typical clients have more than 1 GB of disk space, and clients with 10 GB or more are increasingly common. Clients on the far end of a T1 link contend for actual throughput of less than 700 MB per hour, and those on a 10BaseT Ethernet for throughput of about 4 GB per hour. Even a Fast Ethernet network may not provide sufficient throughput to backup many clients with large disks in the time available.

Security of local data – If confidential data is stored locally on clients, using server-based backup opens a gaping security hole. People who have access to a backup tape can restore it to a FAT volume, thereby stripping NTFS permissions and allowing full access to all folders and files. Alternatively, they may simply restore the tape to a Windows NT computer for which they have the administrative privileges necessary to override file and directory security. This issue also applies to local backups, of course, but it is easier to make individuals responsible for securing their own backup tapes than it is to secure centralized backup tapes, which by their nature often must be readily available to numerous people.

Failure to backup local registry – Some third-party backup products can back up the local registries on remote clients, although doing so may require purchasing and installing agent software on the workstation. Other products, including Windows NT Backup, can backup only the local registry on the computer where they are running.

Granularity – Depending on the server-based backup software you use, you may be limited to specifying entire volumes to be backed up, rather than being able to specify folders and files individually. For example, although Windows NT Backup allows you to make individual file and folder selections when you run it interactively, it limits you to selecting by volume when you run it from the command line (as in a batch file).

If one or more of these issues rules out server-based backup for you, the alternative is to backup your workstations locally. If you decide to use local backup, you must choose and install appropriate backup hardware for each workstation. Although magneto-optical, CD/R, CD/RW, and DVD/RAM are making inroads, tape is still the overwhelming favorite for general backup duties. You are likely to find that one of the following tape technologies is appropriate for your workstation backup needs. The typical drive/tape costs for each are shown in parenthesis.

Travan TR-4 ($200/$25) – These drives store 4GB/8GB (native/compressed), and provide theoretical throughput of 30MB/min native and 60MB/min compressed. Real-world throughput on local drives is typically about 40 MB/min, or about 3.25 hours to fill a tape. Because these drives have only one head, they require a second pass to verify the backup, which increases total backup time by 50% or more. These drives are available with either an IDE/ATAPI or SCSI interface.

Travan NS8 ($250/$25) – These drives began shipping in quantity in Spring, 1998. They provide throughput and capacity similar to that of TR-4 drives, and are available with IDE/ATAPI or SCSI interfaces. They use a read-while-write head configuration, and can therefore complete backup and verify operations in one pass.

Travan TR-5/NS20 ($375/$40) – These drives began shipping in quantity in Fall, 1998. They store 10GB/20GB (native/compressed), and provide theoretical throughput of 60MB/min native and 120MB/min compressed. Real-world throughput on local drives is typically about 80 MB/min, or about 4.25 hours to fill a tape. These drives use a dual-bump read-while-write head configuration, so they can complete backup and verify operations in one pass. These drives are available with IDE/ATAPI or SCSI interfaces. Their sole drawback is the very high cost of TR-5/NS20 tapes.

DAT DDS-2 ($700/$8) – These drives are comparable in capacity and throughput to Travan TR-4/NS8 drives, provide single pass backup/verify operation, and are available only with SCSI interfaces.

DAT DDS-3 ($950/$20) – These drives store 12GB/24GB and provide throughput comparable to that of the Travan NS20 drives. They provide single pass backup/verify operation, and are available only with SCSI interfaces.

The dilemma you face is choosing between inexpensive Travan drives that use expensive tapes and expensive DAT/DDS drives that use inexpensive tapes. Travan drives are relatively inexpensive to build because they do not require close tolerances; all of the rigidity and tight tolerances are built into the Travan tape cartridge itself. Conversely, DDS drives are relatively expensive to construct because they are built to tight tolerances, allowing them to use inexpensive, loose tolerance DDS tape cartridges.

For workstation use, the much lower cost of Travan drives may be offset overall by the much higher cost of tapes. Most common tape rotations require between six and ten tapes, which must be replaced periodically. Assuming a three year useful service life for the drive, annual tape replacements, and disregarding the time value of money, the relative costs work out as follows:

Travan TR-4 4GB/8GB 200 450 – 750 650 – 950

Travan NS8 4GB/8GB 250 450 – 750 700 – 1,000

DAT DDS-2 4GB/8GB 700 144 – 240 844 – 940

Travan NS20 10GB/20GB 375 720 – 1,200 1,095 – 1,575

DAT DDS-3 12GB/24GB 950 360 – 600 1,310 – 1,550

At first glance, it may appear that the overall cost advantage of Travan is small or non-existent. However, only Travan drives are available for the ATAPI/IDE interface that is universally available in workstations. To install a DAT/DDS drive in most workstations, you must also purchase, install, and configure a SCSI host adapter to support it. Even if a slot for the SCSI host adapter is available in every workstation, the parts and labor cost to install aftermarket SCSI can easily exceed $300 per workstation, which knocks out DAT/DDS as a workstation backup alternative in many environments.

Purchasing any of these drives also solves the problem of acquiring suitable backup software, because nearly all of them come with competent backup software for Windows NT Workstation. The bundled software is typically a full-featured workstation or single-server version of either Seagate BackupExec or CA ARCserve. Either of these is more than adequate for the task at hand.

The biggest danger to depending on local backup, of course, is that it won’t get done. Some companies have established draconian penalties for employees who fail to perform local backups. Even if you threaten to shoot recalcitrant employees at sunrise, however, Murphy’s Law says that at least some workstations won’t be properly backed up when you most need them to be.

To enforce compliance, you need to know which workstations have not been backed up on schedule. The easiest way to do this is to configure the backup software on each workstation to record a uniquely-named backup log to a common directory. Each morning, you can examine the contents of that directory to locate missing files.

If you have many workstations, it’s useful to begin the log file name for each of them with a unique number. For example, rather than using the log file names anubis.log, and ariel.log, use 01anubis.log and 02ariel.log. That way, you can simply sort the backup log files by name to make it immediately obvious when one or more files in the expected sequence is missing.

30

Robert Bruce Thompson (thompson@oreilly.com) is the president of Triad Technology Group, Inc., a network consulting practice. He is the author of Windows NT Server 4.0 for NetWare Administrators and the co-author of Windows NT TCP/IP Network Administration, both from O’Reilly &; Associates.