In an Exchange Server Database Availability Group (DAG), when trying to backup a passive copy of a database, you may face a situation where the backup fails with an error. When you check the Event Viewer, you may notice the following error.
Writer name: 'Microsoft Exchange Writer'
Writer Id: WriterId
Writer Instance Id: WriterInstanceId
State: [1] Stable
Last error: Retryable error
Note: This error applies to Exchange Server 2013 and Exchange Server 2016.
If you re-run the backup, you may again encounter the same error. You can run the BETest Tool – a free tool from Microsoft – to test the advanced backup and restore operations on the server. This tool will test the following items:
- Incremental and differential backup
- Advanced restore options
- Roll-forward options
However, when you run this tool, you will still get the following error somehow similar to the above error.
Status for writer Microsoft Exchange Writer: STABLE(0x800423f3 - VSS_E_WRITERERROR_RETRYABLE)
On the server where the backup of passive database copy is initiated, you may notice that an event with ID 2153 is logged in the Application Log with regards to the Exchange Server Replication service.
Log Name: Application
Source: MSExchangeRepl
Date: <Date>
Event ID: 2153
Task Category: Service
Level: Error
Keywords: Classic
User: N/A
Computer: <Computer Name>
Description: The log copier was unable to communicate with server <FQDN of the Active Server>. The copy of database <Mailbox Database\Local Server> is in a disconnected state. The communication error was: An error occurred while communicating with server <Active server>. Error: Unable to read data from the transport connection: An established connection was aborted by the software in your host machine. The copier will automatically retry after a short delay.
Causes behind the VSS_E_WRITERERROR_RETRYABLE Error
It looks the issue is related to VSS. However, the error could also occur due to some underlying issues with the active database or Exchange Server configuration that might be hindering the process. In most common cases, the error is caused by network issues or latency while communicating with the Remote Procedure Call (RPC) service between the server where the passive copy resides and the server hosting the active database. RPC is a protocol of Exchange Server which is used to pass communication, MAPI, and data between Exchange Servers. This is also known as Outlook Anywhere. If this protocol is not working, the passive database will not get any updates from the active database.
Possible Solutions to Fix VSS_E_WRITERERROR_RETRYABLE Error
You can try the following solutions to resolve this error.
Solution – 1
You need to first check the network between the active and passive servers to understand if there is any latency between the servers which is peaking or a particular port/traffic is being blocked between the two sources.
Solution – 2
You can check the Windows Firewall on the servers to see if any traffic is being denied. You should check the server’s security applications, such as Data Loss Prevention (DLP), antivirus or antimalware to see if any processes are being blocked on the servers.
Solution – 3
You need to ensure that the Microsoft Exchange RPC Client Access service is running. If there is an issue, it will be in a stopped state.
Solution – 4
You can also check the timeout in the network devices of the Exchange Servers. The value of the KeepAliveTime should be less than the idle session timeout to ensure there are no timeouts. This is a value in the Exchange Server registry which needs to be tuned and updated according to the timeout. The default value of this entry is 30 seconds. To increase the timeout, you can open the Registry Editor on each server and do the following.
- Open the Registry Editor and look for the below path.
HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\ExchangeServer\v15\Replay\Parameters
- Create a new DWORD (32-Bit) entry with the name QueryLogRangeTimeoutInMsec.
- Edit the value and click on Decimal.
- Enter the value in seconds. If you want to set it to 200 seconds, you need to enter 200000. This depends on the business requirements and the latency between the two servers.
Once this is done, you can restart the Microsoft Exchange Replication Service and then retry the backup.
DAG Backup Considerations
To initiate backup of a passive database copy, the Exchange replication service on the passive database server creates a query to get the range of transaction logs on the active database server. If the active database server is busy, the query may take longer than expected, especially if there are many log files. Then, the Exchange replication service opens an RPC channel to the active database server to inform the server that a backup is in progress. The RPC channel should be open during the backup.
Consider the following points about DAG backups:
- Use only the active database copies for backups. It is not recommend that you back up the passive database copies. Passive database copies should be dedicated to ongoing business operations. Backing up the active copy would be enough to recover the data in case of failure.
- If you must back up passive database copies for some reason, make sure that the active database copies are not configured for backup at the same time. Otherwise, you will experience backup failure and the RETRYABLE error may occur.
- During backup, databases shouldn’t be moved to another Exchange Server in the DAG.
- Network connections should be active and stable.
When you have DAG and using active and passive copies of a database, it is recommended that you use the Exchange Admin Center or the Exchange Management Shell to monitor the health and status of each copy and to perform other management tasks associated with database copies. If there is an issue and the databases are not synchronizing, you will suffer data loss due to inconsistency of data.
What if the Above Solutions Fail?
If all the above solutions fail, it means that there are underlying issues with active and passive copies of the database or the Exchange Server itself. What happens if the active copy is damaged and you need to retrieve the data from the copy? You can use logs on a passive database copy to recover data from log files on the active database copy. By replaying the logs to the database copy, you can recover the database to a specific point in time in the past. The process is difficult because you have to manually manipulate log files and run Exchange Server database utilities. In this case, you are not able to recover complete data.
What happens if the active and passive copies are both damaged? In such situations, you can use Stellar Repair for Exchange. This Exchange Database Recovery software can open any Exchange Server database of any size. You can browse through the data store and export the recovered database to PST and other file formats. In this scenario, you can create a new database and export the recovered EDB file directly to a live Exchange Server database.
Was this article helpful?
