Objects and Attributes, Attributes and Objects
In Exchange 5.5, the associated Windows NT account was an attribute of the Exchange mailbox. In Exchange 2000, the Exchange mailbox is an attribute of the Windows 2000 Active Directory account. This may seem like a subtle difference, but it's actually quite important when it come to backing up, restoring, and configuring your Exchange data.

You no longer have to worry about backing up and restoring the Exchange directory (especially since there isn't one anymore). As long as you have backups of your Active Directory, your user and mailbox list is safe. If you have multiple domain controllers and only one of them fails, your Active Directory should still be intact on the other domain controllers. Simply bringing the Exchange server back up (which may require a reinstall of Windows 2000) as a domain controller should result in the Active Directory being re-replicated back to it intact. Now you only have to worry about restoring your Exchange data.

However you handle it, however, you need to make sure that you can get the Active Directory back. Without it Exchange is dead in the water.

Directories, Directories Everywhere!
In Exchange 5.5 saving your folders and items was simple: priv.edb for your Private Information Store and pub.edb for your Public Information Store. In Exchange 2000 the scene has changed. Now you can have up to four storage groups, named whatever you choose, and each storage group can have up to five databases—again, each named whatever you choose. The nice thing about this arrangement is that you can back up (and, of course, restore) each of these storage groups (or even databases) individually.

Even though you can back up the databases individually, it's considered a "best practice" to back up all of the databases in a storage group as a unit. Be mindful of the time it takes to back up these groups and restore them when you configure the storage groups and databases. If it takes 10 hours to back up a storage group, that will probably prove to be impractical for regular use. Worse, if it takes 8–10 hours to restore the storage group or database, you'll have at least that much downtime in the event of a system failure. The solution is to spread your data into multiple databases and/or storage groups.

From a performance standpoint, this problem is mitigated somewhat by the fact that you can back up the storage groups concurrently. That means you can back up Group A and Group B at the same time. One important limitation is that you can't back up separate databases within the same storage group simultaneously—i.e., you can't back up Database 1 and Database 2 within Group A, separately, at the same time.

Better still, if you're doing an offline restore, you can take them down individually, so that you can restore one database while the rest of them keep running.

The Streaming Database
It's important to understand that there are more databases these days that you, as the admin, have to be worried about. You can't just back up .EDB files and be done with it. When messages are received from the Internet, they're no longer converted to MAPI format. Instead, they're stored in the .STM file, in their native format, and pointers to them are created in the .EDB file. If you back up and restore the .EDB file without the .STM file, your .EDB file is useless.

The .STM file has no indexes; it's just raw content. It doesn't even have any indication of which mailbox each item belongs to. Accordingly, you have to make sure that if you restore an .STM file, you have to restore the matching .EDB file. If they don't match, they won't work.

As a matter of practice you should treat the .STM and .EDB as Siamese twins—one never leaves the other.

The New Switch
If the Exchange server is the only server to fail—i.e., you have your Active Directory from another domain controller—you can run Exchange setup with the /disasterrecovery switch (note the two r's), which will install Exchange just as it was. The key to this is that all of the necessary information is now stored in the Active Directory instead of the Windows Registry.

Once you've reinstalled Exchange with the /disasterrecovery switch you can simply restore your databases (don't forget the .STM files, and Key Management Server—if you use it) and you're back in business.

Hard Recovery vs. Soft Recovery
There are two kinds of recovery that you should be aware of. Soft recovery is what happens when an Exchange server crashes or aborts for some reason and, upon restart, simply replays the transaction logs to bring itself back to the current state. No restore from tape backup is required and, aside from the possibility that the crash will repeat, the server is operational after a restart.

Hard recovery is what happens when you restore the server from scratch, you restore the databases from backup, and the transaction logs are replayed—but it doesn't quite stop there. When you are doing the online backup, often there will be transactions that come in between the time the database is written to the tape and the time the backup finishes. Those are stored in what are known as "patch files," which have to be applied before you're completely restored. Doing a hard recovery takes care of adding those patch files into the database so that recovery is complete.

This has been a quick look at some of the Exchange 2000 issues concerning backups and restores. In a future 10-Minute Solution I'll talk more in-depth about some other issues you'll need to be aware of: mbcon.exe, ldifde.exe, and the legacyExchangeDN value.