The fundamental activities in virtualized environments are essentially the same as physical storage environments. You still need to identify critical systems and data, establish backup and recovery capabilities for them, and test and validate the recoverability of identified critical systems and data. However, even if your organization has made a commitment to an overall disaster recovery strategy/business continuity (BC) program, it can become a major undertaking for virtualized environments, especially for large enterprises with hundreds or thousands of servers. Development, deployment, support and testing of a full disaster recovery/business continuity solution could require major funding, staffing and resources.
Depending on what are perceived to be the most critical virtualized resources, a BC/DR program might be limited to only those resources, especially considering what might be needed to address BC/DR requirements for all virtualized assets. Among the issues to address for disaster recovery in a virtualized environment are the location(s) of data storage assets, network infrastructure changes and security, as well as any server-focused changes.
Since the overall virtualized environment can be located anywhere, the data storage can also be located anywhere. The challenge then is where to locate the physical storage components. Changes to network infrastructure requirements will necessitate a review of internal and external network topology, bandwidth and latency. This occurs because your infrastructure will have both external and internal components, and your present network organization may not be appropriate for a virtualized environment. Finally, security needs to be addressed because you may not have end-to-end control of network security, especially with third-party firms that support your new environment. You will need to carefully review your network perimeter to ensure there are no unauthorized access points from the transition.
Smaller virtualized environments can either build a do-it-yourself disaster recovery solution, such as blending recovery software with virtualization software, or working with third-party organizations, such as Neverfail Group or SunGard Availability Services, that offer BC/DR solutions for virtualized environments. It may be faster and more cost-effective to go with a third party, but if the company's technology organization has the expertise, an in-house solution would also make sense.
On the plus side, virtualization minimizes the hardware requirements for systems recovery. If virtual machines (VMs) can be located anywhere, perhaps special "virtual DR machines" that are designed as hosts for VMs used for disaster recovery can be established. Virtual DR machines can be compacted into single files, making them highly portable and located almost anywhere. Because of that, they can also be deployed in a disaster and then rolled back quickly and easily afterward.
In conclusion, when incorporating virtualization into your disaster recovery program, the
strategic challenges are to:
1) Decide to leverage virtualization into BC/DR programs.
2) Identify critical systems and applications that can use virtual DR machines.
3) Build the ability to rapidly deploy virtual DR machines.
4) Test recoverability of critical systems into the virtual DR machines.
5) Document the procedures for this process so that recovery can be effected by almost anyone.
In the next part of our article on disaster recovery planning and virtualization, learn about technical considerations for virtualization and disaster recovery.
About this author: Paul Kirvan, CISA, CSSP, FBCI, CBCP, has more than 20 years experience in business continuity management as a consultant, author and educator. He has been directly involved with dozens of IT/telecom consulting and audit engagements ranging from governance program development, program exercising, execution and maintenance, and RFP preparation and response. Kirvan currently works as an independent business continuity consultant/auditor and is the secretary of the Business Continuity Institute USA chapter and can be reached at firstname.lastname@example.org.
This was first published in October 2010