A Database Availability Group protects Exchange mailbox service from certain database, disk, server and network failures by maintaining database copies across Mailbox servers. It does not protect every failure and it does not replace a recoverable backup.

Design from failure outcomes, not from a desired number of copies.

Define recovery objectives

For each service/data class, record:

  • maximum acceptable outage;
  • maximum acceptable data loss;
  • site or failure domains to survive;
  • time to provide temporary messaging service;
  • retention/item-recovery needs;
  • dependency on identity, DNS, certificates, load balancers and network; and
  • who may declare failover or disaster recovery.

A DAG can meet a short database-service objective while a deleted item, corrupt application action or lost Active Directory still needs another recovery route.

Map the failure scenarios

At minimum consider:

  • one database copy fails;
  • one disk/volume fails;
  • one Mailbox server fails;
  • network partition or witness loss;
  • one datacentre/site fails;
  • logical corruption replicates;
  • mailbox/item deletion;
  • ransomware or administrative compromise;
  • entire server needs rebuild; and
  • backup must restore historical data.

For each, identify detection, automatic/manual response, data source, dependencies, expected service interruption and return-to-normal procedure.

Design the DAG as a replication system

Microsoft describes a DAG as up to 16 Mailbox servers and the boundary for database replication, switchovers/failovers and Active Manager. DAG members must run the same Exchange version.

Plan:

  • member placement across power/network/storage/site failure domains;
  • database copy count and activation preference;
  • witness placement and quorum behaviour;
  • network latency/bandwidth;
  • replay/truncation lag where justified;
  • database/log capacity and reseed time;
  • load balancer/client-access behaviour; and
  • operational patch/maintenance sequence.

Do not place “independent” copies on shared storage, power or networking without recording the common failure.

Understand what replication cannot recover

Healthy replication can faithfully copy logical deletion or corruption. A compromised administrator can affect every online copy. A DAG does not preserve the historical state required by retention, legal or ransomware recovery.

Keep supported backups or another proven data-recovery design and test them. Include Active Directory/configuration and surrounding services in disaster recovery.

Plan database-copy operations

Monitor copy/replay queue, content index where applicable, copy status, disk health and replication events. Define thresholds that prompt investigation rather than immediate reseed.

Before reseeding, identify why the copy failed and confirm the source copy is healthy. Reseeding consumes network/storage/time and can destroy useful evidence on the target.

Use planned switchovers during maintenance to prove operational procedures while healthy. Record which databases may activate where and whether the server is correctly suspended/drained from transport/client roles.

Plan server recovery separately

For an unrecoverable DAG member, Microsoft documents Setup /m:RecoverServer, which reads stored server configuration from Active Directory and rebuilds the Exchange role on a replacement with the same identity and supported prerequisites.

It is not a bare-metal mailbox-data restore. The recovery plan must capture:

  • exact server name and Exchange build/media;
  • OS and prerequisite state;
  • database copy/lag settings;
  • certificates and local/non-AD configuration;
  • transport queues and application dependencies; and
  • how database copies are restored/reseeded afterwards.

Rehearse before the only server is lost.

Use recovery databases for historical data

A Recovery Database mounts a restored mailbox database separately so data can be extracted or merged into a current mailbox using supported restore requests. It allows recovery without replacing current production data.

Plan backup restore location, log replay, free space, mailbox identity mapping, target folder/merge behaviour, duplicates and legal/privacy controls. Test a representative item and full mailbox recovery.

Understand dial-tone recovery

Dial-tone recovery creates an empty database so users regain the ability to send and receive while the original database is restored. Later, the dial-tone and recovered data are reconciled.

This can reduce service outage but increases data complexity. Users temporarily see an empty/new mailbox, and messages created during that period must be merged correctly. Define communication, identity mapping, interruption points, storage and merge verification before using it.

Test failover and restore independently

A complete exercise includes:

  1. planned database switchover;
  2. unplanned copy/server failure;
  3. client reconnect and mail flow;
  4. witness/quorum observation;
  5. database copy reseed or restoration;
  6. backup restore into an RDB;
  7. item/mailbox merge and duplicate review;
  8. return to preferred copies/sites; and
  9. monitoring/backup baseline restoration.

Record actual recovery time and data point; do not repeat the design target as a test result.

Verify service and data

After recovery, confirm databases/copies, queues, mail flow, Outlook/OWA/Autodiscover, search/index, calendar, application relay, backups and monitoring. Sample mailbox contents across the failure window and reconcile messages created during dial-tone or partial service.

High availability is the ability to continue through known failures. Disaster recovery is the ability to restore and reconcile service when availability mechanisms are not enough. Exchange needs both, tested separately.