How to Solve “database redundancy two-copy health check failed” error in Exchange 2013

Database Availability Group (DAG) helps Exchange Server administrators achieve high availability (HA) and site resilience. It provides automatic failover protection and safeguards the Exchange infrastructure from downtime caused by database, server, or mailbox failure. However, it’s important to continuously monitor the DAG to ensure it provides HA when required.

Test-ReplicationHealth is one of the most used PowerShell to check and monitor all aspects of the database replication, replay, availability of Active Manager, and the health of cluster service, network components, and quorum. It also provides the status of mailbox servers in a DAG environment.

When the health check fails with an error, such as ‘database redundancy two-copy health check failed’, it could be a sign of a damaged Exchange database. In such cases, you can check the database status and repair it using an Exchange recovery tool, such as Eseutil or Stellar Repair for Exchange.

Below we have explained the issue behind the health check failure and solutions to fix the Exchange database redundancy two-copy health check failed error.

Reason for Database Redundancy Health Check Failure

It is observed that the error occurs in an Exchange Server DAG setup with two servers running Mailbox, CAS, and Hub roles, which are geo-located with different subnets connected over a site-to-site VPN, Windows Server 2012 R2 and Exchange Server 2013 Standard configured. However, the error may also occur in other Exchange Server versions with similar setups.

If you notice the event logs, you will find a number of error messages in the Application log on MSExchangeRepl with event IDs 2059, 2153, and 4113. These are a result of some intermitted issues but will show quite often in the event logs.

Database redundancy health check failed.
Database copy: TempDB
Redundancy count: 1
Error: The number of configured copies for database ‘TempDB’ (1) is less than the required redundancy count (2).
Name Status RealCopyQueu InspectorQue ReplayQueue CIState
—- —— ———— ———— ———– ——-
DAG01 MBX Sto FailedAndSusp 111 0 0 Failed
re 1\EXC02 ended
DAG01 MBX Sto Mounted 0 0 0 Healthy re 1\EXC01

IMPORTANT NOTE:

In the output of the Test-ReplicationHealth cmdlet, you may see the error code ‘1018 – Database redundancy two-copy health check failed.’ It is important to note that the health check will always fail with two Exchange Server nodes and two copies. Therefore, if you have only two nodes in your DAG setup, you may ignore the 1018 JET_errReadVerifyFailure error.  

Solutions to Resolve Database Redundancy Two-Copy Health Check Failed Error

Below we have discussed the workarounds and solutions to troubleshoot and fix the Database redundancy two-copy health check failed error in Exchange DAG.

1. The first thing to do is check the logs. It will help you find what happened from when the Exchange Server was healthy until the issue occurred. Then, any changes made could be identified as the cause of the error.
2. However, if no changes were made that could harm the replication health, check for connectivity issues. For example, you need to check the connection’s speed and if there are any disconnections or lost packets during transit. Also, verify any changes on the network firewall or configuration changes.
3. Also, check that the Active Directory Servers on both sides are functioning properly with the repadmin /replsummary to see that replication between sites is fine.

Then use the /queue to see if there are any blocked or unprocessed items. Further, run the command with the /showrepl parameter to see an overview of the Active Directory Partition.

• In conjunction with the above, you must check the DNS health and replication status between sites. Exchange Server is heavily dependent on your Active Directory Schema. Thus, if the AD and DNS are not healthy, you will surely have Exchange problems, such as database redundancy and two-copy health check failure.
• Another thing to consider is the number of mailboxes and the mailbox database, along with their size. It would be wise to split the users depending on their department or location.
• Another option would be to create a new database and move mailboxes to it gradually. This would be ideal as if you have all your eggs in one basket, i.e., all the mailboxes in one database and something should happen to that database, all your users will be affected.
• Another option would be to reseed Exchange database. However, it will take considerable time to finalize, depending on the size and bandwidth.
• One can also try to check the backup software being used. Of course, the backup software must be aware and compatible with Exchange Server DAG. But before using any backup software, one must ensure with the vendor that it’s compatible and DAG aware, as using the wrong backup software can wreak havoc in your setup and create possible database corruption.
• If you run the PowerShell command Test-ReplicationHealth and notice an error on DatabaseRedundancy and DatabaseAvailaibity, go through the setup and check if you are using one network card instead minimum of two. If there’s only one, you need to have another network card.
  I need to stress the importance of not haggling with the requirements as there is a good reason for them.

You may also reseed the other copy by following these steps:

1. Open the Exchange Admin Center (EAC) and navigate to servers > database. Check the database Bad Copy Count is set to 1. Then click on the database that has the issues.

• On the database, copy showing the issue, click on the Update button, and follow the wizard. If all goes well, the database should reseed and resolve the issues.

NOTE: Be cautious in reseeding the database as it can impact the connection and the users.

Conclusion

The article explains why the ‘database redundancy two-copy health checks failed’ error in the Exchange Server Database Availability Group (DAG) appears when administrators perform a health checkup via the Test-Replication health cmdlet. We also shared solutions to troubleshoot and fix the problem. However, if the problem persists, you can always rely on applications like Stellar Repair for Exchange to open corrupted EDB files and export the recovered mailboxes to PST or directly to the Live Exchange Server database and Office 365 tenants.

Was this article helpful?

YES0

NO

About The Author

Shelly Bhardwaj

I am a Product Consultant and is associated with Stellar Data Recovery from last 8 years. I write about the latest technology tips and provide custom solutions related to Exchange Server, Office 365, MS Outlook, and many other Email Clients & different flavors of OS Servers. Read More