Understanding Recovery Storage Groups
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
The recovery storage group (RSG) is a special administrative storage group that enables you to mount a mailbox database, extract data from the mounted database, and then either copy the extracted data to a folder in an existing mailbox or merge the extracted data with an existing mailbox. In previous versions of Microsoft Exchange Server, the task of extracting data from a mailbox database that was mounted in an RSG was accomplished by using the Microsoft Exchange Server Mailbox Merge Wizard (ExMerge) tool. In Exchange Server 2007, the data extraction is accomplished by using the Exchange Management Shell Restore-Mailbox cmdlet, or the Exchange Disaster Recovery Analyzer (ExDRA) tool.
This topic covers the following:
How an RSG differs from a storage group.
When you can use an RSG.
When you should not use an RSG.
What permissions are required to use an RSG.
What data can be recovered from a database that is mounted in an RSG.
How data is recovered using an RSG.
How mailboxes are matched to production database users.
An RSG can be used in many different scenarios. This topic focuses on using an RSG in the following scenarios:
Same server dial-tone recovery Set up a dial-tone database, and then later perform a recovery from an RSG after the original database has been recovered.
Alternate server dial-tone recovery Use an alternate server for a dial-tone database, and then later recover data from an RSG after the original database has been recovered.
Mailbox recovery Recover a mailbox from backup. You then extract data from a deleted mailbox and copy it to a target folder or mailbox in the active database.
Specific item recovery Search for information that has been lost (either deleted or purged) in the current active mailboxes, but is in a backup. For example, recovering messages during a legal inquiry.
How a Recovery Storage Group Differs from a Storage Group
An RSG is similar to a storage group; however, there are some significant differences. Several of the functions of a storage group are disabled for RSGs. RSGs differ from storage groups in the following ways:
All protocols except the Messaging Application Programming Interface (MAPI) are disabled. Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), and Internet Message Access Protocol 4 (IMAP4) are all unavailable for mailbox databases in an RSG. Therefore, mail cannot be sent to or from a database in an RSG. This design prevents the RSG from inserting mail into or removing mail from your Exchange system.
MAPI access is supported by an RSG, but the mailboxes cannot be accessed via Microsoft Outlook or Outlook Web Access.
Mailboxes that are in a database that has been mounted in an RSG cannot be connected to Active Directory directory service accounts. These mailboxes have to be merged into existing mailboxes, or copied to a folder in an existing mailbox.
System and mailbox management policies are not applied. This design prevents items in an RSG from being deleted by the system while you are trying to salvage them.
Online maintenance does not run against databases in an RSG, which eliminates the effect of such intensive operations on server performance.
Databases in an RSG cannot be set to mount automatically when the Exchange Information Store service is started. You must always start the databases manually. If mounted at the time of a cluster failover, databases will not mount automatically after failover is completed.
There is no support for changing data paths or moving data files after initial creation of an RSG. You must delete and re-create the RSG to change paths, or move files manually to desired locations.
Public folder databases cannot be mounted in an RSG.
Only a single RSG is supported per server as opposed to a maximum of 50 normal storage groups per server.
Different versions of Exchange have different maximum numbers of mountable storage groups; however, no version will have more than 50.
You cannot configure an RSG for replication by using cluster continuous replication or local continuous replication.
An RSG can be used as a target for database restores, but it cannot be backed up.
When You Can Use a Recovery Storage Group
The RSG is designed for mailbox database recovery under the following conditions and scenarios:
The logical information about the storage group, database, and the mailboxes in the database remains intact and unchanged in Active Directory.
You need to recover a single mailbox, a single database, or a group of databases in a single storage group. Recovery scenarios include:
Recovering or repairing an alternate copy of a database while another copy remains in production, with the goal of merging the two databases.
Recovering a database on a server other than the original server for that database. If needed, you can then merge the recovered data back to the original server.
Recovering deleted items that users deleted from their mailboxes, which they now need.
If you want to recover more than one database at a time, you can add multiple databases to an RSG as long as they are all from the same original storage group. After you have added the first database, you can only add databases from that database's storage group. Otherwise, you must use more than one server, because each server can only host one RSG.
When You Should Not Use a Recovery Storage Group
RSGs are not appropriate to use under the following conditions:
You have to recover public folder content. Only mailbox databases are supported.
You have to restore entire servers, one storage group at a time.
You have to restore databases from multiple storage groups.
You are in an emergency situation that requires changing or rebuilding your Active Directory topology.
Permissions Required to Use the Recovery Storage Group
To export content to a target mailbox, the account running the migration will need permissions on the server where the RSG is mounted, on the target server, and on the server where the target mailbox is located.
To recover content from an RSG, the account used to run the Restore-Mailbox task must have either of the following permissions: Exchange Full Admin (organization-wide) or Exchange Server Admin (on the source server).
For the server where the target mailbox resides, the account must have either of the following permissions: Exchange Full Administrators (organization-wide) or Exchange Recipient Administrators (on the target server).
What Data is Salvageable Using the Recovery Storage Group
Entire mailboxes can be extracted from databases mounted in an RSG, including all item types, normal folders, and special folder content (such as hidden folders and notes). The format, names, and values of the content are preserved. The following items are included in a mailbox and can be extracted:
All visible and hidden folders and the folder structure.
All message types (including messages, calendar items, contacts, distribution lists, journal entries, tasks, notes, and documents).
The content from the special folders will be merged into existing special folders that exist in a mailbox. If a special folder does not already exist, the folder will be created based on what is in the mailbox. Special folders are ignored if the content is copied to a subfolder in mailbox.
Special content (search folders, dumpster, and calendar items) will have special handling to ensure no duplicates or loss of functionality.
How Data is Recovered Using a Recovery Storage Group
When you recover data from a database mounted in an RSG, you have two options for data you extract from the database:
Merge with a mailbox You can merge the entire recovered mailbox, or a filtered subset of data from the recovered mailbox, with an active mailbox. This option adds, and does not overwrite, the data in the active mailbox.
Copy to a subfolder You can copy the entire recovered mailbox, or a filtered subset of data from the recovered mailbox, to a subfolder in the active mailbox.
When recovered data is merged with a mailbox, all data will be merged except for rules, search folders, and any items that already exist in the mailbox.
- Merge means that each item is copied from the mailbox database mounted in the RSG to one or more mailboxes in a regular storage group and then compared with existing mail that may already exist in the target mailbox. What is currently in the target mailbox is considered to be the best copy, and it will be preserved. Merging allows for the ability to filter data, recover only specific data, and to merge the recovered data into existing mailboxes.
How Mailboxes Are Matched to Production Users
There are two parameter sets for the Restore-Mailbox cmdlet:
**Merge mode ** You may specify the identity of a user mailbox as the target mailbox. Then the target mailbox’s GUID is used to match the mailbox in the RSG database.
Copy-to-folder mode You may specify the identity of a user folder in the target mailbox. The source RSG mailbox is identified by the parameter RsgMailbox, which accepts the following user attributes to match data:
MailboxGuid The Exchange Mailbox GUID of the mailbox to recover.
**LegacyExchangeDN ** The full LegacyDN of the mailbox to recover such as '/O=First Organization/OU=First Admin Group/Cn=Recipients/CN=Jim.
Limitations of Recovery Storage Groups
Before using RSGs, be aware of the following limitations:
The Exchange 2007 RSG does not support mounting mailbox databases from previous versions of Exchange Server.
The target mailbox must be in the same forest as the mailbox database that is mounted in the RSG.
You cannot mount a public folder database in an RSG.
A server can only have one RSG at any given time.
Folder access control lists (ACLs) will not be preserved when recovering content into an active mailbox. Because the process for RSG is to recover the mailbox database and merge the new content back into the original database, there should be no need to copy ACLs.