Want VMs replicated to specific datastores.

[gnatola]

Beginning to plan replication to DR.
Datastores in DR are configured one-for-one with those in production.
Would like VMs to replicate their disks to like-named datastores in DR. E.g. production VM with disks on datastore PROD-DATA1 replicate to datastore DR-DATA1.
Some VMs have disks residing on more than one datastore.
Is there any way to configure replication jobs so that we can satisfy our desired requirement without having to modify the destination datastore for every VM (and its disks) in the replication job?
Thanks.

[DGrinev]

Hi and welcome to the community!

AFAIK there is no other way, you should use Pick datastore for selected virtual disks as this is the proper way to setup what you're after. Thanks!

[mfinnigan_g]

We have been using Veeam for backups of our vSphere environment for a couple of years. Works great. We have Exagrid shares as the targets, and the Exagrid shares are named to correspond with vSphere folders. The Veeam backup jobs are based on folder membership, so if I put a SQL guest into the SQL folder in vSphere, it gets backed up by the SQL job to the SQL Exagrid repository. Works great, it means that we don't (often) put a machine into production without backups.

Now, we're starting to plan our replication implementation. We have a DR site with the same number of hosts and datastores. About 120 guests, around 15 datastores. Some guests have disks on more than one datastore, but for simplicity let's just assume that each VM lives on only one datastore. My goal is to set up the jobs in such a way that we can easily ensure that new guests are appropriately replicated - in some cases that means "not replicated", because we have app-level data replication, like with Exchange DAG.

I had hope to do this with tags, since we're already using folders for backups. Each tag could correspond to an RPO : 24Hour, 12Hour, etc. So, I make a vsphere tag called "24Hour", and put it on all the guests that I want to have replication once a day - going forward, our build instructions would include working with the business to define the correct RPO. Then I create a Veeam replication job called "24Hour". Then, I have to pick a target datastore. I can't put all ~120 machines into a single target datastore, of course. So, this plan won't work as-is.

It seems like one possible way to do this is to rename my datastores to match desired RPOs, so I might have datastores names "24Hour_1", "24Hour_2", "12Hour_1", "NoReplication", etc. Then, I could create one replication job per datastore, and as long as the build instructions include aligning the datastore with the desired RPO, I should be good. Any feedback on where this might fall down?

What is the best practice around this? The manual gives good instructions on Veeam architecture, and single-job-configuration concerns, but nothing on how to make a sustainable process.

[mma]

Team up with gnatola and create a feature request

vmware-vsphere-f24/want-vms-replicated- ... 44782.html

[mfinnigan_g]

He's a member of my team, working on this design with me.

[tsightler]

My first thought when reading through your email was to just create a replication job per datastore and select the datastore as the source and target. This would easily handle the use cases for your VMs where all disks are on the same datastore. This basically aligns to your conclusion and there are a couple of different ways to do this based on your exact environment (you could use tags vs datastores for selection).

Then you only have to deal with VMs that use application replication or that have disks on multiple datastores. I think what I'd do is make a tag called "ExcludeFromDatastoreReplicaion", and add this tag as an exclude rule on each of the datastore replication job. That way, any VM with this tag would automatically be excluded from the default replication jobs, so you could easily exclude any VMs that use application level replication or have disks on mulitiple datastores, manually creating jobs to handle the latter.

[mfinnigan_g]

Yup. For VMs that shouldn't be replicated, I would make one or more datastores named "No-replication" and put them there

For VMs that span more than one datastore, I think I could simply consolidate them so that they don't span. Our storage is Nimble, so there's no different performance characteristics between one LUN and another.

[mfinnigan_g]

I spoke with Veeam support, and they did say that doing RPO-specific datastores will solve this the way I want it solved.