Hi Mike
We are seeing a separation of Business Continuity into three strands - uptime, backup and recovery and disaster recovery.
It is quite easy to get the backup and recovery whether local and remote confused with disaster recovery.
With the backup and recovery piece we are looking at having the time and space to use application agents, schedules etc to ensure that we create as close to application consistent replicas as possible on a backup medium both locally and remotely and depending on the granularity of our schedule and the mass of backup storage media we believe we can sustain and infrastructure overhead (think disk contention, array utilization etc) we can grab nice restarteable copies of the base OS and applications down to maybe every other minute
One of the joys here of RecoverPoint and other journaling products is that can take that approach even more granular - but as alluded to above this may mean buying separate appliance to offload the processing overhead as well as accepting greatly increased storage requirements.
In the nice ordered, predictable world of backup and recovery - we have control over how we recover our environments in the event that an element of that environment fails, corrupts or just plain dies.
If on the other hand the whole environment goes Pete Tong and we have the proverbial smoking hole in the ground - then the key business objective is getting mission critical services back online as fast as possible with a minimal RTO for some or all of these services.
Ideally everything recovers from crash consistent copies that have been failed over with in the SRM framework and the last thing on an administrators mind is whether he retrieves the copy of 10 minutes ago or 15 minutes ago - just getting that specific service up and running in cordination and correct order with the 50-100 other systems and then providing user and customer access back into those services is an overwhelming priority
However, where the line blurs is where the system in question does not recover form crash consistency or whether the objective must be to return to a known good point in time - this is when a mingling of the back up and recovery ethos and the disaster recovery ethos occurs.
This is when people are beginning to look around to enhance the base SRM proposition with additional elements to provide a fall back position whether that be VMware Guest OS level machine consistent snapshots transported across with the base Virtual Machine images or utilizing some other framework such as VSS / VDI to create application of file system consistent snapshots / replicas to provide I would suggest a Plan B option in the event that the service cannot recover from the SRM initiated crash
As to what is supported and what works - I will leave that to VMware and those familiar with the technical scope of the SRM framework to comment - as to what is possible as already suggested - on one level SRM is an organized transport capability - it moves a set of files - the underlying VMFS / RDM structure with the VM images layered on top across to the DR site and recovers - that transport mechanism can be used to transport VSS replicas, VMware snapshots etc. The only issue then is how those elements are localised and recovered back into the wider SRM framework and the fabric of the ESX environment as it now exists on the DR site - the basic scripting elelments avaialble in the recovery plans of today show the way for what eventually might be vendor supplied plug in modules allowing application consistent recovery provided by either VMware or third parties to be intergrated into the overall flow of the recovery cycle
Kind regards
Alex Tanner
