Experienced IT professionals know there's much more to a server OS upgrade than just putting in a CD-ROM and running an installation program. The success of a server OS upgrade depends on careful planning. When it came time to migrate French Mortuary's servers from to Windows NT 4.0 to Windows Server 2003, I needed to evaluate the hardware and software currently running on the servers to make sure they would work with the new OS.
A crucial part of any production server is its backup hardware and software. Before I came to work for French Mortuary, the company had licensed VERITAS Software's Backup Exec for use on NT 4.0 servers because NT 4.0's backup utility didn't meet its needs. The company's servers are scattered in several locations throughout the city, and each server has a standalone tape drive. Remotely connecting to each server to check the backup status was time-consuming, so I used Backup Exec's notification feature to keep me informed by email.
When it came time for the migration, I ran into a problem: The Backup Exec version being used wasn't compatible with Windows 2003. An upgrade to a new version would be necessary. However, because seven Backup Exec licenses were involved, the upgrade would've cost almost $4000—a significant investment for a small company that would have put us over budget in software licensing costs. In management's mind, this was a hidden cost related to the server OS migration.
Previously, I hadn't given much thought to using Windows 2003's built-in backup utility, NTBackup, because I had been using Backup Exec. Plus, my previous experience with NTBackup as well as comments I had read in newsgroups and Web forums didn't give me a positive impression of the utility. But because of the high costs involved in upgrading our backup software, I decided to give NTBackup another try.
NTBackup works closely with a core OS service called Removable Storage, which provides a software interface for managing the tape drive and its associated media. NTBackup also works alongside the Task Scheduler service to provide a wizard-based scheduling capability. However, the online Help files and product documentation provide only a cursory explanation of the NTBackup utility and its interactions with the Removable Storage and Task Scheduler services. Getting scheduled backups to work the way I wanted was, at first, an exercise in frustration.
Some of this frustration is related to our company's backup requirements. Each remote location has a person responsible for inserting the correct tape for the nightly backup. For various reasons, the tapes sometimes don't get changed. NTBackup's built-in scheduling feature requires you to select a specific tape for a backup job. If that tape isn't available when the backup job starts, the backup will simply abort. This behavior isn't acceptable in our environment. We need the backup to continue, even if it overwrites the previous day's tape.
NTBackup doesn't have an option for overwriting an arbitrary tape from its scheduling GUI. I found that you can overwrite a tape by modifying the NTBackup command line to include the /um option. However, NTBackup also then applies a new media label to the tape, which would disrupt our media-labeling scheme. In our case, the label on the outside of the tape must match the tape's media label in the NTBackup GUI. Ideally, I wanted NTBackup to somehow identify the currently inserted tape and use it in a backup. This would give me the ability to overwrite a tape with a new backup without changing its media label or append a new backup to the currently inserted tape.
After doing some research, I found that Windows 2003 has a cryptic command-line utility called Rsm for managing the Removable Storage database. I set out to discover how the Rsm utility works, what capabilities it provides, and how it represents the contents of the Removable Storage database. This proved challenging because the database layout is undocumented. Using the Rsm utility to navigate through the Removable Storage database from the command line is a tedious exercise in cut-and-paste because the database objects are represented by 32-character globally unique identifiers (GUIDs).
One of the difficulties in scripting the Rsm utility is that the Removable Storage database GUIDs are database-specific and are different for different servers. However, I discovered it's possible, given the tape drive's friendly name, to determine the inserted tape, its name, and its GUID.
Armed with this knowledge of the Removable Storage database and the Rsm utility, I created a set of backup scripts that makes NTBackup easier to schedule. To simplify deployment to multiple servers, only a single configuration script needs to be updated to reflect server-specific information, such as the tape drive's name. In addition, the backup scripts can email and/or print the backup log after the backup completes. You can read about the scripts and how to use them in "Want a Flexible Automated Backup Solution?" February 2005, InstantDoc ID 44990.
As the backup scripts demonstrate, scripting can solve real business problems. IT shops aren't known for generating revenue, but they can cut costs. In this case, by using scripts to enhance a core OS tool, I saved my company $4000 in licensing costs, which is significant given that we're a small company with fewer than 100 full-time employees. And based on the feedback I've received, the automated backup system is working flawlessly.
