Upcoming Webinar: TelemetryTV Lunch and Learn

Cloud Services 101: Disaster Recovery

By Microserve
Facebook
Twitter
LinkedIn
Bread and jelly cloud services 101 disaster recovery
Once you have a backups in the Cloud, putting them to use is the next logical step

We’ve covered the basics of what the Cloud is and what it means for your business and followed up with an overview of storing data and backups in the Cloud. Today we’re taking the next logical step—if you have a backup of a virtual server in the Cloud, why not just turn it on? Using a VM backup and turning it on as a functioning server is the basis of disaster recovery in the Cloud or disaster recovery as a service (DRaaS).

We know what the server needs, make it so

At the simplest level here’s how DRaaS works. A Cloud service provider creates a server in their data center that can run an application or service that you have running on one of your own servers in your office (like email). Data between the real and the in-case-of-emergency server are kept in sync through tools like Veeam Cloud Connect, but the disaster recovery server isn’t running, it’s ready to go, and server capacity is allocated for it at the ready, but the server isn’t on…yet. This is one of the magic parts of the system, a server at the ready, always in sync with your main server, but just sitting in suspended animation.

Now let’s say there is a power failure or your email server crashes (it happens), suddenly no one in the office can send or receive email. Panic ensues. Except down in IT, they’ve planned for this, it’s in of the disaster recovery plan, critical systems have cloud counterparts all set. IT and the Cloud provider get on the phone and start turning on the backup servers. In a few minutes email, and other systems like accounting, payroll, and HR, are coming back online.

I’ve oversimplified the scenario above so I wasn’t writing a novel about disaster recovery; there are lots of other moving pieces that need to be in sync for things to work. IT has to make sure domain names and internal networks fail over to the DR server. Email has to have been set up on everyone’s machines so it can failover to a different server if needed. However, these details would have been worked out as part of the disaster recovery plan and communicated with the Cloud provider so people might not even notice the switch to backup servers at all!

Planning for disaster

There are two parts that make disaster recovery as a service work: the servers at the ready and data in sync with the live (or production) servers. Like backup as a service, the data is managed by how much storage is needed to keep things in sync. You pay for the storage you need as you need and use it. The at-the-ready servers are a little different; capacity for those servers must always be available. Cloud providers stay flexible by only increasing capacity as they need it, but if disaster recovery at-the-ready servers aren’t considered part of that capacity, then if the servers are needed, there might not be the capacity available for them. To ensure the capacity is always there the provider has to keep a portion of their servers in reserve to it can be put into service immediately.

But this has a real cost for the provider.

Which makes for a clever compromise between the Cloud provider and the customer. The customer pays for the data storage they are using, which makes sense, but they only pay for a portion of the cost of keeping the DR servers at-the-ready. This compromise allows the provider to have the resources needed for near-instant fail over if there is a problem with production servers, but reduces the month-to-month costs to the customer.

Ready to learn more? Get in touch for a demo or free trial.

What if I didn’t go with the Cloud for DR?

There is another option for disaster recovery, which is to just do it yourself. Have servers at another facility that are running and managed and synced with production and standing at the ready to switch over. There is a cost there too. Beyond the much higher cost of buying the hardware and physical space needed for the servers, your own team must continually patch, update, and test your DR system. Will the server be ready when you need it? What if that server fails?

Cloud servers and services not only take the capital cost and maintenance burden off your shoulders, they reduce the risk of your disaster recovery plan being a disaster too. Since the DR servers are virtual they will always work. Cloud providers have their own redundant systems to ensure that all virtual machines run, and keep running, when they are needed.

From Backup as a Service to Disaster Recovery as a Service in one step

Many Cloud customers start with Backup as a Service (BaaS) and then add on DRaaS after seeing how easy it is to move from backed up data to a functioning server. BaaS and DRaaS are complimentary systems that give you even more backup protection since the DRaaS data needs to be in sync with your production servers you have a live copy of your data and the older BaaS archives are there as a fall back. Together BaaS and DRaaS give you a live and archival backup of data offsite, secured, and verified if the worst case scenario becomes reality.

We’re here to help you

There’s nothing like a live demo or free trial to see how this all can work. Request a free trial of Veeam Cloud Connect and let Microserve give you peace of mind that you data is secure and critical systems will always be there when you need them.

Don’t forget to read Part 1 and Part 2 of this series.

You might also like

Detect Security Blog Banner

How to Detect Security Incidents 

To protect your organization and its assets against security incidents, you need to be able to detect cybersecurity threats. The faster you can detect security