Question regarding VRO isolation and vCenter dependency for DR plans

[Stabz]

Hi everyone,

I am planning to implement Veeam Recovery Orchestrator (VRO) for a Disaster Recovery scenario between two sites:

Site A (Production): VMware environment backed up by VBR to a Dell DataDomain.
Site B (Recovery/Clean Room): vSphere environment with a second DataDomain (Vault) receiving replicated data via native DataDomain replication.
In this setup, I intend to use the embedded VBR instance within VRO at Site B to import the replicated backups. However, I want to keep VRO as isolated as possible and I am reluctant to connect it to the production vCenter or the production VBR.

I have two specific questions regarding VRO (v13.0.1):

Inventory & Tag dependency: Since VRO requires an initial connection to the production vCenter to gather inventory and vSphere tags, what happens if tags are accidentally deleted on the production side and a synchronization occurs? Would this break the existing recovery plans?
Manual Backup Mapping: Is it possible to create a recovery plan by manually selecting VMs from the imported backups on the VRO embedded VBR, without any connection to the production vCenter/VBR?
Thanks in advance for your insights!

[Alec King]

Hello!

I'd first like to say, that the feature of VRO using only imported backups - and never requiring a connection to production systems (including vCenter and VBR) at all - is already in progress for an upcoming version
This fits with our 'clean room' recovery scenarios, and you will see more features around this area in the near future!

To answer your other question around tagging for the current version -
If you use vCenter Tags to collect VMs into a group for use in a plan, and then the Tags are deleted/removed in vCenter - the group in VRO inventory will become empty (or the specific VMs that were untagged will be removed). This is expected, tag management is designed to allow control of VMs in the plan from the external source (vCenter).

Note that this behaviour is not the same if the VM itself is deleted from production vCenter - in this case, VRO holds the VM in the plan (as long as there are still backups for it), and simply marks it as "removed from production infrastructure", so that you can still recover it.

If there is an expectation that Tags could be removed or deleted, it might be best to base the VRO plan on a VBR Job, which is probably less likely to be arbitrarily removed. VRO groups based on VBR jobs are automatically created and synced.

There is another new VRO feature already in progress to allow creation of custom groups of VMs within VRO itself - not reliant on any outside configuration. And these groups will include VMs sourced only from backups. This 'custom groups' feature should ship in an update later this year.

Hope that helps!

[Stabz]

Hello Alec,

Thank you for your answers.
I'm delighted to learn that your roadmap includes the creation of "Clean Room" scenarios without production dependencies!

I assume this is related to the future possibility of using imported backups and selecting only the virtual machines necessary for the disaster recovery plan.

I'm seeking the safest way to deploy VRO. Should I restrict communication to the production vCenter only, despite the risk of tags being deleted (by mistake, malice, or script)? Or should I connect to the production Veeam instance and only the Clean Room vCenter? I prefer keeping the backup environment isolated for security purposes. Also, I don't think VRO allows for VM exclusions when selecting a job.