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.