Video Screencast Help

VM level combined with Exchange DAG backup

Created: 08 Aug 2012 • Updated: 10 Aug 2012 | 17 comments
This issue has been solved. See solution.

A customer has an Exchange 2010 farm with two Exchange Database Servers running in a Windows 2008 VM hosted on vSphere 5.0 HA Cluster. A DAG is created for mailbox HA. We are backup up the databases via the DAG thru the passive copy. We also need to protect the VM's itself for disaster recovery and file level restore. We created a Non-App GRT VM Backup Job for doing just that.

The problem we are facing is however we choose none of the App GRT options, especially the Exchange GRT option is deselected, but the Exchange transaction log files get touched by this VM level backup. This results in the incremental Exchange DAG backups to fail as it states the logs have been touched by another Job than this one.


- Is it true that a VM level backup job, with Exchange GRT de-selected touches the Exchange transaction log files?
- If this is true, how can we design a fully protected Exchange farm? Databases, files and VM.

Comments 17 CommentsJump to latest comment

ZeRoC00L's picture

A vmware GRT backup cannot backup an Exchange DAG !

You will have to backup the Exchange DAG with the Exchange agent.

From the 2012 SCL:

Note:  The Backup Exec 2012 Agent for Hyper-V does not support Exchange 2007 LCR, CCR or SCC and Database Availability Groups (DAG's) for Exchange 2010

due to the distributed nature of these applications beyond a single Guest virtual machine. To protect these applications when they are distributed across multiple Guest

Virtual Machines, please use the Backup Exec Agent for Microsoft Exchange inside of each of the Guest Virtual Machines to protect them.

If this response answers your concern, please mark it as a "solution"

B.T. van Haastrecht's picture

Perhaps i didn't wrote it clearly, but we are backing up the DAG via Remote Agent, not VM.

pkh's picture

When you backup the VM, Exchange is also backed up.

ZeRoC00L's picture

Deselet the Exchange server(s) in the Vmware Agent and only backup these servers with Remote Agent.

If this response answers your concern, please mark it as a "solution"

B.T. van Haastrecht's picture

Agent level backup is not preferabele:

  • It would result in a much longer backup and restore window, as VM is via SAN.
  • Full server restore from agent-level backup takes more time as it needs a running OS base.
  • VM level backup = disaster ready.
ZeRoC00L's picture

I understand your issues, but Symantec does not support an Exchange DAG backup through the Vmware agent, so you have to work around it.

You say you are already taking an Exchange Agent backup, so this will already take the most of the time. What else is on the Exchange server, normaly not much.

If this response answers your concern, please mark it as a "solution"

B.T. van Haastrecht's picture

Well, if we could somehow disable Exchange VSS when a VM is quiesced... I found it strange when de-selecting Exchange App-GRT it still messes with Exchange.

I'm thinking about the following scheme:

  1. Mon to Fri - Exchange Incremental DAG Backup (thru agent)
  2. Sat - VM Full backup
  3. Sun - Exchange Full DAG Backup (thru agent)

This way the VM level will not messup the incremental logs to the full exchange backup made on sunday. And we have a weekly disaster ready VM backup.

ZeRoC00L's picture

 I found it strange when de-selecting Exchange App-GRT it still messes with Exchange.

This is because the logfiles will get the archive flag will be reset, so Exchange will clear the logfiles and messes up the next Exchange backup.

You strategy seems to be good. With an Exchange DAG it should be no issue that a full disaster recovery of this VM takes longer, as you can get Exchange online on another Exchange server.

If this response answers your concern, please mark it as a "solution"

B.T. van Haastrecht's picture

So you mean it isn't the Exchange VSS writer but purely the archive bit on the log files?

Otherwise this VMware KB could be an option, to disable Exchange VSS writer in VMware tools. And VM level backup will no longer use Exchange VSS writer.

Colin Weaver's picture

Hmm well that is a VSS issue.

When Backup Exec  requests a VMware backup (with GRT completely disabled) we make call through the vStorage API to request that VMware snapshots the VM. The VMware snapshot process then makes a call through VMware tools installed inside the VM to request a VSS snapshot of the server. BackuP Exec itself does nto direcvtly touch Exchnage  when GRT is diabled. As such it is probably the VSS snapshot of Exchange that is causing the log truncation.

Not sure there is a solution to this unless it is possible to make VSS not touch Exchnage in some way.

I will ask internally

B.T. van Haastrecht's picture

Thanks for your insight, we are very qurius about the outcome.

pkh's picture

When you back up the VM, Exchange is also backed up. This is why if you just do an incremental backup of Exchange, there will be an error message saying that another application has backed it up.

What you need to do is to continue with your VM backup.  This time with GRT enabled for Exchange and files.  You can do incremental backups of your VM which will back up Exchange as well.  This way you can still restore individual mailboxes with either your full or incremental backups.

B.T. van Haastrecht's picture

We want to take advantage of the DAG priciple, take backup of the passive database which doens't have the user sessions on it. This way backup wont eat resources needed for mailbox hosting.

When you have a DAG you should use the Backup Agent as VM level backup of both VM's would mess up the replicated transaction logs. Therefore it's recommended by Backup Exec, see post made by ZeRoC00l.

Colin Weaver's picture

Ok found it

Firstly in response to ZeRoC00L:

We don't support DAG in VMware against GRT backups - you can still do a VMware backup of the Exchange server itself with GRT disabled, If however you want mail box level backups then you have to use the remote agent and not do Vmware backups. It is however obvious that OP is aware of this if you read his post fully.

Now for the VSS bit we can change VSS to do a copy backup instead of a Full backup using the informnation in

EDIT: removed comments about scripting, as the content of the tech article only amends files that are used by VMware tools, the change won't be called by a RAWS backup so the RAWS backup should correctly still truncate logs.

B.T. van Haastrecht's picture

This is a good solution. I take this also applies for SQL databases?

ZeRoC00L's picture

For SQL GRT is supported in combination with the Vmware Agent.

If this response answers your concern, please mark it as a "solution"

Colin Weaver's picture

As far as I know that will put SQL VSS requests into Copy mode as well, and as such yes that should let you do SQL Transaction log truncation via a RAWS job whilst still doign AVVI backups of the VM itself.

Again for benfit of others AVVI (with or without GRT) of a SQL server will not truncate the logs but does mess up the sequence that must link a SQL transaction log backup to a full backup.