How Disaster Recovery is Different in a Hybrid Cloud

Disaster recovery has many means and can be implemented in many ways. The one thing to keep in mind is that when you are designing a production environment, you should always consider how you are going to recover from a serious incident. What options are available – that mostly depends on the business requirements. If you have to maintain availability through all scenarios, your options are limited and are more expensive. On the other hand, if you can afford a bit of downtime, the range of solutions you can apply significantly increases. In this blog post, we would like to discuss a bit how hybrid cloud setups change your disaster recovery plans.

Two Versus One

Let’s assume you have an on-prem setup. You are owning a datacenter or you are renting servers in an external DC. Whenever you introduce a public cloud in the mix and connect your own network to the secured network in your public cloud, the main, obvious change is that you now have an environment spanning across two locations. This is a giant leap forward in terms of disaster recovery handling. With one location the best you can hope for is to ship your backups somewhere outside of the original datacenter: an off-site backup server, uploading the data to another hosting provider or some sort of a file store, just like S3 in AWS. This also means that the recovery time will be quite long – if your main datacenter would become unavailable, the only course of action for you would be to use the backup you have taken earlier and attempt to rebuild your whole environment on some other hosting provider.

Including public cloud in your environment ensures that you have two locations that you can use for storing the nodes. Having nodes in more than one location means that even if the on-prem side of the network is impacted, you still have working databases in the public cloud part of the network. Those databases may be used to provide service continuity – you can promote one of them to become writable, you can use the data they contain to scale out the public cloud environment and move your operations, temporarily at least, there.

Velocity

Traditional, on-prem, setups, it is not so easy to scale out. You are limited by how fast you can have new hardware ordered and delivered. Depending on the situation this may vary. It could be days if you are ordering the hardware on your own, it can be hours if you put an order with the hosting provider who has the hardware in stock and the only thing that remains is to put it together and install it in the RAC.

Public cloud is years ahead compared to what you can accomplish with “standard” hosting providers. Of course, there might be edge cases but typically you can spin up new infrastructure in a matter of minutes. This makes it a great choice for the disaster recovery scenarios – you do not have to pre-allocate the hardware but you can rely on the availability of the resources in the cloud to quickly build up your infrastructure to production-grade size even if you would start with a skeleton environment.

You can resize instances, you can add more of them.

All of it is typically possible in a matter of minutes. The speed at which you can build up the environment leads us to another section.

Flexibility

With a public cloud integrated into your environment, you have plenty of options how to use it. What’s great, given the velocity in which you can deploy the infrastructure, you can experiment with different setups and you don’t have to commit to long contracts, what is typical for “traditional” providers. Do you predict your workload will increase temporarily? You can scale out vertically or horizontally using the resources in the cloud. Do you want to test different topologies or different deployment patterns for your disaster recovery processes? More small instances or few larger ones? No problem, just do that. Of course, if you can commit to a given set of resources, you can benefit from reduced expenses by contracting them for a longer period of time – this is also possible in the public cloud. Still, if you do not want to do it, you are free to experiment with different options before deciding on whatever works best for you.

As you can see, adding public cloud into the mix and creating a Hybrid Cloud, significantly increases your options and allows you to find the best setup faster and with lower costs. If you have experience working in such a setup and you’d like to share it with others, feel free to add a comment below.