VMware Site Recovery Manager SRM

[nunciate]

Doing some future planning. We currently have 2 data centers in different states. In our backup environment we backup all 250+ VM in the primary DC. We replicate all 250+ to the DR DC with Veeam. We then backup all of the replicas in the DR DC.
This way we have backups of all of our data in both locations. When I say backup, I mean backup to disk repositories and to tape in both sites. (OverKill).

Both locations have the same VMware setup. Each site has a Dell PowerStore 3200T SAN, VMware hosts, and vCetner. They are totally separate.

We would like to enable volume replication between the Prod and DR SANs, setup SRM, and put all our VM onto vVols so SRM can handle the failover.

My question is, will I be able to backup the Prod and DR versions of the VM still? Is anyone doing that?

[Andreas Neufert]

First I would like to mention that you should check our Veeam DR Orchestrator which is basically the SRM on steroid with tons of additional functionality. https://www.veeam.com/disaster-recovery ... rator.html

Then let´s unpack a bit the Veeam Replication and backup from target.
VMs at replica target are not running and so change block tracking can not be used. The backups are always snap and scan backups where we read 100% of the data with every backup run.

There are many ways to setup the processing maybe in a different way. For example you can use backup instead of replication and setup the VM replication from the backup target. That way your lower the processing overhead and gain full control of Guest application processing (for example with database log backups) and other application/file restore options.

Then for Powerstore there is another option with Veeam.
https://www.veeam.com/data-platform-tri ... ge-plugins
Our Storage Plug-ins (developed by Dell themself) can be leveraged similar to what you described with SRM.
The backup process can do the following:
1) Consistency with Guest processing
2) VM snapshots (for some seconds)
3) Create Primary Storage Snapshot (and remove VM snapshots) + maintain primary snapshot chains (for example 14 days or 100 snapshots)
4) Orchestrate Secondary Storage Snapshot replication (to second side) and maintain different retention (for example 90 days)
5) backup from secondary side to other media.

You can restore then from Primary Snapshot, Secondary Storage Snapshot with Instant Restore (nearly same as with Replica Failover with the full power of the storage. As well you can restore VMs independently (not only whole volumes => No VVOL complexity needed).
As well you can use the backups to do point in time DB restores, file/database/application restores or as well instant restores.
This is all possible with VUL license or Enterprise Plus if you have socket licensing.
On top of this you can implement as well the Veeam DR Orchestrator to have an more orchestrated restore approach. (Separate license or within the Veeam Data Platform Premium included. There is as well an optional Incident recovery service with $5M data recovery expense reimbursement possible.

Last if you still want to go with the SRM and use storage replication processing, then I think the VMs at the target are not fully present with the VM disks and so you can not backup at target. But you can backup at source with VMware backup (we support VVOL as source as well). Backup maybe locally and create a BCJ to the other side.
I think the Veeam storage integrated way (even without orchestrator) is very powerful as it is so simple on how you can use this.

[nunciate]

Thanks for that info.

I didn't give the reason why we wanted to do this. We recently did our yearly failover to DR where we failover a subset of our VM to the DR location. Some things we have noticed every year are these.

Failover of about 40 VM using standard Veeam Failover Plans takes about 2 hours. We would like to shorten that even though that number is below our current 4-hour requirement. If we had to fail over all 250 it would take an entire day or more.
Failback of 1 of these VMs (SQL) took many hours. The disk calculations required to do a fallback with changes took far too long. It is faster using virtual proxies but still pretty slow.
Many of our VMs are fine with a single replication every 24 hours but we also have a lot that we would like more up to the minute. Maybe within the last 5 minutes. (Again SQL Non-Always On Servers). Might just be cheaper to get more Always on Licenses ultimately. We also have many Windows file servers that rely on DFS Replication. DFS is unreliable at times but it is pretty up to date and a Veeam replica isn't enough unless we can run it constantly like with CDP.

I tried using a CDP replication which seems to work well enough but the destination VM replica becomes locked so I can't back it up.

That all said I have not looked into DR Orchestrator much. Does it help with the RPO of a replicated VM or is it more just to help do failover and fail-backs?

If SRM leaves the destination VM in a locked state so Veeam can't backup that is not a viable option either.

[Andreas Neufert]

Hi Alan,

thanks for sharing. Regarding Failover Plans, I guess your process the 40VMs sequential as you use the default 60 seconds delay?
You can run multiple of the failover plans in parallel and as well reduce the wait time to 10 seconds or less. It is similar situation on how many VMs you want to start on that environment at the same time. Likely you would manually select 40-50 VMs and start them in parallel. Same approach schould be OK at the failover plans parallelization.

Veeam DR Orchestrator helps with this planning and overall as well with the failover testing as it delivers a virtual lab based test environment for the failover and you can test even a whole datacenter failover. It documents as well this approach. I suggest to reach out to one of your Veeam contacts and ask for a demo.

If you are on an older version of Veeam then I would look into updating to v12.1 as each version we optimize processing, and if I remember right we switched the failback option to a different processing along the way. So it might be faster.
Same likely counts for CDP that you can use maybe for the most critical server.

Anyway, what fits best your situation is to do the following.
Use the Storage integration to create some snapshots on the source side, replicate them to the target side and let Veeam backup from the storage snapshot on the target side. If you just keep "some" snapshots this does not take much additional capacity on both storage systems. Then if you need it, create replicas out of the backups (you can select backups as source for your replications with the "source" button in the replication job) or perform replicas from source VMs. Maybe combine this with Veeam CDP for the most critical systems (or all of them?). Optimize the failover jobs for more parallization to the point that your vcenter is barely handling the loud (optimized failover time window). You can try this by creating 250 empty VMs (just clone an empty VM), replicate them and try multiple options with the failover plan and monitor your target vcenter performance. Likely you can start 50-100 VMs at the same time without issues.

[nunciate]

I am on the latest version of v12 now so we are good there. I'll play around with these ideas and see how it goes. I'll also get quotes for Orchestrator to see what those costs look like.

Thanks again for all the info.