Each database has a logical name that appears in Exchange System Manager. This name is stored in Active Directory as an Exchange database object.

The database itself consists of two files: the .edb database file and the .stm streaming database file. These files are a matched set and must be treated as if they were a single file. They must be backed up, copied, or moved in strict tandem. If you have a version of the .edb file that is not synchronized with the .stm file, the database will be unable to mount. Exchange stores database file names as properties of the Exchange database object.

You can view these properties in Exchange System Manager on the Database tab of the Properties dialog box for that database. For example, the following figure shows the properties of a database. The logical name of the database is Mailbox Store, and the database file names are priv1.edb and priv1.stm.

Database properties tab of a mailbox database

When you mount a database, Exchange reads the paths and names of the database files from Active Directory. If valid files with the proper names are not present in the right path, you will be warned and offered the opportunity to generate new database files. (Unless you know that you want new files to be generated, stop the mount process and find your existing databases.)

Moving a database between ordinary storage groups merely involves moving a matched .edb and .stm file set into the new path location. In general, it does not matter that the new storage group name or the logical database name are different from the original names. It does not even matter if the log file prefix is different in the new storage group (you can move a database that was running with a set of transaction logs named E00nnnnn.log to a storage group with logs named E01nnnnn.log without a problem).

Moving the databases by using an online backup is a more complicated approach than just copying .edb and .stm files from one location to another.

If you are restoring from an online backup to a different storage group, the destination storage group name and the logical database name must match the original names. The restore API queries the destination server to find out if it has a storage group and database matching the ones selected in the backup set. If a match is not found, the API assumes that you have selected the wrong server. This makes the restore operation straightforward in most instances because the administrator can select the restore server without having to specify anything else.

However, when restoring from online backup, you do not have to match the database file names on the destination server with the original file names. Exchange will actually rename the files on the backup tape to match the new file name if there is a difference. In other words, the name matching required when you restore from online backup is almost the opposite of that required when you use offline or file copy backups. When you use an online backup, the logical names of the storage group and database are critical, but the actual file names of the databases do not matter. With an offline backup, only the names of the files are important. The storage group and logical database names are unimportant.

After a database has been restored from online backup, at least one transaction log file must be committed to the database to make the database consistent (to put it into a Clean Shutdown state). You can be certain that this has happened after you have successfully mounted and disconnected from the database once. With the restored database disconnected, you can move the .edb and .stm files to a different storage group, if you want, by copying them into place (subject to the rules for moving copies of databases between storage groups).

If you are moving a database into a recovery storage group by using an offline backup or other file copy, the rules are exactly the same as when moving databases to an ordinary storage group.

If you are moving a database into a recovery storage group by restoring an online backup, the only naming rule is that one storage group on the server must have the same name as the original storage group from which the backup was taken. This matching name does not have to be the name of the recovery storage group.

This requirement exists because the restore API will end the restore operation if there is no matching storage group found on its initial query to a server. After a matching storage group is found, Exchange can redirect the restore appropriately to the recovery storage group. Therefore, when you restore from online backup to a recovery storage group, the logical and physical names of the storage group, database, or database files are unimportant. The critical naming factor is the value of the Active Directory attribute msExchOrigMDB. This attribute must match the original name of the database that you have restored from backup.

The rules for matching names of original and destination storage groups depend on two factors: How you move the database files (for example, using offline backups or normal file copies or restoring from online backup), and whether you restore to an ordinary storage group or to a recovery storage group. To summarize:

• If you are restoring from online backup to an ordinary storage group, storage group and logical database names must match, but actual database file names do not need to match.
  
• If you are restoring from online backup to a recovery storage group, you must have one storage group on the server that has the same name as the original storage group. This can be any storage group and not necessarily the recovery storage group itself.
  
• If you are restoring from an offline backup or file copy, actual file names must match, but storage group and logical database names do not need to match. This guideline is true whether you are restoring to a recovery storage group or to an ordinary storage group.