Manage protected Exchange servers
Updated: May 13, 2016
Applies To: System Center 2012 SP1 - Data Protection Manager, System Center 2012 - Data Protection Manager, System Center 2012 R2 Data Protection Manager
General Exchange maintenance tasks might affect your DPM backups. Note the following best practices:
If you need to perform maintenance on a protected server and do not want protection jobs to continue for the duration of the maintenance, you can disable the protection agent.
If you disable a protection agent for a server that is a cluster node, you should disable the protection agent for every node of the cluster.
We recommend you don’t change the name of a protected server. You can’t change the name of a protected Exchange server and continue protection without disruption. You also can’t change the name of a protected computer and associate the existing replicas and recovery points with the new computer name. If you do need to change the name, remove the data sources from the protection group and then protect the data source on the newly named server.
If you add a new storage group to a protected Microsoft Exchange server, you must add it to a protection group manually. When adding a new database to the storage group, a full backup is required, which can be accomplished by an express full backup or a consistency check. Incremental backups will fail until a full backup is completed.
If a database in a DAG on which express full backup is configured goes down temporarily and returns back then you do not have to perform any action.However if it goes down for a longer duration, then the backups will fail and Exchange Server will be unable to truncate log files for that database. Also the respective DAG node on which the database exists may run out of disk space.
When a database that belongs to a protected storage group is dismounted, protection jobs for that database only will fail. Logs for that storage group will not be truncated. However, the longer that the database remains dismounted, the more likely it is that the log space on the Microsoft Exchange server will overflow, which will result in the dismount of the storage group on the Exchange server. If the database will not be needed, you should delete it.
If protected databases or log files are moved to a volume that contains data that’s protected by DPM then protection continues. Otherwise DPM displays an alert and protection jobs will fail. To resolve the alert, in the alert details, click the Modify protection job link and then run a consistency check.
If a recovery point is created after the path changes you can’t recover the storage group or recovery points from recovery points based on the old path. You can still recover data to a network folder
If you recover an Exchange 2007 storage group after the path for databases or log files has changed and the most recent recovery point was created before the path changed, DPM will recover the databases to the new location.When you change the path of log files for a storage group that uses disk-to-tape backup and only incremental backups have been performed since the path change, recovery of a storage group using Latest as the recovery point will fail. To avoid this issue, perform one of the following actions:
Run a full backup and then retry the storage group recovery.
Recover individual databases, rather than the storage group.
Recover the storage group to a network folder as files.
. If you recover a Microsoft Exchange 2003 storage group after the path for databases or log files has changed and the most recent recovery point was created before the path change, the recovery copies the files to the old path and tries to mount the databases. If the databases can be mounted, the recovery appears to succeed. If this occurs either change the databases back to the original path and recover the storage group again, or recover the databased using copy to network folder and specify the new location as the destination. Select to bring the database to a clean shutdown after copying the files. Then mount the database after recovery.
If you move databases between storage groups DPM behaves as follows:
If you move from protected storage group to protected storage group then DPM stops protecting the database. Run a consistency check for the protected storage group after the move.
If you move from a non-protected storage group to a protected storage group then protection begins if the databases are on a volume protected by DPM. If they’re not run the Modify Group Wizard. Run a consistency check for the protected storage group after the move.
Recover the storage group to a network folder as files.
The time required for DPM Recoverable Object Search to return recovery points that meet the specified criteria increases as the number of recovery points grows and as the DPM database (DPMDB) becomes more fragmented. You can reduce the search time by performing regular maintenance on the DPM database.To improve the performance of the recovery point search for a data source, you need to rebuild or reorganize the indexes related to that data source. Rebuild these indexes for specific data source.
SharePoint—Tables: tbl_RM_SharePointRecoverableObject; tbl_RM_RecoverySource
Exchange mailbox—Tables: tbl_RM_DatasetROMap; tbl_RM_RecoverableObject; tbl_RM_RecoverySource
If you rename a protected mail box stop protection for the mailbox with Retain Data and then reprotect the database. Note that if you try to recover to original location from recovery points created before the rename it will fail. Revert to the old name if you need to do this.
If you must perform an offline defragmentation, you should perform a synchronization with consistency check for protected storage groups when defragmentation is complete.
When you make changes to a server cluster that is protected by DPM, DPM takes the following actions:
When a new server is added to a cluster, DPM issues an alert to install a protection agent on the new cluster node and protection fails.
When a server is removed from a cluster, DPM detects that a node has left the cluster and the server now appears separate from the cluster with no data protected on it.
A cluster node can have any number of resource groups. Moving a protected data source to a resource group, between resource groups, or out of a resource group can cause protection job failures. To successfully make any of those changes to resource group membership, stop existing protection of the data source and begin protection of the data source according to its new status, either as a single data source on a protected server or as a data source as a member of a resource group. This will allocate a new replica for the data source. If you change the name of a resource group stop protecting it, change the name, and then begin protecting under the new name.