3 Application Architectures for Successful Disaster Recovery in the Cloud

Over the past few years, we’ve written several blog posts about various disaster recovery methods for your applications running atop of Cloud-A’s infrastructure. If you take a look at these various articles, which highlight software and tools to help you achieve your disaster recovery requirements, you’ll notice that there there is more than one way to skin this cat.

The method you use to backup and recover your applications and data should vary depending on the technical requirements of a given application and/or data store and your organization’s tolerance for downtime for that app or data store.

Let’s dig into three conceptual models for disaster recovery on Cloud-A. We’ve ranked these methods 1-5 by data resiliency, time to recover and cost.

Baked-in Global Replication ????? 

Data Resiliency ?????

Recovery Time ?????

Cost $$$$$

With this method, your application would have one single global replicated database with multiple access points. In the case of a disaster – say a total region failure, there should be no affect to the availability of the data since the data is stored in multiple locations and can accessed by more than one server.

Advantages:

  • “Never” down
  • More dynamic / living

Disadvantages:

  • High difficulty to achieve success – may require some refactoring of your workload(s) architecture.
  • In case of downtime, has a greater impact.

Suitable for:

  • Mission critical applications with zero tolerance for downtime

Cost Inputs:

  • Application has to be developed and architected specifically for this model. This cost can be hard to calculate quickly and can be expensive in some circumstances because it is a function of developers time/effort and integration costs.
  • Higher cost to run more application and data servers to be able to handle load in case a zone fails.
  • For high performance database replication across multiple geographic regions, more-advanced, higher performing networking solutions may be required.

Asynchronous / Live Failover ????? 

Data Resiliency ?????

Recovery Time ?????

Cost $$$

 In this scenario, you would setup your data store in a master/slave architecture – where the master is the authoritative database source, and the slave databases are synchronized to it. In the case of a disaster, where your master data store goes offline, your application would flip over to use the slave database.

Advantages: Quick recovery, automatable, common (easy to set up, lots of examples)

Disadvantages: This architecture can result in some downtime during a failure, depending on setup. Complexity in recovering to “old master”, generally requires some manual intervention. Some data loss could occur depending on replication technology or snapshot frequency.

Suitable for: Most applications

Cost Inputs: idle servers (usually smaller than production servers), slave database(s,) replication software licenses

Fail and Restore ????? 

Data Resiliency ?????

Recovery Time ?????

Cost $

Fail and restore is a traditional disaster recovery method that has been around for decades. Leveraging backup software you would take regular backups and/or snapshots of your data. You would also need to design a full rebuild plan that outlines the order of steps required to recover your data from a backup. In the event of a disaster/outage, you would restore from that backup – making this the slowest of the three methods.

Advantages: Low initial infrastructure cost

Disadvantages: This method will have the longest amount of downtime in the event of a failure due to the manual intervention required to recover from a backup.

Suitable for:

  • Legacy, monolithic applications
  • Workloads that have a larger tolerance for downtime (non-mission critical workloads.)

Cost Inputs:

  • Backup software and agents
  • Infrastructure to run backup software (in some cases, depending on the software’s architecture)
  • Storage to store backups

Cloud-A Tools to Help

Dual Nodes

Last Summer we announced the launch of our Vancouver data center. Since then, we’ve seen our customers leverage this geo-redundancy to build resilient, highly available, distributed applications between our Halifax and Vancouver nodes.

Bulk Storage

At $0.075 ger GB per month, Cloud-A Bulk Storage is the most cost effective storage medium we offer for backups. Additionally, all data stored in Bulk Storage is replicated 3x for extra redundancy!

NOTE: Because Bulk Storage is accessed via an API, not all backup software is compatible. Check out our Bulk Storage Backup page for a list of supported vendors.

More Info:

Snapshots

Snapshots are a native Cloud-A feature available to all users. Snapshots provide you with a point in time image of your server or storage volume which gives you system redundancy as you can easily and quickly spin up a new instance based on any of your saved snapshots. Snapshots can be done manually, or automated via our API.

More Info:

Next Steps

Not sure which backup and recovery solution is best for your workload? Feel free to reach out to one of our partners directly, or flip us an email and we can introduce you!