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.

[Alec King]

Hello Philippe,

Glad to hear you look forward to our upcoming clean room features!
You are correct, it will mean you can build a plan in VRO using only VMs from VBR backups - and that VBR could be the cleanroom VBR, which has imported those backups from a copy repository. So you will be able to build a plan without connecting to the original source VBR or vCenter at all.

And the custom groups that are coming soon will allow you to create a static group of just the VMs you need for your recovery plan; and the group will be created and managed only within VRO, removing any dependency on vCenter tags or VBR jobs.
One small point - you're correct that VRO does not have a 'VM exclusion' process when recovering an externally-managed group, however you can disable recovery of certain VMs just by removing the "Restore VM" step from those specific VMs. It's not ideal as the plan will warn you about skipped VMs, so the custom groups feature will be a better solution.

Regarding deployment, if you want to keep the backup server isolated from the cleanroom, then I'd suggest using only vCenter tags for VM group management; then you do not need to connect the production VBR server to VRO at all. You only need to connect production vCenter to VRO. When the time comes for recovery, VRO can scan the imported backups in the cleanroom, and match them with the vCenter IDs for the tagged VMs in the plan.

Hope that helps!

[Stabz]

That makes perfect sense, thanks for the clarification!

I’ve been running some tests in my lab and noticed that it’s actually possible to remove the "Restore VM" step from the workflow. It’s definitely not the most elegant solution, but it could work as a decent workaround for now.

Also, I assume there’s no official release date announced yet? Any rough ETA you might be able to share?

[Alec King]

Well I cannot really share a specific release date at this point - however these features are in active development, and I'm pretty sure we will ship them this year. Watch this space!