• Home
  • About Us
  • Contact Us
  • Privacy Policy
  • Special Offers
Business Intelligence Info
  • Business Intelligence
    • BI News and Info
    • Big Data
    • Mobile and Cloud
    • Self-Service BI
  • CRM
    • CRM News and Info
    • InfusionSoft
    • Microsoft Dynamics CRM
    • NetSuite
    • OnContact
    • Salesforce
    • Workbooks
  • Data Mining
    • Pentaho
    • Sisense
    • Tableau
    • TIBCO Spotfire
  • Data Warehousing
    • DWH News and Info
    • IBM DB2
    • Microsoft SQL Server
    • Oracle
    • Teradata
  • Predictive Analytics
    • FICO
    • KNIME
    • Mathematica
    • Matlab
    • Minitab
    • RapidMiner
    • Revolution
    • SAP
    • SAS/SPSS
  • Humor

3 Real-World Disaster Recovery Scenarios

October 17, 2018   Big Data
3 Real World Disaster Recovery Scenarios 3 Real World Disaster Recovery Scenarios
Christopher Tozzi avatar 1476151897 54x54 3 Real World Disaster Recovery Scenarios

Christopher Tozzi

October 17, 2018

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.

Causes and Effects of Data Breaches banner 3 Real World Disaster Recovery Scenarios

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!

Let’s block ads! (Why?)

Syncsort Blog

Disaster, Realworld, Recovery, scenarios
  • Recent Posts

    • The Dynamics 365 Sales Mobile App Helps Salespeople Stay Productive From Anywhere
    • THEY CAN FIND THE GUY WHO BROKE A WINDOW BUT NOT A MURDERER?
    • TIBCO4Good and She Loves Data Offer Free Data Skills Workshops During a Time of Vulnerability
    • Aurora partners with Paccar to develop driverless trucks
    • “Without Data, Nothing” — Building Apps That Last With Data
  • Categories

  • Archives

    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • March 2020
    • February 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    • December 2016
    • November 2016
    • October 2016
    • September 2016
    • August 2016
    • July 2016
    • June 2016
    • May 2016
    • April 2016
    • March 2016
    • February 2016
    • January 2016
    • December 2015
    • November 2015
    • October 2015
    • September 2015
    • August 2015
    • July 2015
    • June 2015
    • May 2015
    • April 2015
    • March 2015
    • February 2015
    • January 2015
    • December 2014
    • November 2014
© 2021 Business Intelligence Info
Power BI Training | G Com Solutions Limited