08-08-2012 12:05 AM
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.
Questions:
- 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.
Solved! Go to Solution.
08-08-2012 03:13 AM
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
http://www.symantec.com/docs/HOWTO74082
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.
08-08-2012 12:13 AM
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
08-08-2012 12:14 AM
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.
08-08-2012 12:25 AM
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.
08-08-2012 12:55 AM
Perhaps i didn't wrote it clearly, but we are backing up the DAG via Remote Agent, not VM.
08-08-2012 12:58 AM
Thanks for your insight, we are very qurius about the outcome.
08-08-2012 01:03 AM
When you backup the VM, Exchange is also backed up.
08-08-2012 01:05 AM
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.
08-08-2012 01:05 AM
Deselet the Exchange server(s) in the Vmware Agent and only backup these servers with Remote Agent.
08-08-2012 02:15 AM
Agent level backup is not preferabele:
08-08-2012 02:32 AM
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.
08-08-2012 02:40 AM
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:
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.
08-08-2012 02:49 AM
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.
08-08-2012 03:13 AM
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
http://www.symantec.com/docs/HOWTO74082
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.
08-08-2012 03:18 AM
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.
08-08-2012 04:13 AM
This is a good solution. I take this also applies for SQL databases?
08-08-2012 01:01 PM
For SQL GRT is supported in combination with the Vmware Agent.
08-09-2012 02:18 AM
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.