Exchange 2010 transaction log

[tomis]

Hello all,

I am not sure if someone ask this before.

After transition our public folder from exchange 2003 (physical machine) to 2010 (virtual machine), the transaction logs occupies around 150GB space. I have setup Veeam to perform the full backup in order to truncate the logs. However, I have no luck with it. I am wondering if there is any configuration I miss in the Veeam 5.0.

The backup job setup is to run every 4 hours with Active full backup everyday (also enable synthetic fulls--because active full backup does not clean up the log).

Please kindly advise how to re-configure the job setting to get rid of the log. Also, please kindly let me know if I can provide more info to resolve this issue.

Thanks for your time.
TOMIS

[Vitaliy S.]

Hello Tomis,

Have you enabled application aware image processing and chosen option to truncate logs in the advanced settings?

See User Guide (page 65) for further reading.

Thanks!

[tomis]

Hello Vitaliy,

Thanks for the help. That is the part I keep missing.

Thanks again,
TOMIS

[Gostev]

Just wanted to note that with Veeam, you do not need to initiate full backup to truncate logs. They will be truncated after each successful backup, unless you change the default settings (click Advanced on the same page where you enable application-aware processing).

[Bunce]

A quick note to the above. In a 2010 DAG environment, logs won't be truncated even after a successful backup unless all nodes are in sync (ie the logs need to first be replayed on all nodes before XGE will allow the truncation)

[cmille34]

[merged]

I've done a fair amount of searching on both TechNet and the VEEAM forums here and am stumped.

We are migrating from Exchange 2003 to 2010 and have our co-existence environment set up.
All of our VM's are running on the the latest ESX 4.1.
We have (3) Exchange 2010 SP1 RU6 servers running on 2008 R2. All three servers are DAG members holding a copy of our single mailbox database. We were having a common issue of the DAG failing over because of low default timeout values on the cluster services but I've increased those based on common links I've seen and we haven't had an unnecessary failover in the last couple days now.

We also just upgraded from VEEAM5 to VEEAM6 as we are upgrading to Exchange 2010. I have configured a new backup job to target one of the Exchange 2010 servers that has a healthy passive copy of our database. The job runs fine and finishes in minutes with no errors. However, I don't see anything in the windows event log indicating that a successful backup had been run so it should truncate the logs. Sure enough, the logs are still there. Our database is very small right now as we have only moved over 3 mailboxes. The database is only ~400mb right now.

A brief list of the troubleshooting steps I've taken thus far:
1. Double checked the backup job and confirmed that queiesing is enabled and I have set the advanced settings to truncate the logs
2. Ran vssadmin list writers and confirmed the existance of the Microsoft Exchange Writer with no errors
3. Rebooted the servers of course
4. Confirmed no other errors in the logs


My gut is telling me it is something basic I am missing since I'm not having much luck finding other people in the same position. I concede it could very well be a Windows or Exchange issue - but maybe it is VEEAM not handling the server or something correctly? Any help would be appreciated. Thanks!

-Chris

[dlove]

i wonder if it's the upgrade from v5 to v6. I had a load of issues on my upgrade from v5 to v6 on my dev stuff. I'm going to do new installs and just let the old backups expire to rule out inconsistencies that i just can't gamble with in production.

[cmille34]

Good question - since we didn't have Exchange 2010 prior to upgrading from v5 to v6 I can't say for sure but since it was set up as a new job I would think it isn't related. Hopefully somoene has some suggestions of what to look for to figure out why Exchange or VEEAM isn't truncating the logs after the full backup on a passive node.

[Bunce]

I think the issue with the most recent poster is DAG failover not log truncation, but its been merged to the wrong thread.

There is an existing thread discussing this here with a command line config option i posted to extend the timeout.

There is also a recent MS kb article detailing some hotfixes that can be installed to prevent unplanned failover. Check the exchange team blog for this.

I'll try and dig up the links shortly.

[cmille34]

I think the issue with the most recent poster is DAG failover not log truncation, but its been merged to the wrong thread.

There is an existing thread discussing this here with a command line config option i posted to extend the timeout.

There is also a recent MS kb article detailing some hotfixes that can be installed to prevent unplanned failover. Check the exchange team blog for this.

I'll try and dig up the links shortly.

I was originally having DAG failover issues but I have increased the thresholds based on a Microsoft article I found somewhere. I have had 1 failover in the past 4 days but that is it, rather than a couple a day. I have gone ahead and opened a case with VEEAM support for this issue, it got escalated to Tier 2 pretty quickly. I'll share the findings once it is resolved.

[Bunce]

I doubt they will be able to do anything except recommend optimsing your storage (resources) to try and minimse the time taken to remove snapshot.

Recent article listing recommended hotfixes I referred to above is as follows:
http://blogs.technet.com/b/exchange/arc ... 08-r2.aspx

[Gostev]

Upgrading to v6 may help as well, because typically v6 is noticeably faster than v5, which directly affects the backup job run time, and so the snapshot size. And the smaller snapshot is, the faster it is to commit.

[cmille34]

@Bunce - Thanks for the links, I will definitley check them out.

In my case, the reason logs weren't being truncated was the VMWare tools on the one node I was targetting with the backup was messed up for some reason. I had installed the VMWare Tools the same way as I had on the other 2 nodes of the DAG but for some reason when I went to the Help/About tab of the tools it said the tools service status was unknown -- only for this one server though -- go figure. VEEAM support helped indentify through logs that VEEAm wasn't able to kick off VSS at all. I simply repaired the VMWare Tools and then I was able to see logs truncate after a successful backup.

Clearly not a VEEAM issue but their support took the time to look through the logs for me. Thanks again to those who posted here with suggestions.

[speckery]

[merged]

hi

when i backup or replicate my exchange vm, i got vss errors:
2007 ESE: Information Store (3928) Shadow copy instance 6 aborted
9782 MSEXCHANGEIS:Exchange VSS Writer (instance 4bf302e4-4b47-4cd6-b400-fbcb1c1cf1f2:4) has completed the backup of database 'mydatabase' with errors. The backup did not complete successfully, and no log files were truncated for this database.

all counters are ok on exchange side; i opened a support request with microsoft i we did a lot of tests which are OK.
when i use windows backup i dont have this problem and logs are deleted;
i ran vssadmin list writers command and all is OK.
i ran eseutil on my databases and logs and all is fine as well.

it s only when veeam run backups or replications that i encounter these issues.

veeam give me a success state at the end of backups and repli

only windows logs give me these errors, the problem is that no logs are truncated and im forced to run a windows backup to clean logs, if i dont do that i will have a lack of space on my logs partition and my databases will crash...

anyone have an idea?

thanks a lot for your help.

[speckery]

thanks vitaly for your post!
i didnt see the option concerning logs to truncate in veeam.
i ll see next backup and will let you know.

bye

[sdelacruz]

I have a problem. I have an Exchange 2010 DAG with 3 nodes holding our dbs.
We have 3 dbs
RegularDB- 500 MB limit
ExecutiveDb - Nolimit
SmallDB - Only 200 MB Limit
I have been checking logs and only on Regular Mailbox and Small databases are trunkcating logs. Executive DB has logs from 3 months ago. What do you guys suggest I could do to truncate these logs?
I have checked the advanced settins and VSS is enabled.
Also I am backing up all 3 Servers on Same job. Job has been finishing successfully for past 3 months.

Any help is greatly appreciated.

SAM

[Gostev]

Logs truncation is handled by Exchange VSS writer in response to notification from backup application that backup was successful. If it does not happen for some of your databases, then it might be best to raise the support case with Microsoft. Could it be by design for databases with "No limit" setting?

[sdelacruz]

Thanks Gostev. I am openning a case with Micrsoft.

[jp34]

Hi,
I'm wondering how Exchange transaction logs could be truncated on the demand without having to backup.
I thought to do a new job excluding all disks with "truncate transaction logs immediately" option: disk exclusion doesn't work (not fixed yet) but I can stop the backup once transaction logs truncated... not very clean...
Isn't there a script/command to tell Exchange to truncate its logs ?
I know it's not recommanded to truncate logs without backing up but it may help in emergency scenario...

[Vitaliy S.]

I thought to do a new job excluding all disks with "truncate transaction logs immediately" option: disk exclusion doesn't work (not fixed yet) but I can stop the backup once transaction logs truncated... not very clean...

What do you mean it does not work? There are no known issues currently around disk exclusion functionality. The only thing I am aware about is that excluded disks are still accounted for total job size (just a UI glitch, nothing more).

[jp34]

Oh sorry, I thought is was more than a UI glitch...

[JoshF]

This seems to work fine with VMWare tools quescing, but not Veeam built-in application awareness. Veeam consistantly say to open a case with MS support, who successfully perform a Windows Server Backup and say that Exchange and VSS works correctly as expected, and to go work with Veeam to resolve the Veeam application-awareness issue. Useless - you should support your customers.

[Gostev]

The interesting part of your statement is that VMware Tools quiescing does NOT have functionality for Exchange transaction logs processing. If you see logs flushing with Veeam app-aware processing disabled, that means that some other 3rd party component flushes them. That component could very well be the reason why Veeam app-aware processing fails to process the logs correctly. Just a thought - you did not post your support case ID, so I cannot look up details. Thanks!

[JoshF]

With Win 2008 and above, VMWare Tools will request all applications perform full VSS quescience/preparation regardless.

[Gostev]

This is correct, but this "full VSS quescience/preparation" by itself does not magically cause the transaction log truncation. Log truncation requires additional API calls which VMware Tools does not implement for a good reason.

Basically, transaction log truncation is a separate operation that must be performed by the backup application, and after successful backup only (for obvious reasons). Now, VMware Tools is not a backup application, and when the VM snapshot is taken, VMware Tools does not know (a) if the snapshot is going to be used for backup, or something else and (b) even if snapshot is created for the purposes of backup, VMware Tools cannot see the future and predict if that backup will succeed or not. For these very reasons, VMware Tools does not, and never will have transaction log truncation implemented. This has to be handled by the backup application solely.

[zoltank]

hi

when i backup or replicate my exchange vm, i got vss errors:
2007 ESE: Information Store (3928) Shadow copy instance 6 aborted
9782 MSEXCHANGEIS:Exchange VSS Writer (instance 4bf302e4-4b47-4cd6-b400-fbcb1c1cf1f2:4) has completed the backup of database 'mydatabase' with errors. The backup did not complete successfully, and no log files were truncated for this database.

all counters are ok on exchange side; i opened a support request with microsoft i we did a lot of tests which are OK.
when i use windows backup i dont have this problem and logs are deleted;
i ran vssadmin list writers command and all is OK.
i ran eseutil on my databases and logs and all is fine as well.

it s only when veeam run backups or replications that i encounter these issues.

veeam give me a success state at the end of backups and repli

only windows logs give me these errors, the problem is that no logs are truncated and im forced to run a windows backup to clean logs, if i dont do that i will have a lack of space on my logs partition and my databases will crash...

anyone have an idea?

thanks a lot for your help.

Did you find the cause for this?

I need to do more testing first, but I suspect when you have Veeam back up the Exchange 2010 mailbox server using application-ware image processing but do NOT have it truncate the log files the Exchange server throws this error.

[zoltank]

After some further testing it seems I get the 9782 error when backing up an Exchange 2010 mailbox server with application aware image processing turned on, but have it set not to truncate transaction logs. Once I set it to truncate logs the error goes away.

[foggy]

After some further testing it seems I get the 9782 error when backing up an Exchange 2010 mailbox server with application aware image processing turned on, but have it set not to truncate transaction logs. Once I set it to truncate logs the error goes away.

Sounds reasonable.

[veremin]

I'm also along the same line with Alexander - Isn’t that actually expected to get the message about Exchange logs not being truncated, when truncation log is disabled?

Thanks.

[zoltank]

I think it's perfectly reasonable to be worried about an error message, especially one which says "The backup did not complete successfully".

As much as I love Veeam, the knowledge base is woefully lacking. All of these errors and warnings listed throughout the forums should have their own knowledge base articles.