IBM Support

Enhanced data protection for Microsoft Exchange Database Availability Groups (DAGs)

Product Documentation


Abstract

Enhancements in data protection agents that provide protection for Microsoft Exchange Database Availability Groups (DAGs) are described.

Content

Database Availability Group overview

The Database Availability Group (DAG) is the base component of the high availability and site resilience framework built into Microsoft Exchange 2010 and 2013. When working in a DAG environment, here are some topics to consider:

  • A group of up to 16 mailbox servers can host up to 100 mailbox databases.
  • Up to 16 online copies of a database (1 active database and up to 15 passive databases).
  • Replication through log shipping.
  • Synchronous or lagged replication.
  • Automatic migration and failover of active database copies.

Sample DAG configuration

DAG members often hold a subset of the Exchange databases in a combination of active and passive copies to optimize use of available server resources.

In the following example configuration, there are three copies of five databases spread across five servers in a DAG. This configuration ensures that no two server in the DAG have the same set of database copies. The configuration also provides greater resilience to failures. Specifically, three servers must fail before losing access to a database.

Backup solutions

You can back up data from any DAG member and restore the data to any DAG member. You can also back up data from either the active or passive copy. Full and incremental database backups do not need to be completed from the same DAG member. All databases included in a VSS type backup are snapped together.

When backing up data, provide options from backup deployment. You want to distribute the backup workload for scalability and isolate backup activity to a dedicated backup node. Isolating backup activity minimizes the impact to production databases.

Ideally, avoid redundant backups of the same databases. Recognizing all replicas as copies of the same database helps achieve this goal. You can also apply retention policies to "unique" databases.

Allowing backups from any node in the availability group and enabling restores from any node in the availability group is also ideal.

Achieving goals with the Data Protection for Microsoft Exchange Server component

The DAGNODE parameter provides a common namespace for all backups. Each node authenticates separately with Tivoli Storage Manager. The backup data is stored in DAGNODE namespace using the Asnode option.

To indicate that a backup is taken from a passive copy unless no healthy passive copy is available, use the PREFERDAGPASSIVE parameter.

If the Exchange Server databases belong to a DAG and are an active database copy, the EXCLUDEAGACTIVE parameter excludes the databases from the backup.

If the Exchange Server databases belong to a DAG and are a passive database copy, the EXCLUDEDAGPASSIVE parameter excludes the databases from the backup.

To specify the minimum amount of time before a backup of another DAG copy of the another DAG copy of the same database is allowed, use the MINIMUMBACKUPINTERVAL parameter.

The synchronization mechanism between the Data Protection client instances on the same DAG ensures that two nodes do not simultaneously start a backup of the same database.

Sample data protection deployments in DAG environments

The following figure illustrates a deployment of a backup task that is distributed across DAG members.


To schedule a CMD type backup on all DAG nodes, the command file contains separate backup commands per database. For example:
    tdpexcc backup DB1 full /minimumbackupinterval=60 /preferdagpassive
    tdpexcc backup DB2 full /minimumbackupinterval=60 /preferdagpassive
    tdpexcc backup DB3 full /minimumbackupinterval=60 /preferdagpassive

In this deployment, there is one schedule and the same backup command file is used on each node.

The following figure illustrates another possible deployment of a backup distributed across DAG members.



In this deployment, one schedule and the same backup command file name is used on all nodes. The command file contains separate backup commands per database on that node. For example:
    tdpexcc backup DB1 full /minimumbackupinterval=60 /preferdagpassive
    tdpexcc backup DB2 full /minimumbackupinterval=60 /preferdagpassive
    tdpexcc backup DB3 full /minimumbackupinterval=60 /preferdagpassive

Again, note that each line is different per node.

[{"Product":{"code":"SSTG2D","label":"Tivoli Storage Manager for Mail"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Data Protection for MS Exchange","Platform":[{"code":"PF033","label":"Windows"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB26","label":"Storage"}}]

Document Information

Modified date:
17 June 2018

UID

swg27041232