Veeam Backup and Recovery Integration with SRM

[cabralta]

I am curious to know if any community members have had success with integrating Veeam backup and recovery while using Site Recovery Manager in their environment. I see a lot of posts regarding the debate over Veeam's replication tool and the use of SRM but no real posts about how backup and recovery is working with SRM. I am looking to understand how folks have implemented and what challenges SRM posed in those environments. I am particularly interested in med-large (300-1000+ VMs) setups running vSphere 5.5, SRM 5.5 and a recent version of Veeam B&R but any constructive feedback would be welcome.

Thanks!

[dellock6]

Hi Thomas,
what are you willing to achieve? Veeam and SRM have no integration in the way that Veeam cannot be used as an SRA for SRM, but they can coexist easily. How are you willing to use both? Also, are you talking about SRM using a Storage SRA plugin, or using vSphere replication?

Luca.

[cabralta]

Luca,

Thanks for your response. I am not looking for information on how to integrate with SRM. I am looking for information on how backup and recovery has been implemented when SRM is being used in the environment. There are a number of considerations when taking into account that SRM makes automatic changes to the environment and those changes will affect backup policies and management. A key example is the use of stubs; are stub VM's backed up? When they are online were the VMs able to be backed up? How were jobs managed or created keeping this configuration in mind?

I hope this helps clarify a bit. Please let me know if you have additional questions.

--Tomas

[cabralta]

Also, to clarify about our environment we are using an SRA and array based replication. We are satisfied with what SRM provides for DR so I am less interested in alternative replication/DR solutions. My main objective is to understand how people have implemented backup given this scenario.

--Tomas

[dellock6]

Hi Tomas,
are you looking to backup VMs at the source site or dr site? Because in first case, I have seen many customers reporting success. I'm not sure what stub is, but using an array-based replication, there are no changes at source on the VMs being replicated. I know there are some issues with vSphere Replication since it injects parameters in the vmx file, and locks the VM during its replica, but this is not the case for storage-level replication.
Intead, if you are talking about protecting the replicated VM, the format used by SRM to register those VMs into target vCenter is indeed a problem, but I honestly wouldn't go for a backup at target...

[cabralta]

SRM's term for what I called a stub is the placeholder VM, which is essentially a VMX file at the target site on a temporary datastore that represents the protected VM from the other site. Just the existence of these placeholder VMs in the environment can cause issues with backup configurations because they are VMs without disks configured before you even get into what to backup.

To further complicate things, in our environment we have a production site and a failover site. At the failover site we have live VM's that would need to backed up. In a normal scenario we dont care about whether the placeholder VMX files are backed up or not because they don't have any data behind them as their replicated datastores are offline. Once a year however, we validate our DR configuration by failing over to the failover site and running the VMs from there for an entire week. In that scenario, those placeholder VMs are brought online after their replicated datastores are attached to hosts automatically by SRM. Those live failover VMs would need to be backed up normally but this can result in some odd behavior with backup products because of changes to the VM id and other factors.

I am curious to see if you or anyone else has worked around these issues and what worked for them or did not - or even if they tried and just gave up!

[dellock6]

Ok, got it.
Well, the placeholder VM cannot be protected simply because, as the name says, is a placeholder and has no disks attached to it that we can backup. If you remove SRM and its formats from the picture, what are we discussing here is a VM that is failed over for a week in a different vCenter/datastore/cluster, and needs to be protected.
The problem is that the VM in the secondary location gets a different MorefID, so for us is a completely new VM. And also, you will need local Veeam resources in the secondary site (at least proxies and repositories) to keep backups running. Another possible issue I see, the backup repository is located at the primary site; if you want to keep backups running during DR, you either need to have a different repository in DR, or your backup traffic will have to cross the inter-DC connection to be stored into the original repository. So, also bandwidth and daily change rate needs to be evaluated.

This said, failover VMs will be managed like new VMs. (see also http://www.veeam.com/kb1299). You can keep using the same backup files by using backup mapping, but you will have to remove the old VMs from the job and add the new ones. Obviously a workaround is to use dynamic containers (like resource pools/folders/datastores) instead of a fixed list of VMs.

You said at the beginning we are talking about 300-1000 VMs. You failover all of them for a week?

[cabralta]

Thanks for your thoughtful reply, I suspected these would be the challenges as they are with most backup products available today. In our environment we failover approximately 350 VMs of the 1000 in our environment for a week to prove our DR plan and to understand if we are meeting our desired RTO.

--Tomas

[yowmemperor]

I have done some searching, found info but need help understanding what happens here.

We are currently in the process of obtaining a CoLo to replace our current DR server room. The plan is to run 6 months out of each location going forward. How will this affect Veeam? We currently utilize SRM for critical systems, and would VMotion others. How do you manage the backup jobs for those you would have to use VMotion for? How will this affect the DR side of SRM VM's?

This post was most helpful: https://forums.veeam.com/veeam-backup-r ... 26895.html

Right now I back up mostly by datastore location. We would love to have storage replication set up, but it may not be in the cards just yet. Is there an easy way, script, etc, to modify the job's source storage locations? I can think of several possible scenarios, but before I brain dump them here with their caveats, I am interested in your solutions!

Thanks,
Matt

[yowmemperor]

Still looking for some advice on this subject.

[veremin]

I have done some searching, found info but need help understanding what happens here.

Not sure whether I got your question. Could you elaborate what VM are you going to protect? Source or Replica ones?

How do you manage the backup jobs for those you would have to use VMotion for?

If this is a general (non-SRM specific) question, then, the requirement is to have VMs added to backup console via vCenter server. This way backup server is able to keep track of vMotioned VMs.

[yowmemperor]

Initially the idea is to pull from the replica. How is this configured if the Prod environment moves every 6 months?

I am not sure why I asked the 2nd question...

[veremin]

As mentioned above, the backup of replica VMs is unlikely to work due to the way those VMs are registered on target host. Thanks.

[tpayne]

Hello,

Just to get clarification from above, it was said that the VM will have to be re-added to the job from the new VCenter. This means that even though it will be in the same job, It still will need to do a full backup of the VMs that were failed over.

I know this thread was started a while ago, but with the newer version of the Veeam agent and deploying the agents and managing jobs from a VBR server, Wouldn't using the Veeam agent to back up the vms be a good solution? Or would the underlying hardware change cause the Veeam agent to need a new full as well? I ask this because I have restored a VAW whole image backup to replacement hardware before and the CPU difference caused a new full to be needed.