Chapter purpose
Connect mailbox data architecture to real capacity, availability and recovery design.
Learning objectives
- Explain mailbox database and log concepts.
- Plan capacity with growth and recovery headroom.
- Understand DAG database copies.
- Separate high availability from backup.
Why this matters in a real company
A database outage can affect many users. Good storage and DAG design keeps mail available through certain failures without pretending that copies are historical backups.
5.1 Mailbox databases are shared service boundaries
Many mailboxes can share one database, so storage or database failure can affect many users at once. Plan database placement and copies from failure domains rather than available drive letters.
Transaction logs are part of database consistency and replication. Uncontrolled log growth should be investigated, not fixed by deleting log files manually.
5.2 Capacity is more than mailbox quotas
Include current mailbox size, growth, retention, database overhead, logs, recovery workspace and database copy count. Alert while there is still time to act.
Free space inside a user mailbox is not the same as free space on the database volume.
5.3 DAGs provide database-level high availability
Microsoft defines a Database Availability Group as a group of Mailbox servers that hosts database copies and supports automatic recovery from some database, server and network failures.
Two DAG members on one hypervisor, one PDU or one switch still share that failure point.
5.4 Observe health and test switchovers
- Confirm copy health.
- Perform approved planned switchover.
- Verify client access and mail flow.
- Verify monitoring alerts.
- Record interruption time.
Get-MailboxDatabase -Status
Get-MailboxDatabaseCopyStatus *
Get-DatabaseAvailabilityGroup -Status
Test-ReplicationHealthTransaction logs, copies and recovery behavior
Exchange writes changes through transaction logs before database state is fully committed. Those logs also support database replication and recovery processes. Deleting logs outside supported Exchange/backup behavior can make recovery or replication worse.
Database copies in a DAG are continuously maintained so another copy can become active when required. Copy health, replay queues and storage/network performance need ongoing monitoring rather than only checking after an outage.
Quorum and witness thinking
A DAG also depends on Windows failover-clustering concepts such as quorum and witness configuration. The exact witness requirements vary with DAG size and state, so administrators should understand the current Microsoft design rather than memorizing one old recipe.
High availability should be tested as a service: users should still connect, inbound and outbound mail should work, monitoring should alert and the team should know which database copy became active.
Two-node DAG shares one top-of-rack switch
Both servers have healthy database copies but every path uses the same network switch.
Decision: Do not describe the design as fully resilient to network failure. Either accept the shared risk or redesign the path.
Evidence: Create a failure-domain diagram covering server, hypervisor, switch, PDU and storage.
Hands-on lab
Build a capacity and failure-domain worksheet for a two-node DAG with current data, annual growth, copies and recovery headroom.
Troubleshooting exercise
- Logs grow: check backup/replication state.
- Copy queue grows: inspect network and storage performance.
- Database fails over repeatedly: find root cause instead of disabling protection.
Field checklist
- Capacity trend monitored.
- No manual log deletion.
- DAG copies healthy.
- Failure domains mapped.
- Planned switchover tested.
- Backup/retention separate from HA.
Current technical references
The supplied PDF books are used as a historical curriculum map. Current implementation guidance is checked against current Microsoft documentation.