Over the last few years, virtualization has gained a lot of trust and many decided to virtualize Microsoft Exchange and other I\O intensive business apps. As a result, there have been many questions about the backup and recovery of those apps, including questions about what Veeam has to offer for such circumstances.

Can Veeam back up an Exchange VM running on an ESX(i) or a Hyper-V host?

YES, it can. You can google many fine articles on this topic. Veeam fully leverages Microsoft VSS (Volume Shadow Copy Service) technology, which allows performing transaction-consistent backups for applications such as Microsoft Exchange, Active Directory and SQL.

Despite many similarities, companies of different sizes often deploy Microsoft Exchange differently. For cost reasons, SMBs companies more often use a “typical” deployment method, meaning one Exchange server is running Mailbox, Client Access and Hub Transport roles at the same time. Enterprise organizations tend to deploy Exchange Database Availability Groups (DAGs).

Exchange DAGs are a set of 2 to 16 Microsoft Exchange Server 2010/2013 mailbox servers, which use database replication and failover technologies to provide high availability and data protection against failures. Each Exchange server being a DAG member can host one copy of each mailbox database, with a maximum of 100 databases per server. Obviously, the maximum of 16 servers in a DAG is quite enough for the majority of organizations.

Exchange DAG with five members.

Pic. 1 Exchange DAG with five members (source: microsoft.com)

One of the frequently asked questions on Veeam Community Forums is whether Veeam can back up Exchange DAGs. The short answer is YES, Exchange DAG servers can be backed up by Veeam as any other VM with the help of Microsoft VSS technology; you just need to enable “Application-aware Image Processing” to make it work. Below is a short list of the most popular tech notes you need to know during the backup strategy implementation process related to DAGs:

Should I create a separate backup job for each server in a DAG, or only one backup job for all DAG nodes?

If you have enough storage space, create a single backup job for all of your DAG nodes. This will most likely result in better deduplication ratio.

If you want to backup DAG nodes in separate backup jobs, make sure that the schedules don’t overlap and also that all VMs are not being snapshotted at the same time. This can easily be done in the settings of your Veeam backup jobs. For example, the next backup job can be started once the previous one is completed.

Should I backup active or passive DAG nodes?

Veeam can backup both active and passive nodes. Keep in mind that the backup process might affect your production because it may be very processor-intensive. If this is the case, think about moving all of your active databases to a single DAG node and then perform backup for the passive node. This will help you reduce the impact on your production environment because passive nodes can be backed up, even during business hours.

If you still want to keep your active databases distributed across several DAG members, you can add one more completely passive node to DAG and set Veeam to backup this node.

The fastest way to backup your VMs with no impact on running VMs is to create backups from storage snapshots for HP Lefthand and HP 3PAR storage systems, with the latest version of Veeam for VMware.

Veeam Backup & Replication 7.0 R2 update contains several backend improvements for working with DAGs, so be sure install it immediately, if you haven’t already done so.- http://www.veeam.com/kb1831

How do I avoid failover between DAG nodes while the VSS snapshot is being used?

If your DAG nodes are geographically distributed with the WAN connection between them, you can experience VSS timeout (the default freeze timeout for the Exchange writer is 20 seconds). This timeout can result in a failover from the active node to the passive node during snapshot creation/commit. Why? Microsoft FCS (Failover Cluster Service), a Microsoft service that groups independent servers to increase their availability, has relatively low timeouts designed for the fast failover in LAN environments. WAN links have a higher latency that can result in unexpected failover between DAG nodes in your environment during backup.

In this instance, you'll need to reduce “sensitivity” of your cluster by changing timeout values to max with no server reboot (command line):

cluster /prop SameSubnetDelay=2000:DWORD

cluster /prop CrossSubnetDelay=4000:DWORD

cluster /prop CrossSubnetThreshold=10:DWORD

cluster /prop SameSubnetThreshold=10:DWORD

More suggestions for preventing unexpected failover between DAG servers during the backup process can be found on Veeam Community Forums. These are general recommendations, and because each virtual infrastructure is unique, there may be other factors to consider before you decide to implement a backup strategy.

Other interesting resources:

Do you use Exchange DAGs? I always enjoy hearing from readers. Feel free to comment below or contribute to the Twitter discussion on this topic.

Thanks for reading!

GD Star Rating
How to: Backup Exchange Database Availability Groups (DAGs) with Veeam Backup & Replication, 4.5 out of 5 based on 21 ratings

Veeam Availability Suite — Download free 30-day trial

Download now
  • Yajith Dayarathna

    We experienced the same issue related to Exchange DAG node failover and VSS timeouts sometime ago. It was resolved with the same settings suggested above. In our case, the DAG environment was on a LAN and there were no WAN links involved.

    I’m curious to know what other issues could have caused the same error other latency over WAN, specially since the same fix worked for us too.

    Thanks for the interesting post.

  • Magali Sourbes

    The link for White paper, Exchange DAG backup and design best practices, by Brien Posey, takes me to Top 5 reasons to virtualize Exchange by Siegfried Jagott. Is it possible to correct it, or send me the link? Thanks.

    • mlevkina

      Hi @magalisourbes:disqus, sorry for the delay in replying! The whitepaper by Brien Posey is out-of-date a bit, that’s why we put a redirection to another helpful resource.