We have an Exchange environment with 3 copies of all databases.   One of our copies/nodes is currently offline (Service Down) because the data center is undergoing maintenance and will be for a few days.

After backups complete successfully I am now seeing where the transaction logs are not being purged reliably, only about 1/2 of the time and I'm wondering if it is because Exchange wants to use them to replicate the database to the offline node. 

What is strange however, is that Exchange is purging the logs about 1/2 of the time, on databases where one of the nodes is offline.

Any input on this or thoughts?

I've already used the eseutil.exe to find the checkpoint of where I can safely move the logs, however I don't find any information on when I can delete the logs or why it is failing 1/2 of the time.

I would like to delete the logs if I can safely do so, also, If I have to reseed the databases on my third node that is currently down I don't have a problem with that.

It shouldn't be truncating if it cant access one copy

https://technet.microsoft.com/en-us/library/dd335158%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396

The following criteria must be met for a database copy's log file to be truncated when lag settings are left at their default values of 0 (disabled):

• The log file must have been successfully backed up, or circular logging must be enabled.

• The log file must be below the checkpoint (the minimum log file required for recovery) for the database.

• All other lagged copies must have inspected the log file.

• All other copies (not lagged copies) must have replayed the log file.

Thanks for the link.

Is this behaviour the same with Exchange 2010 SP3?

Any way to force it to truncate the logs versus deleting them manually?

Any way to determine why it IS truncating the logs on 1/2 of the databases.  All databases are configured the same.

Thanks for the link.

Is this behaviour the same with Exchange 2010 SP3?

Any way to force it to truncate the logs versus deleting them manually?

Any way to determine why it IS truncating the logs on 1/2 of the databases.  All databases are configured the

Hi Jason,

Have you checked the suggestion Andy provided? Is there any update with your issue?

Best regards,

If the servers were below 10-15% free disk space they purged the logs, otherwise they didn't.  This behavior was intermittent.  Once we brought our 3rd copy back online, the logs purged as they replicated to the 3rd node and all returned to normal.

Moral of the story, if a DAG copy is going offline for a while, make sure you have enough LOG space to hold the logs until that copy is back online.  They are needed to update that copy, even if FULL backups are performed, which makes sense after seeing how it works.