…how do you work within a Recovery Plan when it comes to a parallel processing, for example 5 VMs simultaneously?
For example: in this specific plan (built on based with Tags), there are some Domain Controllers in it. Within a DataLab Plan i can add the option for Prepare DC for DataLab (preparing services, exiting DSRM and so on). Within a Recovery Plan, this is not available.
But in the case of a Desaster, and these DCs within the Recovery Plan are the only available DCs - they has to be started first. With a parallel processing and no available option for a Pause-Step, other VMs will be booted, even the Domain Service are not yet available.
For sure, i can start those DCs within a separate Recovery Plan first or a better solution: have a DC also running and available at the DR-Site…
What do you think about it, or how do you handle this?
thanks and best, Markus
Best answer by AlecKing
Hi Markus! Regarding your options for recovery - you could use another tag on those DCs, and use that group in your plan to recover the DCs before the remaining VMs in the second group. Groups are always processed sequentially by VRO, regardless of the processing settings for VMs in the group itself.
And I just wanted to share a small feature from vNext which will help you in this situation 😊
When you run the “Prepare DC for Datalab” step in your plan test, actually VRO just sets a bunch of special parameters on the Restore VM step. Those parameters tell VBR that it’s recovering a DC.
And in VRO vNext we have simply moved those parameters to the Restore VM step. So you will be able to recover a DC in a real restore, not just in a lab test. Here’s a sneak preview of the new parameter!
You will see this on every Restore VM step - so you can choose per-VM whether VRO/VBR will treat this as a DC or not (and you won’t see Prepare DC for Datalab any more)
Before you all ask “WHEN will this vNext be released!?”, I can only tell you, it’s in progress 😎
Hi Markus! Regarding your options for recovery - you could use another tag on those DCs, and use that group in your plan to recover the DCs before the remaining VMs in the second group. Groups are always processed sequentially by VRO, regardless of the processing settings for VMs in the group itself.
And I just wanted to share a small feature from vNext which will help you in this situation 😊
When you run the “Prepare DC for Datalab” step in your plan test, actually VRO just sets a bunch of special parameters on the Restore VM step. Those parameters tell VBR that it’s recovering a DC.
And in VRO vNext we have simply moved those parameters to the Restore VM step. So you will be able to recover a DC in a real restore, not just in a lab test. Here’s a sneak preview of the new parameter!
You will see this on every Restore VM step - so you can choose per-VM whether VRO/VBR will treat this as a DC or not (and you won’t see Prepare DC for Datalab any more)
Before you all ask “WHEN will this vNext be released!?”, I can only tell you, it’s in progress 😎
I haven’t used VRO yet Markus, but I would think the ‘Plan’ in it would be similar to the Replication Failover Plans where VMs are processed in order in the list you place them in, with replica VM power on option decided upon by the ‘Delay’ setting? Is this not the case currently in VRO?
VRO failover plans do not have a Delay setting - the last thing we want when performing recovery at scale is to introduce delays 🙂
Instead VRO can perform all the additional checks that you might want to ‘delay’ for, such as confirming apps, databases, services - or reboot as a DC. Then VRO knows the VM is up and online, and it proceeds to the next one - no sooner or later than required!
