Although Exchange limits the number of ordinary storage groups on a server to four, the recovery storage group does not count toward this limit. You can create a recovery storage group on a server that already contains four storage groups.

For best performance, place the recovery storage group on the same server as the original database that you are restoring. You can merge recovered data into a database from a recovery storage group database on a different server, but performance will be noticeably slower than it would be if both databases were on the same server.

Critical properties that you must set when creating a recovery storage group are:

• Name
  
• Transaction log location
  
• System path location
  

If you are restoring a database using an online backup (a backup created by Backup or another Exchange-aware backup application), note the name of the original storage group to which the original database belongs. You may need to use this name for the recovery storage group, according to the following criteria:

• If the original storage group does not exist on the server on which you are creating the recovery storage group, the recovery storage group must have the same name as the original storage group. For example, if you are creating the recovery storage group on a recovery server that has no other storage groups, the recovery storage group must have the same name as the original storage group.
  
• If the original storage group exists on the server on which you are creating the recovery storage group, the recovery storage group must have a different name. For example, if you are creating the recovery storage group on the server where the original database and storage group reside, the recovery storage group can have any name (other than the names that have already been used).
  

At the beginning of a restore operation, the Exchange online backup API verifies that a storage group exists on the target server with the same name as the storage group in the backup set. If this is not the case, Backup reports the following error:

The specified computer is not a Microsoft Exchange server or

its Microsoft Exchange services are not started.

Other backup agents may report different errors.

Existing backup agents work transparently with recovery storage groups. The API functions as if the restore operation is done to the storage group that matches the name in the backup set. However, restoration is actually redirected to the recovery storage group.

If a storage group with a name that matches the name in the backup set already exists on the server, the following error appears when you try to name the recovery storage group:

The object Storage Group Name already exists.

Enter a unique directory name for this object.

If this error happens, give the recovery storage group a different name. There are no further name restrictions.

Do not set the transaction log path to the same path as that of the transaction logs for another storage group on the server. In most cases, you can set the transaction logs to the same path as the intended database restore path. This advice contradicts the advice usually given for setting Exchange database and transaction log paths.

For best performance on a typical Exchange server, the transaction logs and databases should be separated on different physical drive sets. However, in the recovery storage group, almost no information is written into a database—you are only reading data to salvage it. This lack of database activity means that there is minimal transaction log activity and any new log files that are created will not be useful in the recovery operation. Therefore, the placement of transaction logs for the recovery storage group seldom affects performance.

Some recovery scenarios involve copying or moving recovery storage group data files from one location to another. In such scenarios, it is not essential to set all data paths for a recovery storage group to a single location, but doing so makes it easier to manage and inspect the files. The most common recovery scenarios are discussed in detail later in this document.

Exchange uses the directory listed in System path location for checkpoint files (see Figure 2.2.) In most cases, you should set this directory to the same directory as the transaction logs. Although there is no harm done by setting a different path, doing so unnecessarily complicates troubleshooting and file management.

Although you are not required to do so, it can be more convenient to run Exchange System Manager on the server on which you intend to create the recovery storage group. Doing so makes it easier to verify and examine data paths and then decide where to place data files for the recovery storage group. You do not have to be at the server console to do this. You can use a remote desktop session.

Note:
You cannot create a recovery storage group on both Exchange virtual servers in a two-node cluster. In active/passive multi-node clusters with more than two virtual servers, you can create recovery storage groups on multiple virtual servers.

Major considerations when adding a database to a recovery storage group are:

• Database name
  
• File locations for the Exchange database and streaming database
  
• Overwrite setting
  

You can name a database in the recovery storage group anything that you want. If you restore an online backup of the database, it restores correctly with that name, even though the name might be completely different from the original name.

Important:
This guideline applies to the logical database name, not the names of the database files themselves. For information about database file names, see "Database File Locations" later in this topic.

This behavior differs from restore behavior to an ordinary storage group. In an ordinary storage group, you can only restore an online backup if the name of the database in the backup set matches the logical name of a database on the restore server. (The logical name is the name of the database object as seen in Exchange System Manager.) But the rules are different for a database in a recovery storage group. As described earlier in this document, each recovery storage group database has an attribute called msExchOrigMDB. This attribute links the recovery storage group database to the original database.

Because the database names can be different, you can give the recovery storage group database a name that distinguishes it from the original database. For example, it may be convenient to add a suffix to the name of the recovery storage group database. Without a suffix, you may see the database name twice in some administrative lists and thus will find it difficult to distinguish between the original database and the recovery storage group database.

You have four primary considerations when deciding where to restore the database:

• Disk space   You may not have sufficient disk space on the drive on which the original database exists to restore a copy. Planning for sufficient disk space on each database drive might seem like an extravagant waste of disk space, but it is a best practice for several reasons.
  First, if an existing database is damaged and cannot mount, you can move or rename the damaged database before you begin restoring from backup. If you do not have enough disk space to do this, you have two alternatives: You must delete the existing database before restoring from backup, or you must take the time necessary—often hours for large databases—to copy the database to another disk before you can begin restoring from backup.
  Second, offline defragmentation of a database works by creating a second copy of the database that has been purged of empty pages. If you do not have enough room on the same drive for this second copy, you must defragment the database on a different drive and copy the defragmented database back to the original drive. This activity can extend defragmentation time by several hours for a large database.
  The trade-off for not keeping sufficient free disk space for such operations is increased downtime or increased risk when recovering from a disaster or when performing offline maintenance operations.
  
• Performance   Restoring a copy of the database to the same drive as the original database has some affect on performance. The performance degradation is often unnoticeable to end users, but it may be significant depending on your particular hardware and configuration.
  
• Intended recovery strategy   As a general rule, if your recovery strategy involves copying the recovery storage group database back to its original storage group location, try to place the recovery storage group database on the same logical drive as the original database. Doing this will allow you to move the database back into its original place in only a few seconds, regardless of the size of the database files. This can reduce the time for completing all recovery operations by several hours.
  
• File naming   The default file name for the database that is suggested by Exchange System Manager may or may not match the file name for the database in the original storage group. Use the following rules to determine what file name to use:
  
  • If you are restoring from an online backup, the file names do not have to match. Exchange automatically renames the files restored from online backup to match the names in the recovery storage group.
    However, if you intend to move these files from the recovery storage group back into their original storage group, the file names must match those names defined for the destination database in Exchange System Manager (listed in the Database tab of the database Properties dialog box). If you did not use the same file names when creating the database in the recovery storage group, you must manually rename files before moving them. Otherwise, Exchange will not recognize them as belonging to the appropriate database.
    
  • If you are restoring an offline backup or file copy database to the recovery storage group, the file names defined for the recovery storage group database must match the file name for the database in the original storage group. Because you are not using the Exchange online backup interface, Exchange only recognizes the files as belonging to the correct database if the filenames match.
    
  As a general rule, it will be less confusing and you will be less likely to make mistakes if you name the databases correctly as you are creating the database objects, rather than renaming the actual files later.
  

When you add a database to a recovery storage group, leave the This database can be overwritten by a restore check box selected. The important thing to remember about this check box is that if you restore the same database to the recovery storage group a second time, you will have to mark this check box again before you can mount the second restore of the database. If you fail to do this, no harm is done, but Exchange reminds you of what to do by displaying this error message:

The database files in this store were replaced with older versions by an offline restore. To use the restored files, open the Database property page for this Store, select 'This database can be overwritten by a restore', wait for Active Directory replication, and then try again.ID no: c104173a

You should not add the same database to more than one recovery storage group in your Exchange organization at a time. If you configure the same database in recovery storage groups on two different servers, confusion will result for both the backup API and for ExMerge. You may then be unable to restore the database or extract data from it until you delete one of the duplicate recovery storage group databases.

After you have decided on file names and locations, you can add the databases to the recovery storage group. This operation creates the logical database structure in Exchange.