Disaster Recovery Plan in the Cloud

All of those entities have used some sort of backup devices, storage devices, backup storage devices, and other hardware solutions to achieve very efficient RTO’s (Recovery Time Objective) and RPO’s (Recovery Point Objectives). For a large organization, this required massive amounts of hardware in the form of servers, disk space, and network gear. This was often cost prohibitive to entities that could not scale up and out for this type of protection. That’s no longer true with cloud resources like Azure and AWS.

You can achieve this a few different ways via cloud offerings. If you have a server farm hosting an application you can “lift and shift”. If you’re hosting software you have the option to re-architect the app. In either case, you can also re-platform. Let’s talk about each.

A “lift and shift” scenario entails taking your servers that are hosting and, if they are physical, virtualizing them to replicate to the cloud. If they are virtual already then much of your work has already been done. The virtual servers can be moved to the cloud in many different ways to now run on AWS or Azure as they are.

Re-architecting entails rewriting custom apps or hosting your OTS software in the cloud. Re-platforming is defined as a flavor of “lift and shift” in which you move your virtual machines into the cloud but slim the servers and storage down as much as possible to achieve greater financial gains.

The last option is to re-platform. This entails making massive changes to your architecture and/or application. Maybe your entity has decided to do away with servers entirely for this iteration of your product? It’s also possible that you're over being in the mainframe support business. Either way, this is a clean slate utilizing cloud resources to take your technology to a new and modern level free from hardware or geophysical constraints.

Now that we’ve discussed ways to migrate to the cloud we can now talk about what this means for DR operations. Being in the cloud frees your operations from physical limitations, scalability determined by physical capacity, and having data in a physical location when your disaster event recovery requires that data in another location.

Physical limitations are dealt with via cloud resources in that your data is everywhere there is an internet connection. Once your data is in the cloud it can be accessed from your DR site, a new office, or the McDonald’s wifi.

Storing those images is no longer limited by your physical disk space size. You have unlimited storage in the cloud as well as tiered storage options that are some of your very least expensive options. Keep your latest backup images on fast storage while storing your oldest and least accessed images on cold storage backup costing your very little per month.

Consider that the best DR plan is one you never have to implement. With your servers, or serverless app, residing in the cloud you can have an instance in North America and another instance in the EU (European Union). In this way, if the North American instance goes down you can switch over to the EU instance instantly and easily encountering very little if any data loss. Your DR plan just went from an intricate web of contingencies and actions to a singular switching over from one AZ to another allowing you the time required to recover. If the EU instance is faltering under load, copy the data from the EU AZ to a new AZ in Asia. This is all possible with cloud-native infrastructure.

Would you like to find out more about Disaster Recovery & Business Continuity? Learn more how we can build custom Disaster Recovery (DR) solutions tailored to your unique IT operations.