Exchange Server 2010 : Performing Backup and Recovery for Mailbox Server Roles

1. Volume ShadowCopy Service

Exchange Server 2010 only supports using Volume ShadowCopy Service (VSS) for backup and restore. Exchange 2007 or before also supported using Extensible Storage Engine (ESE) streaming backup APIs, but this option is no longer available in Exchange 2010. Therefore, the only way to create a backup of an Exchange database when it's online is by using the VSS interface.

1.1. VSS Backup Overview

VSS provides the backup infrastructure for Windows Server 2008 as well as a mechanism for creating consistent point-in-time data copies, which are known as shadow copies. The backup solution thus creates a shadow copy of the disk as the backup process begins. Then, Exchange Server creates the backup with the shadow copy rather than the working disk, so that backup does not interrupt normal operations. This method offers the following advantages:

• It produces a backup of a volume that reflects that volume's state when the backup begins, even if the data changes while the backup is in progress. All the data in the backup is internally consistent, and it reflects the volume's state at a single point in time.

• It notifies applications and services that a backup is about to occur. The services and applications, such as Exchange Server, therefore can prepare for the backup by cleaning up on-disk structures and flushing caches.

VSS produces consistent shadow copies by coordinating with business applications, file-system services, backup applications, fast-recovery solutions, and storage hardware. An architectural overview is shown in Figure 1.

Figure 1. VSS architecture

The VSS architecture consists of several components: namely Writer, Requestor, and Provider, as described in Table 1.

Table 1. VSS Components

VSS COMPONENT	DESCRIPTION
Writer	The VSS writer that is included with Exchange Server 2010 and that coordinates Exchange Server 2010's input/output (I/O) with VSS. Exchange 2010 comes with two VSS writers, one in the Exchange Store to backup active database copies and one in the Microsoft Exchange Replication service that can be used to back up passive mailbox database copies
Requestor	Backup or restore application, such as Windows Server Backup
Provider	Low-level system, software, or hardware interfaces, such as storage area networks (SANs)

The VSS components interact with each other to create a consistent backup of the disk. The following steps are completed for a VSS backup:

1. The requestor starts the backup by initiating the writer.

2. When the writer finishes its tasks, it notifies the requestor that the data is ready to do a backup.

3. The requestor then contacts the provider to notify the hardware to complete the backup.

4. After the backup is completed, the requestor notifies the writer so that the writer can allow database activity to resume.

VSS providers are available in two flavors: Hardware or Software VSS solutions. Hardware VSS solutions are available with SANs; software VSS solutions can be used against SANs or direct attached storage architectures. However, be aware that hardware VSS solutions mostly require a specific LUN architecture so that you have database and log files separated on two LUNs. For more information about VSS, see http://technet.microsoft.com/en-us/library/cc785914(WS.10).aspx.

1.2. Exchange Server Support for VSS Backup

To back up and restore Exchange 2010, you must use an Exchange-aware application that supports VSS backups for Exchange 2010, such as Windows Server Backup. Alternatively you can use a third-party backup solution that comes with its own VSS plug-in for Exchange Server 2010, such as Microsoft Data Protection Manager 2010, or a third-party, Exchange-aware, VSS-based application.

The VSS plug-in for Windows Server Backup that ships with Exchange 2010 has the following limitations:

• VSS support is at the volume level only, not the database level.

• VSS support is for full backups and copy backups, not for incremental or differential backups.

• Without using the registry key mentioned later in this section, VSS can only be used to back up volumes containing active mailbox database copies or non-replicated databases.

2. Using Windows Server Backup

Exchange Server 2010 now includes full Exchange VSS backup support for Windows Server 2008 and Windows Server 2008 R2. When you install the Mailbox server role on a server running Windows Server 2008, it also updates Windows Server Backup to support Exchange Server 2010. Windows Server Backup enables you to perform VSS-based backups of Exchange Server data without extra charge.

For many smaller organizations, Windows Server Backup provides a sufficient solution. However, larger organizations may require a more robust backup strategy because Windows Server Backup includes the following limitations:

• Backups are only performed at volume level; you cannot back up a single database only.

• There is no Exchange-only backup feature. You need to back up at least a complete volume to create an Exchange-aware backup.

• You can only perform full or copy backup, not incremental or differential backups.

• Windows Server Backup has no remote server backup functionality—it must run on the Exchange server that needs to be backed up.

• Windows Server Backup is only available for Windows Server 2008 or Windows Server 2008 R2.

• Windows Server Backup PowerShell cmdlets are not compatible with the Exchange Server 2010 VSS plug-in.

For more information about Windows Server Backup, see the Microsoft TechNet article "Using Windows Server Backup to Back Up and Restore Exchange Data" at http://technet.microsoft.com/en-us/library/dd876851(EXCHG.140).aspx.

2.1. Backing Up Your Exchange Server with Windows Server Backup

Windows Server Backup (WSB) is the right tool for backing up Exchange databases and servers if you have just a couple of Exchange servers installed in your environment and you do not require direct connection to a storage system such as a tape library. If the backup software that supports your storage system does not include Exchange 2010 plug-in, you can use Windows Server Backup to create a backup on a file share and then use your available backup software to store the data to your storage system.

Using WSB, you can create a scheduled backup set, meaning that you decide how often the backup is done, or you can create one backup. The next option you can configure is how WSB handles Exchange log file truncation. You can choose a VSS full backup, which removes the Exchange log files after the backup, or you can choose a VSS copy backup, which preserves the log files as shown in Figure 2.

Figure 2. Exchange log file truncation options

Keep the following general considerations and best practices in mind when using WSB for creating Exchange backups:

• You need to select the backup on the volume level; you cannot back up just the Exchange folder because this will not create a valid Exchange VSS backup.

• If your database files and the log files are on different volumes, you need to back up all volumes in the same backup job to create a valid Exchange VSS backup of your database.

• Out of the box, WSB does not support backing up a volume that includes active and passive mailbox database copies. If you attempt this, the Backup Status will appear as Complete With Warnings and you won't have Applications recovery type available when recovering. The recommended workaround is to make sure that your passive database copies are either stored on one Exchange server that you do not back up or use a separate volume for them. However, a tweak is available that allows WSB to back up volumes containing both active and passive database copies. This tweak forces WSB to use the Store Writer instead of the Replica Writer for backup; thus passive databases will be ignored. To implement the tweak, you need to perform the following two tasks on the servers where you have both active and passive databases:

  • Apply the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\Replay\Parameters\EnableVSSWriter set to 0 (DWORD type), as shown in Figure 3.

  • Restart the Microsoft Exchange Replication service.

  ---

  Note: If you later change to a backup solution that does support the Replication service VSS writer, such as Microsoft Data Protection Manage (DPM), you will need to remove the registry value and restart the Microsoft Exchange Replication service!

  ---

  Figure 3. Tweaking Windows Server Backup to ignore passive database copies

  

• Consider implementing Exchange-only volumes such as disk D: for all mailbox databases and their log files so that you can perform an Exchange-only backup.

• A backup cannot be stored on the same volume that you want to back up; you must always use a volume selected for backup or a remote shared folder as a backup target.

• You can only use mount points on Windows Server 2008 R2 computers. If you have Exchange 2010 installed on Windows Server 2008 SP2, mount points are currently not supported.

Selecting the correct volumes for backup is key to successfully backing up Exchange; Figure 4 provides basic guidance to what items you should select when backing up Exchange.

Figure 4. Windows Server Backup Select Items to back up

---

Note: Don't forget to always check the Application log in Event Viewer to verify that the Exchange backup was successful. For every Exchange database you should see Event ID 9780 for a non-replicated database or Event ID 9827 for a replicated database copy, and Event ID 224 for a successful log truncation.

---

2.2. Restoring Backups with Windows Server Backup

To restore a backup that was created with WSB, you can select a backup set available either on a local drive or on a remote shared folder. After you selected the desired backup set to recover, you need to select recovery type. For Exchange backups you must have the Applications option selected, as shown in Figure 5.

---

Note: If the Applications option is dimmed, the selected backup set is not a correct Exchange-aware VSS backup and thus can only be considered a file-level VSS backup. The most common reason for this is that you forgot to back up the volume containing the Exchange log files or you did not back up on a volume level but on a folder level.

---

Figure 5. Selecting the recovery type in WSB

After selecting the Applications option, you will see the available applications that are part of the backup set. You also can view details on what databases are available as part of the backup set, as shown in Figure 6.

Figure 6. Viewing Exchange application backup details in WSB

You can either recover to the original location or you can restore to another location, such as a local folder or network drive as shown in Figure 7.

Figure 7. Specifying the recovery location

2.2.1. Using Windows Server Backup to Recover to the Original Location

Recovering a backup set to the original location is quick and easy. If you selected the Applications option, you will recover all Exchange databases of that respective backup set to their original location. WSB will take care of dismounting the involved databases and mounting them again after the restore is completed. If the original location of the databases was changed, you cannot recover the databases anymore but have to use recover to another location.

---

Note: Restoring a backup set to the original location is a volume-level operation and thus does not require additional Exchange configurations such as selecting This Database Can Be Overwritten By A Restore on the Maintenance tab in the Database properties of EMC. However, you should consider a restore to the original location carefully because you might overwrite a database by mistake without even realizing it!

---

2.2.2. Using Windows Server Backup to Recover to Another Location

Alternatively, you can recover a backup set to another location such as a local drive or a network drive. Using the Applications Recovery Type in the Recovery Wizard, restore all Exchange databases to another local location, such as C:\Recovery, as the target folder. When the recovery is finished, the target folder will include the full folder structure including the database as well as log files for the databases.

Once the database is recovered, run the Eseutil /mh <database.edb> command to make sure that the database is in a clean shutdown state. If the state shows Dirty Shutdown, as shown in Figure 8, you need to additionally run the Eseutil /r e00 /i /d command to bring it to a clean state.

Figure 8. Verifying the state of a recovered database

Even though you can only recover all databases of a backup set using Windows Server Backup, with a few tweaks you can achieve the following:

• Recover a single database You need to dismount the respective database, then move all database and log files from the restored database folder to the database and log folder, and then mount the database again. Make sure the target folder is free of the existing database, log, and catalog files.

• Recover a database as a recovery database Move the recovered database and log files to a directory that is easy to reach, such as C:\RecoveryDB, and then create a new recovery database using the New-MailboxDatabase -Recovery -Name RecoveryDB -Server <server name> -EDBFilePath "C:\RecoveryDB\<database name>.edb" -LogFolderPath "C:\RecoveryDB" cmdlet. Don't forget to use the original database name of the recovered database and mount it using the Mount-Database RecoveryDB cmdlet. An example is shown in Figure 9.

  Figure 9. Creating and mounting a recovery database

  

---

Note: You can only recover mailbox databases to a recovery database. Public folder databases cannot use a recovery database!

---

3. Using Advanced Backup Solutions

If your company requires more functionality than available in WSB, you need to consider using an advanced backup solution such as Microsoft Data Protection Manager 2010 or other Exchange-aware, VSS-based backup applications from third-party vendors.

Such backup solutions provide you with the following advanced features:

• You can back up volumes containing active and passive mailbox database copies at the same time.

• You can back up and restore a single database or single database copies.

• You can restore a database into a recovery database or an alternate location.

• If the backup solution is from a hardware vendor, it includes advanced features to utilize the backup hardware.

---

Note: Passive database copies are backed up using a VSS writer in the Microsoft Exchange Replication service. The Microsoft Exchange Replication service VSS writer doesn't support restores; thus you can't perform a restore directly to a passive database copy. However, you can perform a VSS restore to an alternate location, suspend replication to the passive copy, and then manually copy the database and log files from the alternate location to the location of the passive database copy.

---

3.1. Considerations for Selecting an Exchange Server Backup Solution

When selecting a backup solution for Exchange Server 2010, you must consider your system's characteristics and those of the software and hardware. System characteristics to consider include:

• The amount of data you are backing up.

• The time window in which the backup can occur.

• The type of backup you are performing.

• Recovery time requirements.

• Archiving requirements.

• Budgetary considerations for the backup solution.

When you understand your system characteristics, you should consider how to select the backup software required. To help you with this, Table 2 describes some basic criteria for selecting the software that best meets your needs.

Table 2. Backup Software Selection Criteria

SELECTION CRITERIA	DESCRIPTION
Backup architecture	Your backup software should provide support for any operating systems that you have. Additionally, the backup software should be able to back up Exchange Server to your desired media, either on the local computer or over the network.
Scheduling	Your backup software should support the ability to schedule backups that you require for your organization. Most backup software allows you to schedule jobs at any time you require. However, this is easier to configure in some software packages.
Brick-level backup support	If desired, ensure that your software supports brick-level backups. Alternatively, consider implementing Single Item Recovery.
VSS writer for Exchange 2010 API support	Your backup software must support the Exchange Server Backup VSS API to perform online backups successfully.
Tape management	Different backup software has varying degrees of flexibility for tape management. This includes automated naming of blank tapes and preventing existing tapes from being overwritten accidentally. Also, as tape media is used it becomes less reliable. It is important to manage the number of times the media is used and replace it with new media.
Vendor support	Vendor support is essential if you experience any problems during disaster recovery. Ensure that vendor support is available for your backup software.
Disaster-recovery support	Some backup software has a disaster-recovery option that provides complete disaster recovery for a failed server, including Exchange Server.
Hardware support	Your backup software must support the technologies that your company uses, including clustering or SANs. The two most common types of backup hardware are tape and disk. Many organizations use disk-based backup as the first tier, and then utilize tape as a second tier. This allows you to perform primary backups quickly to disk. Typically, any data that you need to archive offsite is backed up to tape from the disk backup.

3.2. Data Protection Manager 2010 Overview

Microsoft System Center Data Protection Manager (DPM) 2010 is a backup and recovery solution that provides all advanced features for Exchange 2010. It can back up basic file and print servers and application servers.

DPM 2010 fully complements Exchange 2010 DAGs and provides protection against total data loss resulting from logical corruptions; it helps you preserve data for point-in-time restores beyond the 14 days that a Exchange 2010 lagged copy will allow. It provides a cost-effective means of storing data for long haul on tape to meet regulatory requirements. DPM 2010 supports and enhances DAG Continuity of Service SLAs by reducing RTO and RPO times and supports item-level recovery using Exchange Recovery Database.

DPM 2010 performs disk-based backups first, and then allows you to archive to tape. The first backup to disk is a complete copy of the server. The second snapshot captures only changes and writes them to disk. Multiple backup versions exist on the disk, but the tool only uses disk space equivalent to the first backup plus changes. This is similar to VSS in that it allows you to restore multiple versions of shared files on a file server.

VSS backups snapshot the entire logical disk, not individual files. However, you can restore specific information—such as files or an Exchange Server database—rather than an entire logical disk.

You can find more information about DPM 2010 and Exchange 2010 at http://blogs.technet.com/b/dpm/archive/2010/01/08/dpm-2010-protecting-exchange-2010-dag-in-a-single-site.aspx

Notes From The Field: DPM 2010 vs. Lagged Copies Todd Hawkins Senior Consultant, Dell Global Infrastructure Consulting Services, US South Central Region You can achieve the same point-in-time (PIT) recovery goal of a lagged copy with Microsoft Data Protection Manager (DPM) 2010. DPM can take PIT snapshots of your databases at up to 15-minute increments. When restoring to a PIT with lagged copies, you need to plan what logs are needed to get to the desired recovery point, suspend replication, delete the .chk file, and use Eseutil to replay logs. You may also need to write scripts to automate some of the process. With DPM, on the other hand, you choose the date and time you want to recover from very easily in the GUI. This leads to a faster RPO and less difficulty in disaster-recovery scenarios. In addition to being easy to use, DPM offers you more flexibility. For example, with DPM, you can move these backups to tape for offsite storage or for compliance reasons. In addition, you aren't limited to 14 days of PIT recovery—you are limited by the amount of storage you have available. DPM is not just an Exchange backup solution—you can use it to provide backup and recovery for file servers, Microsoft SQL, Windows SharePoint, and more.

3.3. Third-Party, Exchange-Aware Backup Solutions

Of course, more than just DPM 2010 is available to back up Exchange Server 2010. Many other third-party backup solutions are available that are Exchange-aware, such as Symantec Backup Exec 2010 and Commvault.

The list of Exchange-aware backup solutions is ever increasing. You can find a frequently updated Exchange 2010 Backup Product Support Matrix at http://chrislehr.com/2010/02/exchange-2010-backup-product-support.htm.

However, if you're already using a third-party backup solution, you should check with your vendor to make sure their solution supports Exchange Server 2010, including DAGs.

4. Dial Tone Recovery

Dial tone recovery is the process of implementing user access to e-mail services without first restoring data to user mailboxes. Dial tone recovery enables users to send and receive e-mail as soon as possible after a database or server loss. Users can send and receive e-mail messages, but they do not have access to the historical mailbox data.

Because your users can work with the dial tone database, you can recover the original database or server and restore the historical mailbox data without pressure. After you bring the recovered database back online, you can merge the dial tone database and the recovered database into a single up-to-date mailbox database.

4.1. When to Use Dial Tone Recovery

Use the dial tone recovery method when it is critical for users to regain messaging functionality as quickly as possible after a mailbox server or database fails, and when you cannot restore historical data from a backup quickly enough.

The loss may result from hardware failure or database corruption. If the server fails, you will need significant time to rebuild the server and restore the databases. If you have a large database that fails, restoring the database from backup may take several hours.

If the original mailbox server remains functional, or if you have an alternative mailbox server available, you can restore messaging functionality within minutes using dial tone recovery. This enables continued e-mail use while you recover the failed server or database.

4.2. Implementing a Dial Tone Database

Implementing a dial tone database should be carefully considered because it requires additional work to recover to the original situation. Consider the different dial tone recovery scenarios available such as using a different dial tone recovery server. However, all scenarios follow the same general steps:

1. Create the dial tone database. For messaging client computers to regain functionality as quickly as possible, create a new database for the client computers. Two methods are used for creating the dial tone database:

   1. Create the dial tone database on the same server as the failed database. Use this method if the drive that contained the database failed or if the database is corrupt.

   2. Create the dial tone database on a different server than the failed database. Use this method to utilize a different server as a recovery server or if the original server fails.

2. If necessary, configure the mailboxes that were on the failed database to use the new dial tone database. You must configure the mailboxes to use the new database if you create the dial tone database on a different server. To re-home all users from the old database to another, use the Get-Mailbox -Database <OldDatabase> | Set-Mailbox -Database <dial tone database> cmdlet.

3. Configure user profiles. If the server failed, you might need to reconfigure any user that is directly accessing the server (because you have multiple Exchange server roles hosted on a single server). Outlook profiles will be automatically updated.

   ---

   Note: At this point users can connect to their mailboxes and are able to send and receive messages. However, they will find an empty mailbox not including their historical data. If your client computers are using Outlook 2003 or later and run in cached mode, users receive a prompt to connect or work offline when they connect to the dial tone database. If users choose to connect to the server, they will see an empty mailbox (local cached copy is replaced with the empty mailbox). If they choose to work offline, they will see all of the historical data stored in the offline folders (.ost) file but will not be able to send or receive new messages.

   ---

4. Restore the failed databases from backup. After the dial tone database is operational and your users can continue to send and receive messages, you can work on restoring the failed database. In a dial tone recovery scenario you should restore the failed databases into a recovery database to the same or another server.

5. Merge the data in the two databases. Because you have restored messaging functionality by implementing the dial tone database, users will be sending and receiving e-mail while you are restoring the original databases. When the recovery is complete, users should be able to access both the original and the dial tone data. This means that you must merge the contents of the dial tone database with those of the original database. To do this, you will use the recovery database as mentioned in the next section.

5. Using the Recovery Database

The recovery database is a database that does not affect any other databases or mailboxes running on that server. It runs separately and is limited to one mounted recovery database per Exchange server.

Users cannot access the recovery database directly. Only administrators can access it to recover single items, folders, mailboxes, or complete databases. The recovery database replaces the recovery storage group from Exchange Server 2007. You need to use the EMS to create a recovery database.

After you restore a database to the recovery database, you can copy messages to a folder or merge them into user mailboxes. The recovery database has the following requirements and characteristics:

• The server must have enough free disk space to restore the database. Effectively, there must be enough total storage space on the server to store two database copies simultaneously—the original database and the recovered version.

• The recovery database does not support public folder databases.

To create and mount a recovery storage group, the following steps are necessary:

1. Use the New-MailboxDatabase –Recovery cmdlet to create a new recovery database.

2. Restore the database that you want to recover to the recovery database.
   

3. Mount the recovery database using the Mount-Database <database> cmdlet.

When your recovery database is mounted, you can take a look at what mailboxes are in the database by using the Get-MailboxStatistics –Database <recovery database> cmdlet or, if you also want to display the GUID for each mailbox, use the Get-MailboxStatistics –Database <recovery database> |ft DisplayName. MailboxGuid, ItemCount cmdlet as shown in Figure 10.

Figure 10. Listing mailboxes of a recovery database

If you want to recover the complete mailbox from the recovery database to its original location, use the Restore-Mailbox –Identity <mailbox> -RecoveryDatabase <RecoveryDB Name> cmdlet. This is common when you use dial tone recovery because dial tone recovery preserves all mailbox GUIDs.

---

Note: Recovery to the original folder location is currently only possible if the user's mailbox GUID in Active Directory matches the one in the recovery database. If the mailbox GUID is different because the mailbox was re-created, you need to use the mailbox GUID instead of the name and define a target folder to store the recovered folders.

---

To restore to an alternative mailbox (or to a different mailbox GUID) or target folder, you need to use the Restore-Mailbox -RecoveryMailbox <Name or MailboxGuid> -Identity <mailbox> -RecoveryDatabase <recoverydb name> -TargetFolder <DestinationFolder> cmdlet to perform this task. Remember, this requires you to define a destination folder where all the items and folders will be restored.

6. Recover an Exchange Server

When recovering a failed Exchange Server, you have several options. The option you choose determines the process that you use to restore the server. When you need to replace a failed server, you have the following options:

• Restore the server You can restore the server from a full computer backup set and then restore your Exchange Server information. When you restore a server, you are reproducing the server configuration, including the server security identifier. This option is feasible only if you have a full server backup, including the System State backup, and you have replacement hardware that is the same or very similar to the failed server.

• Rebuild the server This option involves performing a new installation of Windows Server and an Exchange Server 2010 installation in Recover Server mode, which gathers the previous settings from Active Directory and then restores your Exchange Server databases.

• Use a standby server You can use a standby recovery server as part of the Mailbox server recovery strategy. This option involves keeping recovery servers available with the operating system and other software installed. Having available standby recovery servers reduces the time you need to rebuild a damaged server.

So what is better, restoring the server or rebuilding the server? The answer depends on what kind of backups your organization is taking. If you are doing backups for bare metal recovery that include system state and all server data, restoring the server from a backup is probably the best idea provided that the hardware you are restoring to is comparable to the server that was backed up.

If you are only backing up specific volumes and no system state, the best option is rebuilding the server using the /m:RecoverServer switch to build the server using the information in Active Directory and then restoring the databases.

Running Exchange Server Setup with the /m:RecoverServer switch causes Setup to read configuration information from Active Directory for the server with the same name as that from which you are running Setup. After you gather the server's configuration information from Active Directory, the original Exchange Server files and services then are installed on the server, and the Exchange Server roles and settings that Active Directory stored are applied to the server.

---

Note: When you run Exchange Server Setup in Recover Server mode, it must be able to connect to Active Directory and read the Exchange Server configuration information that links to the name of the computer that is running Exchange Server. This means that the computer account still must exist in Active Directory. If you delete the computer account, you will not be able to restore the Exchange Server.

---

Follow these steps to restore a member server running Exchange Server 2010:

1. If the failed Exchange server was part of a DAG, you need to do the following:

   1. Verify whether there was a database copy on that server that had ReplayLagTime or TruncationLagTime configured. You can do this using the Get-MailboxDatabase –Server <server> | fl Name,*lag* cmdlet. If the server had a lag configuration, you should write down these settings so that you can configure the same lag configuration settings later.

   2. Remove all database copies from that server (obviously from Active Directory because the copies are no longer on the server). This can be done using the Remove-MailboxDatabaseCopy <database name>1\<server> cmdlet.

   3. Remove the server from the DAG configuration by using the Remove-DatabaseAvailabilityGroupServer -Identity <DAG> -MailboxServer <server> cmdlet.

2. Install Windows Server 2008 or later on the computer that you are rebuilding. Use the same computer name and drive volume letters as the failed server. Install any Windows Server 2008 service packs and software updates that the damaged server was running.

3. Reset the Active Directory computer account for the failed server. After resetting the account, join the computer to the domain.

4. Install Exchange Server on the computer by running Exchange Server 2010 Setup in Recover Server mode by running Setup /m:RecoverServer.

5. Recover all drives that contained Exchange databases or log files when restoring a Mailbox role server or recover all other role-specific information for other Exchange roles.

6. If the failed Exchange server was part of a DAG, you need to add it again to the DAG, configure all previously available database copies, and configure any ReplayLagTime or TruncationLagTime settings.

---

Note: The Recover Server mode installation can recover only server configuration data that Active Directory stores. This means that the rebuild may not preserve every custom setting or restore data, such as custom scripts, that may have existed on the failed server. Also it won't restore custom Client Access Server role settings. Therefore, you should be prepared to re-create any Exchange Server configuration settings or files that you cannot recover from Active Directory.

---

7. Backup and Recovery of Public Folders

The area of Public Folders is one of the most controversial topics of Exchange Server. In Exchange 2007 Microsoft first de-emphasized Public Folders, but because of customer feedback they added a public folder management interface with Exchange 2007 SP1. In Exchange 2010 Public Folders should also be considered in your backup and recovery strategy.

Although public folders can be on members of a DAG, you cannot use continuous replication to make database copies, nor do the Single Item Recovery or Hold policy features apply. You also cannot use a recovery database to recover a Public Folder database. Thus you cannot protect public folders in the same way you can protect mailbox items so you need to especially consider public folders and backup.

If your company is using Public Folders, you should consider the following recommendations to make sure you can recover public folders:

• Replicate Public Folders to at least another Exchange server.

• You can configure deleted item retention settings on a public folder database or public folder level. By default it stores all deletions for 14 days, as shown in Figure 11.

  Figure 11. Public folder database deletion settings

  

• Use the Recover Deleted Items option to recover items and folders that have been deleted (only available in Outlook—not in OWA)

If these features do not provide sufficient protection to your public folders, or you have other requirements such as governmental regulatory or company policy that dictate you to backup public folders to a long-term storage system, you should consider an additional backup solution that provides you with the features required.