About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Many organisations still run Exchange Server on their own infrastructure, and many of them protect it with backups. A backup of an Exchange server, though, is only part of the answer. What matters in a recovery is which of Exchange's own recovery mechanisms the situation calls for, and whether the backup and the environment around it give that mechanism what it needs.
Microsoft documents four main mechanisms for on-premises Exchange Server 2016, 2019 and Subscription Edition. This article sets out each one, the failure it suits, and the conditions it depends on.
First, how Exchange is backed up
Microsoft's preferred approach does not use backups
Microsoft's Windows Server Backup article for Exchange opens with a point that shapes everything else: Microsoft's preferred architecture for Exchange Server uses a concept known as Exchange Native Data Protection. Microsoft explains that it relies on native Exchange features to protect mailbox data, without traditional backups. In our understanding, those features centre on keeping several copies of each database in a database availability group.
Microsoft's high availability and site resilience article defines one of those features, the lagged copy, as A passive mailbox database copy that has a log replay lag time greater than zero. In our understanding, a lagged copy deliberately stays some hours or days behind, which gives a way back from a logical problem that has already replicated to the other copies.
In our view, whether to rely on native data protection or on backups is a design decision for each organisation, not a default. The rest of this article applies where backups are part of the design, either alone or alongside database copies.
What Microsoft says about backing up with Windows Server Backup
Exchange includes a plug-in that lets Windows Server Backup take Exchange-aware backups using the Volume Shadow Copy Service. Microsoft sets out several rules for it:
- Whole volumes. Backups occur at the volume level. To back up a database and its log stream, the whole volume holding the database and logs must be backed up, not just folders.
- Local only. The backup must run on the server being backed up; the plug-in cannot take remote backups. Microsoft says the resulting backup can be stored on a local drive or a remote network share.
- Full backups. Microsoft states Only full backups should be taken. Transaction log truncation happens only after a successful full backup of the volume or folders containing a database.
- Copy backups do not truncate. The article's table notes that a copy backup leaves logs untruncated, and that one style of full backup truncates logs but allows only file restore, not an application-level restore.
For the Windows Server Backup plug-in, successful Exchange-aware VSS full backup is the documented log-truncation trigger. Logs can grow when that backup path fails. Other protection designs, including circular logging and replicated database copies, have additional rules; do not infer that every Exchange server without a recent full backup retains logs indefinitely.
Mechanism 1: the recovery database
What it is for
Microsoft's article on recovery databases explains that mounting restored data as a recovery database (RDB) allows the administrator to restore individual mailboxes or individual items in a mailbox. The restored database and logs can be placed on any disk; Exchange replays the logs to bring the database up to date.
Microsoft lists the situations it suits, including recovering an individual mailbox after the deleted mailbox retention period has passed, and Specific item recovery: You can restore from backup data that has been deleted or purged from a mailbox.
How it differs from a normal database
An RDB is deliberately isolated. Microsoft lists the differences, including:
- Mail can't be sent to or from an RDB. All client protocol access is blocked.
- Outlook and Outlook on the web cannot open it; only recovery tools can.
- Mailboxes in an RDB can't be connected to user accounts. Data must be merged into an existing mailbox or exported.
- System and mailbox management policies are not applied, so items are not deleted by the system during recovery.
- Only one RDB can be mounted at any time on a Mailbox server.
- An RDB is a restore target, never a backup source, and has no database copies.
What it needs
Microsoft states that an RDB works for Exchange 2016 and later mailbox databases only, and that the target mailbox for merges and extraction must be in the same Active Directory forest. It also notes that folder permissions (ACLs) are not preserved when content is recovered into an active mailbox.
In our reading, the RDB is the everyday restore tool for Exchange: it targets mailbox content rather than rebuilding the entire server. Its requirements are modest, but they include disk space for a full restored database on a Mailbox server, and a backup that contains the whole database and its logs.
Mechanism 2: dial tone recovery
What it is for
Microsoft describes dial tone portability as a limited business continuity solution for failures affecting a database, a server or a site. A dial tone recovery involves creating an empty database on a Mailbox server to replace a failed database, so users can send and receive mail while the failed database is restored.
How it unfolds
The article describes the sequence: users are given empty mailboxes in the dial tone database; for same-server recovery, the failed database is restored into a recovery database; the restored and dial tone databases are swapped; and mailbox restore requests merge the mail received during the outage into the restored mailboxes. Microsoft describes three variants: on the same server, on an alternate server and then back, or on an alternate server permanently.
In our reading, dial tone recovery changes what a long restore means for users. Without it, users have no mail until the restore finishes. With it, they can regain new-mail service after the dial tone environment is prepared and clients reconnect and their history returns later. The trade-off is a more complex sequence with a merge at the end, which we recommend rehearsing before it is needed.
Mechanism 3: database portability
Microsoft's article on database portability explains that it lets a mailbox database be mounted on a different Mailbox server in the same organisation, and that it can help reduce overall recovery times for some failure scenarios.
It has conditions. Microsoft notes that the operating system version and the Exchange Server version on the source and target servers must be the same. The database must be in a clean shutdown state before it is moved; if it is not, a soft recovery is performed first. Users regain access after Active Directory replication completes, with most clients redirected automatically.
In our reading, database portability is the option when one Mailbox server has failed but its database files, or a restored copy of them, are available and another suitable server exists.
Mechanism 4: rebuilding a lost server with RecoverServer
What it does
Microsoft's article on how to recover Exchange servers explains that a lost server is rebuilt with Exchange Setup in its RecoverServer mode. Because most Exchange server settings are stored in Active Directory, Setup reads that information to rebuild the server with the same identity. Databases are then restored separately.
Servers that were members of a database availability group follow a related procedure, described in Microsoft's article on how to recover a database availability group member server, which includes recording lag settings and removing the old member's database copies first.
The conditions Microsoft lists
The recovery article sets out requirements that, in our reading, should be checked long before they are needed:
- Same name. Recovery won't succeed if the target Windows server doesn't have the same name as the lost Exchange server. The computer account is reset, and the new server joins the same domain.
- Same Windows version. The target server must use the same version of Windows Server as the lost server.
- Same drive letters. The same disk drive letters that were used for mounted databases on the lost server must also exist on the target server.
- Same install path, or the path must be given to Setup. The original path is stored in Active Directory.
- Similar hardware. The target should have the same general performance and hardware configuration.
- Permissions. The account doing the recovery needs Domain Admins and Exchange Organization Management membership.
- Certificates. RecoverServer assigns a self-signed certificate to services that need one. A certificate from another authority must be re-imported and configured, or clients will see certificate warnings.
Microsoft also notes that if the installation media for the original cumulative update is not available, the latest one can be used. It says the recovered server’s version attributes can still display the older CU build as a cosmetic discrepancy; a later supported Setup Upgrade operation corrects those attributes. That display issue alone does not establish a failed recovery.
What this means for the backup
In our reading, RecoverServer changes what a "server backup" needs to hold. The Exchange configuration lives largely in Active Directory, so the domain controllers and their backups are part of Exchange recovery. The databases are restored from Exchange-aware backups. What remains, and is easy to miss, is everything outside both: the certificate with its private key, the drive layout, the Windows version, the install path, and any customisations made on the server itself. We recommend recording these alongside the backups.
Choosing the mechanism
From the points above, our reading of which mechanism fits which failure:
| Situation | Mechanism |
|---|---|
| Deleted items or a mailbox past its retention period | Recovery database |
| A database is lost and the restore will take hours | Dial tone, then restore and merge |
| A Mailbox server is lost, database files or backups available, another server exists | Database portability |
| A server is lost and must be rebuilt with its identity | RecoverServer, then restore databases |
A note on timing
In our reading, the four mechanisms differ sharply in how quickly users notice a recovery. A recovery database works in the background, and users may never know one was used. Dial tone restores mail flow quickly but leaves users without their history for a time. Database portability and RecoverServer both wait on Active Directory replication and on database restores, so their duration depends on the size of the databases and the speed of the backup storage. We recommend measuring a full database restore at least once, so the choice between waiting and starting a dial tone recovery is made with a real figure.
Our recommendations
- Decide the protection model deliberately: native data protection, backups, or both.
- Confirm backups are Exchange-aware full backups and that logs are truncating after them.
- Rehearse an RDB restore for a single mailbox, including the merge or export step.
- Write down the dial tone sequence and rehearse it once, merge included.
- Record what RecoverServer needs: name, Windows version, drive letters, install path, certificate and permissions.
- Protect Active Directory as part of Exchange recovery.
Confirm lifecycle support and isolate the recovery test
The recovery pages still describe Exchange 2016 and 2019 as well as Subscription Edition. Their presence in an applicability banner is not proof of current product support. Check the installed edition, cumulative update and Windows combination against Microsoft’s lifecycle and support matrix before using a rebuilt server for service. A recovery to an old build and an upgrade to a supported build are different operations and need their own plan.
For an isolated rehearsal, prevent the restored server from receiving production mail or delivering duplicate messages. Verify the directory dependencies, certificate private keys, database state and intended mailbox identities before testing a controlled extraction or delivery. A database mounting successfully does not prove that users can authenticate, that mail routing is correct or that historical mailbox permissions were recovered. Record those checks separately, including any ACL limitations of the selected recovery method.
Microsoft’s lifecycle pages record that Exchange Server 2016 and Exchange Server 2019 ended extended support on 14 October 2025. They are historical recovery contexts here, not recommended supported deployments. Check any separately purchased support arrangement and the current Subscription Edition requirements.
Risks and limits of this article
- Based on Microsoft documentation as read on 11 November 2026. Requirements can change with cumulative updates.
- Comparisons, the choice table and recommendations are our reading, labelled as such.
- No recoveries were run for this article, and Microsoft's command procedures are deliberately not reproduced.
- Exchange Online is out of scope.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Using Windows Server Backup to back up and restore Exchange data
- Microsoft Learn: High availability and site resilience
- Microsoft Learn: Recovery databases in Exchange Server
- Microsoft Learn: Dial tone portability in Exchange Server
- Microsoft Learn: Move a mailbox database using database portability in Exchange Server
- Microsoft Learn: Recover Exchange servers
- Microsoft Learn: Recover a database availability group member server
This article was originally published on .