This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - Executing and managing cloud disaster recovery strategies: Read more in this section
- Planning and testing disaster recovery in the cloud
- Cloud-based disaster recovery requires strict management
- Best practices for disaster recovery in the cloud
- Defining disaster recovery strategies using cloud computing
- The importance of testing in your cloud DR strategy
- Disaster Recovery as a Service terms you need to know
- Rolling out disaster recovery in the cloud without the pain
- Six steps to implementing cloud-based disaster recovery
- What disaster recovery means for the hybrid cloud model
- Why companies are turning to a multi-cloud model
Explore other sections in this guide:
There's some confusion between traditional offsite disaster recovery and DR in the cloud. Knowing the difference and spelling out recovery requirements are the first stages in maintaining a solid DR strategy.
Disaster recovery has evolved from barely more than tape-based restores and rented data center space for recovery of essential services to nearly instant switchover from a downed site to a virtual failover site. Differences also exist in how cloud computing DR vendors manage the offsite component, or how they get an IT environment to the cloud. And what some people might say they believe is DR in the cloud, is not.
Most vendors insert a device into the client's IT infrastructure to acquire information, store it locally and then replicate it to the cloud. In nearly all cases, data isn't actually going to the cloud; data is actually transferred to the provider's data center. This method is similar to traditional backup. It's local, fast and allows you to recover data from the device in the event of a non-disastrous data loss. In the event of an actual disaster that takes the protected site offline, offsite data is brought back online and presented over the Internet.
Once you understand where data is housed in the event of a disaster, it's crucial for IT teams and business managers to determine recovery point objectives (RPO) and recovery time objectives (RTO) that meet the company's needs. While many companies may want always-on, never-down operations, often budget and the likelihood of a disaster occurring help them realize that's not necessarily what they need. It's important to set realistic DR goals.
For companies that depend on technology to generate revenue, a zero RPO/zero RTO rule holds true; paying for this DR plan is part of the cost of doing business. For others companies, cyber insurance and a high RPO/RTO will suffice. The larger the business is, the more complex the portfolio is, the more complex its RPO and RTO needs are -- from zero/zero to an 8 hour/24 hour setup to a more complex 24/24 requirement.
DR in the cloud options
Virtualization is the underlying technology of cloud-based disaster recovery. And this is where, later in this process, it becomes a true cloud service. Major vendors like IBM, Iron Mountain, CommVault, Simply Continuous and AppAssure provide commercial-grade cloud-based DR products designed to integrate with business standards and processes, report on activities and keep both IT teams and business units informed about the product's status.
Virtual machines (VMs) that were created to recover the IT environment are no different from VMs you would bring up in a dedicated facility using physical machines. The only disparity is that these VMs are hosted in a third-party facility and are essentially operating from the cloud. When the lights go out at the protected facility and disaster protocols are invoked, those VMs replace both physical machines and virtual machines -- taking over as production machines.
This approach is SLA-friendly. Virtual machines that store DR data and applications can be brought up in a controlled manner. This allows you to manage capacity and cost. If a business unit has an RTO of four hours for a Web-based order-processing system and an RTO of 48 hours for a frequently used but nonessential historical archive of customer orders, the service-level agreement dictates that the DR product immediately recover the Web-based order processing systems and wait to recover historical archives. This hold on recovery serves two purposes: it reduces to cost associated with any compute time and gives harried IT staff time to ensure that more critical SLAs are met first.
A phased recovery plan also allows time for the disaster to dissipate or pass. It's common to plan for utter destruction; however, in many cases, a disaster is a simple case of evacuation. Once the evacuation orders have been lifted and the facility has been checked, you may not need to run the DR protocol for less critical SLAs.
ABOUT THE AUTHOR
Joseph Foran is the IT director for Bridgeport, Conn.-based FSW, Inc., and principal at Foran Media, LLC. He has been in IT since 1995, specializing in infrastructure, and involved in virtualization and cloud computing since 2002. Email Joe at email@example.com or follow him on Twitter (@joseph_foran).