Over 90% of businesses that do not recover from a disaster within 5 days will close within a year, according to FEMA. Despite the risk, businesses still fail because their cloud disaster recovery (DR) plans are built on “hope.” There are three groups basing their future on hope:
Group 1: Hope nothing will go wrong. They have no DR plan.
Group 2: Hope that IT protects the “right” things. They protect only some applications.
Group 3: Hope that everything will “just work.” They never test their DR.
While it is easy to criticize organizations without a robust disaster recovery plan, most companies cannot afford to do better. To follow disaster recovery best practices, organizations need affordable, simple, disaster recovery solutions. After decades of complex, hardware-intensive offerings, a cloud-centric disaster recovery architecture can replace hope with a real plan.
Disaster recovery best practices
Organizations that survive disasters follow 3 rules:
- Protect (almost) everything
- Test application recovery
- Plan to survive for weeks or months in the disaster configuration
Protecting everything is the only way to ensure that the company’s most important assets are safe. It is unrealistic to expect IT to know which applications and infrastructure are business critical, since the business units probably do not even know. No amount of meetings, change control processes, or individual heroism can combat the natural entropy of IT infrastructure. Therefore, to be safe, successful organizations protect virtually everything.
Testing is the only way to ensure complex applications can be recovered. Protecting components of a business application won’t keep the company running. Disaster recovery must protect and recover the entire application – infrastructure, application, and data. As applications become more distributed, frequent testing uncovers gaps in the DR configuration. Widespread testing also enables IT to train more people to run a disaster recovery. Too often, inexperienced teams destroy the DR setup by panicking when it comes time to push the “big red button.” There is no substitute for the experience that comes with testing.
Organizations need to be prepared to use their “DR setup” for an extended period of time because some disasters can compromise data centers for weeks or months. Therefore, they need a plan to secure, protect, and grow the DR environment. You do not want to survive the initial disaster only to be cyber-attacked, lose data, or constrain the business. The initial disaster recovery is just the first step.
How to reduce the cost of disaster recovery
Organizations know they should protect their entire environment, but even the largest enterprises cannot afford to double the cost of their production environment – including servers, networking, and data storage.
With the cloud, it is possible to protect all your applications without an overwhelming bill. In the cloud, companies can spin up the compute infrastructure for their applications on-demand. They no longer need data centers filled with servers, networking, and storage systems “standing by” waiting for a disaster to happen.
The challenge, however, is data. For the past decade, backup vendors have attempted to improve performance, so you can use backup copies for disaster recovery. While the approaches were unsuccessful (conflicting requirements for low-cost storage vs. performance, still requiring an extra data center), the model was correct. Backup and disaster recovery are now converging in the cloud.
In the cloud, you can run an “on-demand” recovery of an EBS snapshot (held on object storage) into an active copy (block storage). As the compute infrastructure comes up, the data will be available for the applications. While performance will be limited as the working set is restored, the application is running.
With on-demand infrastructure and data in the cloud, the cost of disaster recovery plummets. There is no standby data center. There is no extra infrastructure. There is no extra backup appliance. There is only preparedness for whatever may happen.
How to test disaster recovery
Organizations do not test disaster recovery because it is complicated and risky. First, most organizations do not have a “sandbox,” so they fail over their business to the secondary site. Since a failed disaster recovery test can take them offline, they are hesitant to run the tests. Second, they prepare for the test so carefully that it does not resemble an actual disaster. Third, the test itself modifies the infrastructure, so they are not confident that even a successful test means that they are ready for a disaster (aka Schrodinger’s DR Test).
Disaster recovery tests need to be run realistically and frequently. Therefore, organizations need a DR test sandbox that is completely independent of the production and protection infrastructure. With a realistic sandbox, anybody can run a disaster test at any time.
In the cloud, you can run disaster recovery tests whenever you want. You can clone the disaster recovery environment, run a recovery, and validate the results. Neither the production or protection environments are affected. Since the disaster recovery environment is provisioned on-demand, it does not cost much, either.
With on-demand infrastructure and data in the cloud, you can test your disaster recovery with confidence.
How to survive after the disaster recovery
After recovering from a disaster, most organizations are not prepared for what comes next. Sometimes it can take weeks or months before the primary data center is available. Most DR sites are not capable of sustaining the business. They rarely have data protection because if you can barely afford a second site, you definitely cannot afford a third. Since the site is remote, they lack the staff or space to react to the new business needs.
In the cloud, disaster recovery sites can be run as full production sites. After failing over, you can set up disaster recovery for the site to another region in the cloud. Since it is the cloud, you can manage it from anywhere in the world. You can also add resources even more easily than in your data center.
With on-demand infrastructure and data in the cloud, you can reliably use your disaster recovery site for as long you need.
How to get cloud disaster recovery
Druva offers cloud-native disaster recovery for workloads running in remote offices, data centers, and the cloud, so you can protect all your applications.
Druva uses AWS to offer low-cost disaster recovery in 15 minutes or less. Druva backs up all your data to the cloud, so that it is automatically offsite. For customers who want the fastest disaster recovery in their VPC, Druva maintains an EBS snapshot (held on S3 storage) of each virtual machine. When it is time to recover, Druva brings up the virtual server in AWS and uses the on-demand EBS snapshot recovery to bring up the application. The compute, network, and block storage are not allocated until it is time to recover.
Druva’s disaster recovery enables unlimited testing. Using the same configuration, users can simply clone as many disaster recovery environments as they want, whenever they want. With simple network rules, the tests do not affect the production environment. Since everything is cloned on-demand, the tests do not affect the disaster recovery setup, either. Customers can also test as often as they want.
Druva’s comprehensive disaster recovery protects applications wherever they are. Druva protects applications in the cloud, so it also protects applications after they’ve been brought up in the cloud. One solution protects your applications no matter where they are running.
Conclusion
While it will never be enjoyable to prepare for a disaster, it can be less painful. You do not have to rely on a “hope-based” plan because the cloud enables organizations to follow disaster recovery best practices. With on-demand disaster recovery, you can protect everything, test frequently, and be prepared for whatever comes next.
After a disaster, businesses should no longer fail. With a cloud-native data protection solution, they can survive a disaster and emerge even stronger.
Read Druva’s white paper to explore best practices, utilize tools and sample templates to build an effective DR plan to meet your organization’s needs.