Data Centers

Best practices for backing up all NT data prior to migration

When upgrading to Windows Server 2003 from NT, the last thing you want is for the upgrade to fail midstream and to then discover you've lost all of your server's data in the process. Here's how to properly back up your system first.

By Brien M. Posey

If your network is running purely Windows NT Server and you're planning on migrating to Windows Server 2003, you’re in for a lot of changes. Windows Server 2003 is very different from Windows NT. Whenever you perform a radical operating system upgrade, there's always the potential for something to go horribly wrong. That’s why it’s so important to make a full backup of your NT servers before even attempting a migration. But what is the best method for ensuring a successful backup? Here are several backup strategies you can use when backing up NT prior to moving to Windows Server 2003.

What are my options?
There are a few backup methods you can use to get the job done. One method is to use the built-in NT Backup program and back your server up to tape. Another method is to get a third-party backup utility and use it to create a full system backup. Finally, you can create an image file for each of your hard disks. Any of these methods will do the trick if executed properly, but each has pros and cons associated with it.

NT backup vs. third-party backup programs
First, let's look at the NT Backup utility. As you may know, this utility is included with Windows NT Server, meaning that you don’t have to go out and buy anything, except for maybe a tape drive. The downside to using the NT Backup utility is that it’s very crude. It doesn’t support software-based compression, scheduling, or any of the other features that are standard in more modern backup software packages. However, don’t write off Windows NT Backup just yet; it does have some advantages that may make it the perfect solution.

Before I discuss these advantages, I suggest you take a look at the commercial backup software that’s available. There are a million third-party backup software packages, and most of them do a decent job of backing up Windows NT. When Windows NT was first released, there was an issue with some of the backup software packages because some didn't know that the registry existed or didn't understand how to back up the NTFS file system. I also saw some backup programs that had trouble backing up long filenames. Unless you have a really old backup application, though, you shouldn’t encounter any of these issues. Of course, you're guaranteed not to experience any of those problems if you use NT Backup.

Any up-to-date backup program should be able to successfully back up and restore the Windows NT operating system. Where you might get into trouble is if your server is running a server application that requires online backup support. A good example of such an application is Microsoft Exchange. Because of Exchange's nature, messages are constantly being sent and received. As you may know, backup software can't back up a file that’s open at the time of the backup. To get around this problem, Exchange has a unique way of backing up the databases. When messages come in, they're not written directly to a database, but rather to a transaction log. When a backup runs, the transaction logs are processed so that the databases are current; then the databases are backed up. This is a gross oversimplification of the process, but if your server is running Exchange, you can’t back up data in the normal manner.

The only way you can successfully perform an online backup of an Exchange Server is to have an Exchange-aware backup application. When you install Exchange Server, the NT Backup program on that server is automatically updated, thus making it Exchange-aware. Such an update does not occur for third-party backup packages or for copies of NT Backup that might be running on different servers.

That isn’t to say that you can’t use a third-party backup software package to back up an Exchange Server. Most of the major enterprise class backup packages offer add-on modules for backing up Exchange Server. In fact, these add-on modules are often better than what Microsoft appends to NT Backup. For example, with NT Backup, you can’t easily restore a single mailbox on an Exchange 5.5 Server. There are tricks you can use to restore a single mailbox, but those tricks require a completely separate Exchange Server that has been created solely for backup and recovery purposes. On the other hand, some of the Exchange add-on components will allow you to restore individual mailboxes just as easily as restoring an individual file.

It may sound as though using a third-party backup solution is the way to go. However, these solutions can be really pricey, especially when you have to start buying add-on modules.

A third technique you can use to circumvent most of the issues I've discussed involves creating hard-disk images rather than traditional backups. You can easily create hard-disk images by using a product such as Norton Ghost. When creating such images, the image files can be written to CD, DVD, or many other types of removable media. As with the other backup types, however, ghosting has its good and bad points.

Before you can ghost a hard disk, you must take a server offline. Doing so ensures that no changes occur during the backup process and that there are no open files to contend with. Even if your server is running Exchange Server or a similar product, a ghosted image will get the job done.

There are a few issues you need to be aware of before settling on ghosting. First, you can make a ghost image only of a single partition or a single drive. You can't ghost the system as a whole. You can achieve a full system backup by making ghosted images of each individual drive or partition, but doing so can be time-consuming and often requires a lot of manual intervention.

Manual intervention is often required because an entire drive or partition seldom fits on a single CD or DVD, even if compression is used. Therefore, someone will have to be available to swap media when necessary. Newer versions of Ghost can write backups to removable hard drives, which eliminates the issue of media swapping.

The biggest downside to using Ghost is that if your system has RAID arrays, there's a good chance that Ghost may not recognize the partitions that exist on the RAID array. This would mean that Ghost would be unable to image such a partition.

There is one other issue you need to be aware of. Let’s suppose for a moment that you had a Windows NT Server running Exchange 5.5, and that you ghosted all of the server’s partitions. Now let’s say something went wrong during the migration to Windows 2003, and you had to restore the ghosted images.

Restoring with Ghost would be easier than restoring with most other backup programs. Backup programs such as NT Backup require you to install the Windows operating system before you can restore the backup. That’s because the backup software runs on top of Windows. Ghost, on the other hand, runs outside of the operating system, and ghosted images can be restored directly, without your having to first install an operating system.

Also, if only one of the server’s partitions became corrupt, it would still be necessary to fully restore all of the ghosted partitions in this case. Exchange places files on a variety of partitions in order to optimize the system. Exchange won’t work unless everything is consistent. If you restored one partition that was used by Exchange, but left another partition in its present state, there’s a good chance that Exchange would become corrupt and stop working.

If you've done drive-level backups, there's nothing special that you'll have to do prior to restoring ghosted images. If you've ghosted at the partition level, you'll want to recreate the partitions prior to restoring the ghosted images.

Testing your backup
After you've made a backup, the next step is to test it. Believe me, there is nothing worse than needing to restore a backup and finding out that the backup is incomplete, corrupt, or that it has some other major problem.

The best way to do this is to set up an old PC as a server that you can use to restore your backups to. This PC should not be connected to the network. If your test PC is connected to the network, and you try to restore a backup, you'll run into conflicts with computer names and IP addresses.

A better solution is to simply unplug the PC from the network, configure the PC to mimic the partition structure of the machine you're testing the backup for, and then try to restore your backup. When the restore completes, be sure to take some time to check that everything is there. If you really want to give it the ultimate test, you can unplug your production server and see if your test server can stand in for it. If the process works, you know that you have a good backup. Just remember that any data that gets written to your test server while it is filling in for the production server will be lost.

Setting up a domain controller
This is a little off the topic of backup strategies, but if you're considering migrating your NT network to Windows Server 2003, I recommend getting your hands on some old PCs that are no longer being used and loading Windows NT Server onto them. You can set up a PC as a domain controller for the domain that you're about to upgrade.

Normally, when you're going to start upgrading domain controllers from NT to Windows 2003, you'll want to start with the PDC. Keep in mind that Windows 2003 doesn’t use the Windows NT Security Accounts Manager (SAM), but rather uses Active Directory. During the conversion, there is a potential for user account information to become corrupted across the entire domain.

Because of this, you'll want to bring an old PC online as a BDC and give it time to replicate with the rest of the domain controllers for that domain. Just before you begin the upgrade, shut down the PC and unplug it from the network. Now, put the PC in a safe place while you do your migration.

Most of the time, a migration will go smoothly. If something does go awry, you can get your PC out of the closet, bring it online, and promote it to PDC. This will allow you to reconstruct your domain and all of the user account information contained within it. You'll want to create such a PC for each domain in your network.

I should point out that setting up an old PC as a domain controller is a safeguard but is no substitute for a real backup. If an individual server were to fail, your PC does not have enough information on hand to be able to restore the server. The PC that you’ve created is suitable only for recovering account information after an entire domain has become corrupted.

The real world
So far, I've given you a lot to think about as far as different backup techniques and strategies go. Now I want to give you a dose of real-world experience to go along with all of the theories.

About three years ago, I was living in Kentucky and had a network of around 20 machines running in my basement. At that time, I decided to pack up and move to South Carolina to be closer to my family. I knew there was a good chance that my servers could be damaged in the move, so I wanted to make sure I had a good backup of each machine.

I chose to use Ghost for my backups. I also purchased an additional computer that I could use for testing my ghosted images. After I finished ghosting each machine and testing each backup, I had planned on formatting the machine and then bringing it online as a domain controller to preserve a copy of my Active Directory environment (I was already running Windows 2000).

However, I decided that, for the purpose of the move, it would be better to have the spare machine already loaded with an image of my most important server, rather than just bringing it online as a domain controller. Of course, this was for a physical move, not for a migration. For a migration, I think you’re better off setting the machine up as a domain controller and putting it away where it can be used in an emergency.

Editor's Picks