Exchange 2007 provides additional flexibility with regard to how you can recover mailboxes. This flexibility is made possible using features such as the recovery storage group. You can also help protect mailbox data on the client side with the Cached Exchange Mode feature of Microsoft Office Outlook 2007.

Note:
Your ability to help your users protect their mailbox data is enhanced when your clients are using a client application that supports client-side caching.

Consider implementing one or more of the following strategies to help you be prepared to recover individual mailboxes or individual items:

• Server-side deleted item retention   In this method, you help protect mailboxes from accidental item deletion through the clients by saving deleted items before purging them from a mailbox. You can customize the deleted item retention period for your users. For information about the best practice of configuring deleted item retention periods, see Best Practices for Minimizing the Impact of a Disaster.
  
• Server-side reconnect of a deleted or orphaned mailbox   In the case of deleted or orphaned mailboxes, you can reconnect them to a user account using the Exchange Management Console or by using the Exchange Management Shell. You can customize the time that deleted or orphaned mailboxes can be retained on the server. For information about the best practice of configuring mailbox retention periods, see Best Practices for Minimizing the Impact of a Disaster.
  
• Restoration of backups performed at the mailbox level   In the case of a damaged mailbox, you can restore a user's individual mailbox from backup.
  

  Note:
  If your users are using client-side caching of mailbox data such as Cached Exchange Mode, they should have a local copy of their mailbox data on their computer.

• Recovery storage group   With the recovery storage group feature in Exchange 2007, you can mount a second copy of an Exchange mailbox database on the same server as the original database or on any other server that is running Exchange in the same Exchange administrative group. This action can be performed while the original database is still running and serving clients. With this capability, you can recover data from an older backup copy of the database without disturbing user access to current data. The recovery storage group can also be useful in various disaster recovery scenarios, most notably the messaging dial tone scenario.
  
• Third-party brick-level backups   Some third-party backup tools let you back up and restore Exchange at the level of individual mailboxes.
  
• Alternate server method   This method requires that you restore an entire database to a server outside of your production environment and that you extract the mailbox data that you want. Although this method is still valid, whenever possible, you should use the recovery storage group method.
  

When your Exchange data becomes damaged or is lost in a disaster, you must recover it from backup. There are several cases in which restoring from backup may be necessary, including:

• Corruption of one or more databases in a storage group   In this case, the native single-database restore functionality of Exchange can usually be used to restore the damaged databases without interrupting access to other databases on the same server.
  
• Hardware failure that causes loss of access to transaction logs or databases   In this case, you may have to recover all storage groups, including their associated logs and database files.
  
• Failure or damage to a mailbox or public folder server that requires the server to be rebuilt   In this case, disaster recovery frequently requires rebuilding the underlying server and its operating system.
  

Individual databases in a storage group may be restored while all other databases remain online. This method is the preferred means of replacing a single failed database. When the database is remounted, pertinent transactions are automatically played back from the storage group's log files to bring the restored database back to the time of the disaster.

When you use Backup to restore Exchange databases, API calls are made to the Exchange Extensible Storage Engine (ESE) to restore Exchange database files and their associated log files. You can use Exchange database backups to restore one or more damaged mailbox stores or public folder stores. You can also use Exchange database backups to restore every mailbox and public folder on the server. In a disaster recovery scenario that involves rebuilding a server, use Backup to restore your Exchange databases after you run Exchange Setup and any Exchange service packs in Recover Server mode (assuming that Active Directory is still available).

Exchange 2007 supports hardware-based snapshots using the Volume Shadow Copy Service (VSS) implemented in Microsoft Windows Server 2003. Generally, it takes much less time to restore a backup that was taken using a hardware-based snapshot. Therefore, depending on the hardware and software that was used in the solution, restoring Exchange data from these types of backups may make it easier to meet the elements of your service level agreement (SLA) requirements that relate to the time that it takes to restore Exchange databases. Additionally, because larger databases can be restored more quickly, hardware-based snapshot restores can help you support larger database sizes and still let you meet your SLAs for restoring Exchange data.

To provide more flexibility when restoring mailboxes and mailbox stores, Exchange 2007 provides a feature named the recovery storage group. The recovery storage group is a specialized storage group that can exist alongside the regular storage groups in Exchange, even if the server already has the maximum number of regular storage groups. You can restore Exchange 2007 mailbox stores from any storage group in the Exchange organization.

After you restore a mailbox store to the recovery storage group, move the recovered mailbox data from the recovery storage group to the regular storage group. With this method, you can recover an entire mailbox store, which includes all the database information, including the log data, or just a single mailbox. Mailboxes in the recovery storage group are disconnected and are not accessible to users who have mail clients.

Note:
You can only use the recovery storage group to recover mailbox stores, and not to recover public folder stores.

The recovery storage group also makes it possible to offer dial-tone service quickly after a failure. This capability means that users can create and receive mail while their existing data is being restored. Frequently this approach is the fastest way to restore mail service to users. Because the volume of data generated by the users is likely to be less than the amount of data in the existing database, merging the dial-tone mail data into the original store after it is recovered is faster than moving the original database contents to a new store. When correctly used, the recovery storage group can be a powerful tool for reducing outage times.

Consider the following information before you perform specific recovery procedures in the Exchange 2007 organization:

• Determine the time that is required to restore and play transaction log files. Performance in your environment may vary significantly from the average, and you should consider log replay in addition to restore time. If you perform weekly Normal backups and daily Incremental backups, you may have thousands of transaction log files that require replay after a restoration.
  
• To minimize the time that it takes to recover an individual database, configure storage limits for the mailbox and public folder stores to constrain databases to a maximum size limit.
  
• To back up Exchange data using the ESE streaming backup APIs or a VSS-based solution, the database must be online. You can still back up an offline database manually. However, in that event, manual checksum verification is required. In addition, performing an offline backup of Exchange involves an interruption of service to clients.
  
• You can back up and restore databases in a storage group individually or simultaneously. As long as you do not exceed the data bandwidth capacity of your hard drives, controllers, and backup hardware, you can save time by simultaneously running multiple instances of Backup to back up or restore databases.