Disaster Recovery vs. Backups — What’s the Difference?

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

2063

Abstract

I have mentioned, running backups takes care of small-scale failures. Disaster recovery is not the same thing. Disaster recovery, first of all, is really about production applications. It protects against a whole region failure. Wait, what is a region failure? A region failure would be if wherever your production application is running experienced some sort of a natural disaster. Could be something like widespread flooding, widespread cold, a tornado, or a hurricane, basically something that will take that entire region offline.In such a scenario, you will declare a disaster and failover from that primary site to your disaster recovery site. Now, you can do that with backups, but it takes a while. It is not a great idea because you will have a long downtime, which I can only assume is unacceptable. That is when you set up your disaster recovery site a standby. This means that you are constantly streaming production data from your production site over to your disaster recovery site, so the amount of downtime that you take that your system is down is relatively low.If we were to compare these two, a backup is a point in time, ie, your application and data are all backed up and stored in the backup server at a specific time. That means that if there are any changes made between that time and the next backup cycle, and things go wrong, you will lose them. That is how backups work. Disaster recovery is streaming. If you are streaming, you are only going to get a little bit of lost data, as opposed to backups. It is a much higher availability because it solves the problem of having minimal downtime, which for production applications is absolutely critical.Switching from production to disaster recovery is a process that can be done programmatically, whereas restoring from a backup is almost always manual. There are some things that you can do to automate backup restores, but you still have to check and be sure that the backup is restored correctly. With that said, backups are good fo

Options

r other things. You can restore backups anywhere. If you have an application or data in location A, you can back that up and move it over to location B. This is purely about moving applications — portability. In this kind of setup, you can run tests on a clone of your production application and keep developing and testing without actually affecting the production application.My primary issue is that people will talk about these tools as if they are disaster recovery tools even when they are really not. They are not entirely wrong but look at it this way, can you afford the downtime? You might think you do not need a disaster recovery site because you have a great backup policy and all. If you are trying to use backup for your disaster strategy, you need to ask yourself the question of time. How long can you afford to be down? When it comes to the disaster recovery strategy, your downtime and data loss will be minimal compared to restoring from a backup.The key for you to take away is that these two have entirely different use cases, two different goals. So, solving your disaster problem cannot be done with backups, and disaster recovery is not a backup of your production system. You can’t just have a disaster recovery site and assume that that is good enough. Your disaster recovery site should be taking backups of the data that lives within it, so in the event of a huge disaster where your streaming is interrupted or corrupted, you have a proper backup. I mean, host failures can also happen in a disaster recovery site just like they can happen in a production site.I hope that this has been helpful, and you can design your strategies in a better way, in a more resilient way, and in a way that solves the needs for you and your business and company. Keep in mind that you can work well with both of them together for the sake of being thorough and efficient.More content at <a href="http://plainenglish.io/">plainenglish.io</a></article></body>

Know the difference to design your strategies for safeguarding your data in a more resilient and better way.

Have you ever thought of a way of protecting your data in case of failure? What is the strategy you normally use for such scenarios? I would like to explain the two most misunderstood topics — those are backups and disaster recovery.

If you will not finish reading this, I would like to emphasize more than anything else that they are not the same thing, therefore, they should not be treated as if they are.

I want to talk about some differences. I am aware that they have a generally similar goal, which is to protect your data in the event of some sort of failure. The difference is that the type of failures might not be the same. What kind of failures do backups protect against? Well, these include things like host failure. That is when the system on which you are running your application goes down. It will also protect you against some sort of malicious attack. The most popular attack right now is the encryption scheme, where someone will compromise access to your system then send you a demand letter, kind of like ransomware. In the case that you do not meet their demands, restoring your system from your backup is the only option you will have. That is not a problem because I can only assume that making backups is part of your daily routine. These are basically all small-scale failures.

Let’s switch gears a little bit and discuss disaster recovery. A disaster recovery scenario is a very different kind of beast. As I have mentioned, running backups takes care of small-scale failures. Disaster recovery is not the same thing. Disaster recovery, first of all, is really about production applications. It protects against a whole region failure. Wait, what is a region failure? A region failure would be if wherever your production application is running experienced some sort of a natural disaster. Could be something like widespread flooding, widespread cold, a tornado, or a hurricane, basically something that will take that entire region offline.

In such a scenario, you will declare a disaster and failover from that primary site to your disaster recovery site. Now, you can do that with backups, but it takes a while. It is not a great idea because you will have a long downtime, which I can only assume is unacceptable. That is when you set up your disaster recovery site a standby. This means that you are constantly streaming production data from your production site over to your disaster recovery site, so the amount of downtime that you take that your system is down is relatively low.

If we were to compare these two, a backup is a point in time, ie, your application and data are all backed up and stored in the backup server at a specific time. That means that if there are any changes made between that time and the next backup cycle, and things go wrong, you will lose them. That is how backups work. Disaster recovery is streaming. If you are streaming, you are only going to get a little bit of lost data, as opposed to backups. It is a much higher availability because it solves the problem of having minimal downtime, which for production applications is absolutely critical.

Switching from production to disaster recovery is a process that can be done programmatically, whereas restoring from a backup is almost always manual. There are some things that you can do to automate backup restores, but you still have to check and be sure that the backup is restored correctly. With that said, backups are good for other things. You can restore backups anywhere. If you have an application or data in location A, you can back that up and move it over to location B. This is purely about moving applications — portability. In this kind of setup, you can run tests on a clone of your production application and keep developing and testing without actually affecting the production application.

My primary issue is that people will talk about these tools as if they are disaster recovery tools even when they are really not. They are not entirely wrong but look at it this way, can you afford the downtime? You might think you do not need a disaster recovery site because you have a great backup policy and all. If you are trying to use backup for your disaster strategy, you need to ask yourself the question of time. How long can you afford to be down? When it comes to the disaster recovery strategy, your downtime and data loss will be minimal compared to restoring from a backup.

The key for you to take away is that these two have entirely different use cases, two different goals. So, solving your disaster problem cannot be done with backups, and disaster recovery is not a backup of your production system. You can’t just have a disaster recovery site and assume that that is good enough. Your disaster recovery site should be taking backups of the data that lives within it, so in the event of a huge disaster where your streaming is interrupted or corrupted, you have a proper backup. I mean, host failures can also happen in a disaster recovery site just like they can happen in a production site.

I hope that this has been helpful, and you can design your strategies in a better way, in a more resilient way, and in a way that solves the needs for you and your business and company. Keep in mind that you can work well with both of them together for the sake of being thorough and efficient.