NMM supports Data Availability Groups (DAG) for high availability of Exchange Server 2010 and 2013 databases, with the following considerations:
· You must install the NMM client on each Exchange server that has the mailbox role installed.
· You can replicate each Exchange database to multiple Exchange servers, with a maximum of 16 copies.
· For Client Direct file access (DFA) backups, each client resource that you create on the NetWorker server for the Exchange client can contain a maximum of 10 mailbox databases. For example, an Exchange server that contains 20 databases requires two client resources that contain 10 databases each.
· Out of multiple copies of a database, only one copy of the database is active at a time. The remaining copies are passive.
· You can back up active databases, passive databases, or both.
· You can only restore backups of databases in a DAG environment to active database copies.
Exchange Server 2007 and 2010 VSS Writers:
Exchange Server 2013 VSS Writer:
Backups types and levels:
You can use the Microsoft VSS software provider with NMM to perform full and incremental backups for stand-alone and clustered databases. Ensure that the user for the Replication Manager Exchange Interface service is a member of the Organization Management Exchange security group. NMM supports the following backup types when you use the Microsoft VSS software provider:
· Point-in-time snapshot backup for FULL Level backups, with the Snapshot Policy “Backup Snapshot” option set to ALL
· Single server backup
· Virtual server cluster backup
· SCC backup
· LCR backup of the production data , but not of the replicated data
· CCR active node and passive node backup
DAG federated backups (Exchange Server 2010 and 2013 only):
NMM supports federated backups for Exchange Server 2010 and 2013 DAGs. Federated backups allow you to back up all databases in a DAG with a single save set across all Exchange Server nodes in the DAG. NMM do es not require you to perform a separate backup of each node.
NMM supports federated backups through a user-defined client resource that acts as a Coordinating Node. This client resource will manage and monitor the backup of all databases in its DAG. The client resource will point to the virtual DAG Exchange server in the DAG which will act as the Coordinating Node.
Application information attributes for federated backups:
– Add the NSR_FEDERATED_BACKUP application information attribute and specify “yes” as the value.
– NSR_FEDERATED_PSOL: Type a comma-separated list of the order in which to back up the databases on each server in the DAG. If you do not specify a list, the coordinating node will distribute the backups based on an unordered list of Exchange servers in the DAG.
– NSR_EXCH_INCL_SA: Type “False” to exclude public folders and stand-alone databases. The default setting is True.
– NSR_EXCH_BACKUP: Type one of the following:
o Passive: To back up only passive databases in the DAG.
o Active: To back up only active databases in the DAG.
o Preferred: To back up the passive copy or replica of each database if one exists. The Exchange server on which each passive database will be backed up will be determined by the preferred server order list. If no passive database exists (either there is no replica or if the current replica(s) are all suspended or dismounted), then the active database will be backed up.
Example of an Exchange Server 2010 and 2013 federated backup
Exchange Backup Task list:
· Task 1: Configure a backup pool.
· Task 2: Configure snapshot policies.
Add this attribute in the Client Properties > Apps & Modules tab > Application Information field when configuring the client resource NSR_EXCH_RETAIN_SNAPSHOTS=yes
· Task 3: Configure a backup schedule.
· Task 4: Configure a backup group resource.
· Task 5: Configure Exchange client resource.
· Task 6: Configure NetWorker administrator privileges.
NMM supports the following types of recovery:
· Roll-forward recovery
· Point-in-time recovery
· Database recoveries to Exchange RSG or RDB
· Remote database recovery for Exchange Server 2010 and 2013
· Mailbox item level recoveries from Exchange RSG or RDB databases
· Exchange RSG or RDB mailbox browsing, mailbox, folder, and message recovery
· Recovery to alternate storage group or alternate mailbox database
Point-in-time recovery of Microsoft SQL Server or Exchange Server
Use the following EMC NetWorker modules for backup and recovery of Microsoft servers and server applications:
- EMC NetWorker Module for Microsoft Exchange to back up and recover the Exchange Server.
- EMC NetWorker Module for Microsoft SQL Server to back up and recover the SQL Server.
NetWorker Module for Microsoft Applications to back up and recover Exchange Server, SQL Server, Office Sharepoint Server, and Data Protection Manager Server.
Best practices and recommendations Review the following best practices for Exchange backup and recovery:
* You can reduce backup time by spreading data across different storage groups.
* In addition to your scheduled full backups, you should also perform a full backup copy of Exchange Server after:
• Every successful recovery.
• Upgrading to NMM from previous releases of NetWorker clients.
• You change the database directory path or the Log Path or System Path.
* Ensure that you have mounted all databases before backing up the Exchange Servers.Unmounted databases are not backed up.
* For Exchange Server 2007, ensure that database (mailbox and public folder) files and transaction log files reside on separate volumes for backup. Also, ensure that the volume drive letter of the databases files is different from the volume drive letter of the transaction log files.
* If you delete Exchange objects like storage groups and databases in Exchange Server 2007 or databases in Exchange Server 2010 or 2013, you cannot recover these objects until you perform disaster recovery. Objects from the Exchange Server should not be deleted unless they no longer need to be recovered.
* After upgrading to the NMM client from the NetWorker Module for Exchange (NME), you cannot recover Exchange backups that were performed with NME. To ensure that you can recover all Exchange data to the point-in-time of the upgrade, perform a full backup of Exchange data immediately after upgrading to the NMM client.
* Save sets and backup groups that include the Exchange writer cannot include any other volumes, applications, or non-Exchange items in the save set.
* Exchange Management tools must be in stalled on a proxy host. The Exchange Management tools include the Exchange consistency checker utility Eseutil.exe which is required and used by the proxy host. Ensure that the version of Eseutil , including service pack level, installed on the proxy host is the same as that installed on the Exchange Server. For example, if Exchange Server 2007 is installed, then the version of Eseutil that is installed on the proxy host, must be from the Exchange Server 2007 management utilities. Otherwise, the consistency checker utility will report errors even when the database is valid.
Exchange recovery limitations Review the following limitations when backing up and restoring Exchange objects with NMM:
– For Exchange Server 2007, you cannot restore a single mailbox database using point-in-time recovery — A single mailbox database cannot be restored by using point-in-time recovery of Exchange, because it requires both logs and databases to be selected for restore:
• VSS-marking semantics do not allow selecting logs for backup or restore.
• Logs are included only when you select a storage group for backup or restore.
• Logs are not included when you select a database.
– Roll-forward recovery is not possible after point-in-time restore — After you complete a successful point-in-time restore, perform a full backup of the Exchange Server so that you can perform roll-forward recovers.
– No support for RSG configuration where the RSG system path restore location and RSG logs restore location are different — Although Microsoft Exchange Server supports an RSG configuration where the RSG system path restore location and RSG logs restore location are different, NMM currently do es not support that configuration. The location for the RSG system path and the RSG log path must be the same.
*MAPI memory errors when recovering mailbox items from RSG databases — There is a known memory error that may occur with Microsoft Exchange MAPI when recovering mailbox items from RSG databases. The error MAPI_E_NOT_ENOUGH_MEMORY may be reported in the NMM logs. When this error occurs, NMM recovers the mailbox item,but may lose properties such as the original font and formatting.This is a known problem, but Microsoft has no workaround or fix for this issue at this time.
· When performing Exchange Server backups, keep the following requirements in mind:
o After a snapshot of a save group starts, you cannot interrupt or halt the snapshot process. For example, in Exchange backup, the nsrsnap_vss_save.exe process on the production server and the Eseutil process on the proxy may continue to run after you halt the snapshot. Any attempt to stop a save group in NMC will take a long time to complete.
o When creating an RDB, do not include symbols. RDB item level recovery fails with an error if the folder name contains a symbol.
o When browsing an RDB, the log-in user mailbox or the user mailbox that you provided during NMM installation should reside on the mailbox server you are browsing. Otherwise, you might encounter browsing errors.
o NMM will only back up mounted databases. NMM does not display during the backup operation to indicate if any databases are unmounted. The NMM log files provide details about unmounted databases.
· To verify if a backup is successful, use the following command on the NetWorker client:
nsrinfo_nmm -s <Server> <Client Name> where the <Client Name> is the DAG name or Exchange Server 2010 or 2013 mailbox server name.
· You can use circular logging to limit the transaction logs stored on the system. However, incremental backups are not supported with circular logging enabled
· Conventional recovery: A conventional recovery recovers data that has already been rolled over to a backup medium. Conventional recoveries support the same level of item selection as instant recoveries.
· Instant recovery:Instant recoveries are performed with persistent snapshots. An instant recovery takes less time to complete than a conventional recove ry because the snapshot is available on a mounted disk storage volume rather than on a conventional backup medium. Instant recoveries support the selection of individual components at any level of granularity supported by the application writer
· Persistent snapshots enable quick recovery because recovering from a snapshot that is already available on the disk is much faster than recovering from a backup. However, retaining persistent snapshots consumes disk space. Non-persistent snapshots allow the backups to be retained much longer, but recoveries are slower.
· Do not perform a synthetic full backup, if the Save sets contain database systems such as Microsoft Exchange and Oracle.
· A Windows BMR backup does not back up the following files on a critical volume:
- Files listed in the FilesNotToBackup registry key
- Files excluded by system writers
- Files that are backed up by an application VSS writer, such as Exchange databases.
These files must be backed up with an application backup program such as NetWorker Module for Microsoft Applications (NMM).
· NetWorker Management Console (NMC) does not support VSS backups of Microsoft applications such as Microsoft Exchange, SQL Server, SharePoint Server, Windows Hyper-V, and so on. To fully protect these applications, you must use a product such as the NetWorker Module for Microsoft or another third-party product.
· When an error occurs while recovering Microsoft Exchange Server or Microsoft SQL Server data by using VSS, you must restart the recovery process. When the recovery fails due to a problem with VSS or a writer, an error message appears. Use the Windows Event Viewer to examine the event logs for additional information. VSS recovery error messages are also written to the NetWorker log file
· Post-recovery tasks when using an application backup tool other than NMM If you backed up a database application with an application backup tool other than NMM, perform the following post-recovery operations:
o Recover any required file system data by completing the steps in Post-recovery tasks to recover file system data.
o Recover the application data by using the application backup tool, such as NetWorker User for SQL Server, NME, or any third-party application backup tool. Refer to the documentation that comes with your application backup tool.