3 Real-World Disaster Recovery Scenarios
Disaster recovery is one of those things that is easy to explain in the abstract, and harder to understand at the real-world, implementational level.
That is why it may be worth your time to study some disaster recovery examples that help illustrate the steps required to prepare for disaster recovery, as well as the process involved in a successful recovery from disaster.
That’s what we do below. Keep reading for some examples of real-world disaster recovery scenarios. We’ll focus especially on situations involving the restoration of data availability, but the lessons below apply generally to any type of disaster recovery scenario.
Example 1: A DDoS attack
In this disaster recovery scenario, imagine that a group of malicious hackers executes a Distributed-Denial-of-Service (DDoS) attack against your company. The DDoS attack focuses on overwhelming your network with illegitimate requests so that legitimate data cannot get through.
As a result, your business can no longer connect to databases that it accesses via the network—which, in today’s age of cloud-native everything, means most databases. It’s rare nowadays to have a database that does not require a working network connection to do its job.
In this scenario, disaster recovery means being able to restore data availability even as the DDoS attack is underway. (Ending the DDoS attack would be helpful, too, but anti-DDoS strategies are beyond the scope of this article; moreover, the reality is that your ability to stop DDoS attacks once they are in progress is often limited.) Having backup copies of your data would be critical in this situation. That’s obvious.
What may be less obvious, however, is the importance of having a plan in place for making the backup data available by bringing new servers online to host it. You could do this by simply keeping backup data servers running all the time, ready to switch into production mode at a moment’s notice. But that would be costly, because it would mean keeping backup servers running at full capacity all the time.
A more efficient approach would be to keep backup data server images on hand, then spin up new virtual servers in the cloud based on those images when you need them. This process would not be instantaneous, but it should not take more than a few minutes, provided that you have the images and data already in place and ready to spin up.
Example 2: Datacenter destruction
One of the worst-case scenarios that a modern business can face is a disaster that destroys part or all of its datacenter—and all of the servers and disks inside it.
While such a situation is rare, it can happen, and not only as a result of a major natural disaster like an earthquake or hurricane. Issues such as electrical surges and even ill-fated squirrels can cause permanent datacenter damage.
The best way to prepare your business for recovery from this type of disaster is to ensure that you have offsite copies of your data. If your production data lives on-premise in one of your datacenters, this would mean keeping backups of the data at another datacenter site or in the cloud. If your data is hosted in the cloud, you could back it up to local storage, to another cloud or a different region of the same cloud.
You will also want to make sure that you have a way of restoring the backup data to new infrastructure quickly. Moving large amounts of data from one site to another over the Internet can take a long time, so it’s not always a wise strategy within the context of disaster recovery. In some cases, it might be faster to move physical copies of disks from one site to another. Alternatively, it might prove quicker and easier to stand up new servers in the datacenter where your backup data lives, then connect them to the backup data and turn them into your production servers.
The bottom line: Restoring data after datacenter destruction requires having offsite copies of the data available, as well as a plan for moving that data quickly to wherever it needs to go following the disaster in order to keep your business running.
Example 3: Data sabotage
A third type of data disaster that might befall your business is one in which someone—such as a disgruntled employee—deliberately sabotages data. The employee might insert inaccurate or bogus data into your databases, for example, in order to lower data quality and make the data unusable for your business. He or she might even insert malicious code into your data in an effort to spread malware to your systems.
The critical step in preparing for this type of disaster is to ensure that you have backup copies of your data that go back far enough in time to allow you to recover using a version of the data that you know to be safe. If the only copy of your data that you have available was taken a day ago, but the damage occurred three days ago, the backup won’t help in this situation.
This is why it’s a good idea, when possible, to have multiple backups of your data on-hand, each taken at a different time increment. Instead of deleting the last data backup when you make a new one, keep older backups on hand so that you can use them for disaster recovery if you need. If you make a backup daily, and keep seven backups on hand, then you know that you can restore data from as long as a week ago if newer backups contain damaged information.
The trade-off for using an older backup for disaster recovery, of course, is that any data that was added or modified since the backup was taken will be lost. In certain disaster recovery situations, however, this is the price you have to pay.
Keep in mind, too, that if you can identify which parts of your data was sabotaged, you can leave that data intact, and recover only the damaged data, in order to minimize data loss.
Check out our white paper on the causes and effects of data breaches!