Design of SRM Plan for DR purposes

[jameswong1]

I would like to learn more about the intended design of a SRM plan for DR purposes.  Is a plan designed to include a significant number of applications/VMs?  I asked because there is the limit of having 10 concurrent plans running when we're in recovery mode.  If a plan contains the recovery of a single application, the RTO will not work.

Thank you.

[vXav]

It is down to how you want to recover your VMs really.

You could have 1 "mega" plan which includes everything you need to recover on doomsday.

Then you could have a plan per application for DR testing purpose, or a plan per department in your company (accounting, sales...) or <insert idea here>.

Then the recovery order might (will) matter. Core services > DB > Middleware > web servers... You get the idea.

It sounds simple put this way but it's easier said than done, especially if you use storage array replication. In which case it qualifies as an operational nightmare.

[jameswong1]

Thank you for your advice.  I agree that it's up to us and that it's usually easier said than done.

To me, the good news is the VMWare limit to run no more than 10 plans concurrently forces us to design those ten plans so that more time is spent on designing them than running/monitoring them at disaster time.  Perhaps something like two plans dedicated to Finance, so that all Finance apps that have to be in sequence are within Plan 1, and within Plan 2.  But Plan 1 and 2 can run concurrently to save time.  If we divide up the overall orchestration that way, it may make sense.

Thank you again for your help.