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 ★★★★★
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.
- “Never” down
- More dynamic / living
- High difficulty to achieve success – may require some refactoring of your workload(s) architecture.
- In case of downtime, has a greater impact.
- Mission critical applications with zero tolerance for downtime
- 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 ★★★✩✩
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 ★✩✩✩✩
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.
- Legacy, monolithic applications
- Workloads that have a larger tolerance for downtime (non-mission critical workloads.)
- 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
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.
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.
- Automatic Server Backups to Cloud-A Bulk Storage
- Bulk Storage Auth for Cloudberry Products
- Using Bulk Storage Container Keys with Duplicity
- Nova Scotian MSP saves 30% on Cloud Backup Storage with Cloud-A
- WordPress Backups for Beginners and Advanced Users
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.