When a new Exchange Server is added to Database Availability Groups or DAG environment, the database copy from the active server is automatically seeded and replicated to the newly added passive server. Log files are also copied from the active server and are replayed on the newly added passive database copy to maintain data integrity and consistency.
When a disk on one of the member servers fails, the database copy stored on the failed disk is automatically replicated to a spare disk on the same server from an active copy of the database. Similarly, if multiple disks fail, all database copies are automatically replicated across spare disks on the same server.
However, you may come across a situation where you add a database copy to a newly configured Exchange Server in Database Availability Group but end up with an error, such as,
“The database file wasn’t found after log replay. The copy will be set to fail. Database: xxxxx\MyDatabase’. File Path: ‘C:\EXCHDB\xxxx.edb’.”
The error indicates failure while seeding the database copy to the new server as it fails to replay the log files on the database copy.
In this article, we have discussed steps to resolve the ‘The database file wasn’t found after log replay‘ error and ensure high availability.
Steps to Resolve ‘The database file wasn’t found after log replay’ Error
The Exchange Server may fail to seed the database due to a lack of incorrect permissions to the folder created by DAG. However, it may also occur due to other reasons related to the Exchange Server or problems with the database.
Check the status of the failed database copy using the following PowerShell cmdlet,
Get-MailboxDatabseCopyStatus *
It will display the status of the failed database copy as FailedAndSuspended.
DAG does not prevent the replication of inconsistent database copies. It may copy the damaged database copy across all passive Exchange servers. Thus, sometimes databases may show as Dismounted or FailedAndSuspended status due to inconsistencies in the database.
In such cases, restart the server and try mounting the databases using the Mount-Database cmdlet with –A force switch (if required). Then, try reseeding the database copies manually via Exchange Management Shell (EAC) or Exchange Management Shell (EMS).
Reseeding Database in DAG via EAC and EMS
The steps are as follows.
- In EAC, navigate to servers> databases and click on the database copy with failed status.
- Click the ‘Update‘ link. A warning message will appear. Click ‘Yes.‘
- Click ‘Browse‘ to select the source server. For seeding, select a passive Exchange database server. Please do not select the Active Exchange Server, as it failed to seed the database.
- The Exchange will start the seeding process from the database copy on the passive server to your newly added Exchange Server.
- After it has finished, you will have another healthy passive Exchange database copy to protect against the database-level failure.
You may also use the Update-MailboxDatabaseCopy PowerShell cmdlet in Exchange Management Shell (EMS) to reseed the failed database copy.
Update-MailboxDatabaseCopy “Mailbox Database 971165243”
Use –DeleteExistingFiles switch if you encounter an error related to log files.
You can also specify the active or passive source server to reseed the failed database copy,
Update-MailboxDatabaseCopy “Mailbox Database 971165243” -SourceServer EXSRV01
Add –BeginSeed switch if you don’t want to keep EMS open until seeding is finished.
Points to Remember
- Reseeding may take a while to finish based on the database size, network speed, and bandwidth.
- The Seeding process takes longer when you seed or reseed database copy between two different DAG groups.
- Not mentioning the source in the Update-MailboxDatabaseCopy PowerShell cmdlet will seed the failed database copy from the active database copy.
- Ensure the newly added Exchange Server has enough storage space to hold the database copy, log files, and additional data. Otherwise, seeding may fail.
To Wrap Up
The database file wasn’t found after the log replay. When an administrator adds a new Exchange mailbox server to DAG, a seeding error is displayed, but database replication fails. However, this can be resolved by manually reseeding the database copy from an active or passive Exchange Server with an updated mailbox database copy.
But sometimes, the databases on the active server may get damaged or corrupt and replicate the damage across all passive servers. This could lead to server failure and downtime. However, you can use an Exchange recovery tool, such as Stellar Repair for Exchange, to repair inconsistent or corrupt databases in DAG and export the recovered mailboxes directly to a new database on a Live Exchange Server (member of the DAG group). After fixing the database, you can replicate the healthy copy of the database manually across passive servers using EAC or EMS cmdlets, as discussed in this guide.
