Planning out your business continuity can take time, but it could be a significant cost-saver in the long run. Knowing the risks you face and how to deal with them is a big advantage compared to being blindsided and unprepared when your servers start failing. Regardless of how powerful your servers are, it will not matter if they’re not running.
Two often confusing aspects of business continuity are disaster recovery and high availability. This blog will explain the differences between the two and when to implement each solution.
High availability is a method of designing your storage infrastructure to minimize or even eliminate costly downtime by ensuring you have a fail-over solution in place. It is meant to address periodic outages that could be caused by hardware failure or routine downtime.
Generally, it is measured as a percentage, with 100% being always available. However, there are diminishing returns as the percentage goes higher. A common target is 99.999% available (or downtime of around 5 minutes a year) for those looking for extremely high availability.
Redundant in the server world means something that can take the place of another to keep your infrastructure running when there is a failure. Adding redundancy is the primary method of designing highly available systems. We generally achieve it at the server level through clustering. One of the protocols for designing highly available solutions is to eliminate any single point of failure. This is an important aspect that ensures any single component that is failing or has failed won’t stop your whole system from working. With a multiple server setup, it is also important that any failures are detected and workloads redirected. With 45 Drives’ clustering solutions, even when you’re performing maintenance or an entire server goes down, your data will still be available.
Large amounts of redundancy can be quite expensive. Therefore, it is important to balance cost with your performance and/or storage requirements. If downtime costs more than the additional costs of redundant infrastructure, it can be a cost saver to implement a highly available solution now rather than attempting to stick a square peg in a round hole later.
*Redundancy also exists on the component level. Disaster hardware such as redundant power supplies or switches, for example. This can keep a single server from going down and prevent you from needing to failover.
Imagine this – your server room just exploded and, all your data is destroyed – do you have a plan to deal with it?
High availability won’t save you from data loss; that is what disaster recovery is for. Having a way to deal with a flood, fire, theft, cyber-attack, IT admin who makes a catastrophic mistake, or any other way you could take down your entire server infrastructure. Losing all your servers and data is rare but can be the end of many businesses, and at best, will likely be expensive. Disaster recovery is all about being prepared for the worst-case scenario when your infrastructure is dusted. It is a planned strategy, combined with the way you designed your system, to make sure recovery is within your acceptable downtime for your business to survive and, lastly, that your data will still be secure and available.
Some think disaster recovery is like having a backup, but it is more than that. If your system gets wiped out completely and you have a week-old backup on tape (many do), with no plan to get your servers back up and running, you’re likely in a troublesome position regardless of that data still existing. As well, if there is a fire in your building and you keep your backup there too, it could also be destroyed, leaving you in the same position as if you hadn’t been backing it up. Disaster recovery also includes the plan for how to handle those situations and minimize additional or surprise expenses. It also means ensuring you have your backup data kept in a geographically separate location so it won’t be destroyed with the rest of your data, which can be done over your local network or the internet. Unlike highly available clusters, these copies aren’t meant to be quickly failed over when the primary server(s) fail. They are meant to keep your mission-critical data safe.
Your budget, how quickly you need your data back, and how much data loss you can tolerate (how old your backups can be) will determine what sort of solution you require.
How quickly you get the backup implemented and how old it is will depend on your recovery time objective (RTO) and recovery point objective (RPO).
RPO is how old your data can be when it is back up and running; this determines how often you should back up your server. RTO is how long you can wait for post-catastrophe to have your servers back up and running normally. This can inform how you should design your system to balance costs with recovery time. With these together, you can understand your needs for creating a disaster recovery solution.
So, let’s summarize the differences between the two.
High Availability
Disaster Recovery
Interested in learning more about one or both of these solutions? Talk with an account manager today.
Newsletter Signup
Sign up to be the first to know about new blog posts and other technical resources
